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
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
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:
Se busca tener esto:
De forma que todos los cambios estén en un mismo commit.
Solución
Se hace un rebase interactivo de los 3 últimos commits: git rebase -i HEAD~3
Se coge el más antiguo con pick(p) (el de más arriba) y los otros dos con squash(s):
Ahora, al haber puesto squash, se permite modificar el commit inicial para añadirle información:
Ahora al guardar ya se tendrán los 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):
Al seleccionar Create pull request le llegará una notificación al dueño del repositorio.
Enlaces de interés
Sobre mí:
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:
consulting@pue.es 
Solicitud de información para la implantación de proyectos
