Distributed Version Control
Local y Remoto
Si queremos trabajar en equipo en nuestro código es necesario compartir el repositorio, para ello existen varias entidades como github que nos ayudan a distribuirlo en las maquinas de cada uno de los colaboradores (peers)
De esta manera se obtiene el repositorio desde una maquina (tener en cuenta que existen repositorios privados que requieren ciertos permisos para obtenerlos).
Se descargan los archivos, el modelo git de base de datos de nuestro proyecto y un archivo particular .git/config
Se pueden tener varios repositorios remotos, pero cuando se hace clone el repositorio por primera vez git asigna el por defecto [remote "origin"] El archivo también describe que contamos con un branch principal [branch "master"]
Si se consulta las ramas del repositorio desde la maquina:
pero si adicionamos el flag --all podremos visualizar todas las ramas
incluye todas las referencias incluyendo las que están en el control remoto, branches remotas y la posición actual de HEAD
Descubriendo los branch del repositorio
Para descubrir los branch del repositorio descargado:
como se puede observar tenemos dos master, una es la local y la otra es la master remota, pero están apuntando al mismo commit (hash), están sincronizadas, se pueden hacer commits a la local y posteriormente se puede actualizar la remota con un push command
Nuevos commit en local branch
Cuando creamos un nuevo commit en el local branch, es decir un nuevo cambio y consultamos las referencias:
notamos que el branch local tiene un hash diferente al repositorio remoto.
Ahora podemos sincronizar el branch remoto:
podemos consultar nuevamente las referencias de master:
y se ha actualizado y el branch ahora apunta al último commit.
Push desde otro peer
Se pueden presentar conflictos en el momento de hacer push al branch remoto, por que puede que otro peer (otra maquina o compañero del proyecto) haya hecho un push de uno o mas commit con antelación.
Con git se debe tener un orden especifico para el trabajo en equipo, para el escenario anterior se puede resolver de dos maneras, la primera y no muy recomendada:
el flag "-f" hace que se force el merge, pero esto puede traer mas conflictos entre los commit. La segunda forma es hacer fetch antes de hacer push a la rama remota:
asi se tiene en cuenta los commit que otros peers han hecho en la rama remota, y se puede proceder a hacer un merge antes del push de los commits locales:
existe un comando que resume dos: el git fetch y el git merge en mi local branch y es:
esta acción hace fetch y merge en mi local branch, posteriormente y si se resulven los conflictos si los hay se puede hacer:
Last updated
Was this helpful?