Contexto de GIT en el mundo colaborativo

El creador de LINUX creó GIT como una herramienta que le permitiera coordinar el trabajo en equipo entre sus miles de colaboradores.  La idea era tener un trabajo original y crear copias que se irán editando para completar el trabajo original, permitiendo la comunicación entre los diferentes colaboradores del proyecto o trabajo a realizar.

Lo bueno de ésta herramienta, es que puede ser complementada con otras como JIRA, controlando las diferentes versiones y pudiendo encontrar posibles fallos fácil y rápidamente.

A continuación, ejemplificaré diferentes maneras de solucionar problemas habituales que se dan en entornos de trabajo en equipo.  En primer lugar, mostraré cómo organizar a varias personas trabajando sobre el mismo proyecto, de manera que cada miembro tiene una copia en su repositorio evitando así cualquier pérdida de datos y mantener el original seguro y controlado. Posteriormente, explicaré cómo coordinar el trabajo entre los miembros que colaboran en el proyecto para finalmente unir las diferentes piezas del proyecto en el trabajo original.  También expondré cómo unificar los cambios en un único cambio, facilitando la tarea de revisión e inclusión a la versión original.

Gestión de varios remotes

Problema

En un proyecto de varias personas, puede pasar que cada uno tenga su rama de trabajo en su repositorio. Esto puede complicar las cosas si se quiere probar la compatibilidad de cambios de diferentes personas sin pasar por el repositorio principal.

Solución

Git permite tener varios repositorios asociados al repositorio del usuario. Esto permite que se puedan traer cambios de otras ramas de otros usuarios a local y hacer pruebas.

Ejemplo paso a paso

Para facilitar, se crearán 2 repositorios en local y uno en remoto. Los locales serían los de 2 desarrolladores diferentes, mientras que el remoto sería el repositorio oficial, en el que hay que hacer una pull request para que se añadan los cambios.

Se crean 2 repos locales:

cd /tmp
mkdir repo1
mkdir repo2
cd repo1; git init; cd ..
cd repo2; git init; cd ..
cd repo1

Se añade el repositorio local y uno remoto (github, por ejemplo) al repositorio 1:

git remote add repo2 ../repo2
git remote add githubrepo url
git remote -v
repo2 ../repo2 (fetch)
repo2 ../repo2 (push)
githubrepo url     (fetch)
githubrepo url     (push)

Se crea una rama nueva para añadir una nueva feature y se hacen cambios:

git checkout -b feature1
cat – << EOF > 1
cambio1
EOF
git add 1
git commit -a -m “cambio 1”

Se añade el repositorio repo1 como origen. Se obtienen los cambios desde el repo2 con un fetch y se accede a la rama, para añadir otro cambio:

git remote add repo1 ../repo1
git remote -v
repo1 ../repo1 (fetch)
repo1 ../repo1 (push)
cd ../repo2
git fetch repo1
git checkout repo2/feature1
cat – << EOF > 1
cambio2
EOF
git commit -a -m “cambio 2”

Se hace un push con los cambios al repo1 (suponiendo que se tengan permisos de escritura, que en este caso sí se tienen). Luego se puede ver en repo1 que los cambios están:

git push repo1
cd ../repo1
git log

Ahora, si se tienen permisos, se puede hacer un push al repo de github:

git push –set-upstream githubrepo feature1

Si no, hay que hacer una Pull Request.

Organización del histórico con rebase

Problema

Git organizacion rebase
Git cambios de rama

Se han hecho cambios en una rama, y se meten en master. Ahora la rama feature1 está “descoordinada”. Si se intentan meter los cambios en master, puede haber conflictos por haber cambiado los mismos ficheros. La rama feature1 debería actualizar su bifurcación (su “base”) para que al hacer el merge no aparecieran problemas.

Solución

git checkout feature1
git rebase master

Git cambio master

Ahora la bifurcación de feature1 se iniciaría en el último cambio de feature2, y, por tanto, de master. Ahora se puede hacer el merge sin problemas:

git merge feature1
Updating 0039646..24e91af
Fast-forward

Problema

Se quieren agrupar todos los cambios en un único commit, asociado a la feature. En vez de tener esto en la rama feature3:

Git agrupar commit

Se busca tener esto:

De forma que todos los cambios estén en un mismo commit.

Solución

Git  cambios commit

Se hace un rebase interactivo de los 3 últimos commits: git rebase -i HEAD~3

Git rebas interactivo

Se coge el más antiguo con pick(p) (el de más arriba) y los otros dos con squash(s):

Git pick

Ahora, al haber puesto squash, se permite modificar el commit inicial para añadirle información:

Git modificar commit

Ahora al guardar ya se tendrán los commits reorganizados:

Gir commits reorganizados

Gestión de repositorio principal (Pull Requests)

Desde los repositorios online (github, gogs, gitlab…) se puede pedir un pull request a través de la web. Una vez subida la rama al repo propio online, los pasos serían estos (en github):

Git pull request
Git new pull request
Git cambios en el commit

Al seleccionar Create pull request le llegará una notificación al dueño del repositorio.

Git create pull request

Enlaces de interés

Learn Git Branching

Git School

Sobre mí:

Jaime Perez 
Big Data Specialist
Jaime Pérez Aparicio
Big Data Specialist

Estudié física pero me gustaba mucho programar, así que decidí buscar nuevos retos que tuvieran que ver con ello. Por eso empecé a probar COBOL y el diseño web, hasta que descubrí el Big Data y el Machine Learning y me apasionaron (y lo siguen haciendo).


Sobre PUE

Como líder de Big Data, Cloud, Microservicios, NoSQL y DevOps en España, el objetivo de PUE es, siempre, ofrecer a sus clientes las mejores soluciones con las últimas tecnologías: soluciones innovadoras propuestas por un equipo técnico certificado, expertos en Administración, Analista de Datos, Científico de Datos y Desarrollo.

Para más información sobre los servicios de PUE:

Servicios y soluciones con PUE
Formación y certificación oficial

Contacta para saber más en:

mail consulting@pue.es icon-formSolicitud de información para la implantación de proyectos