IBM SkillsBuild | Introducción a Python
Git y Github
Branch, Merge y conflictos
1
IBM SkillsBuild | Introducción a Python
Índice
Branch 3
Crear un Branch 4
Merge 6
Conflictos 6
2
IBM SkillsBuild | Introducción a Python
Branch
Cada programador creará una rama desde la rama
principal, trabajará en ella haciendo los cambios o
implementaciones que necesite y cuando haya
acabado fusionará su rama con la rama principal. De
Las ramas o Branchs son líneas de tiempo que
modo que, al final, en la rama principal quedarán
estarán conformadas por todos los “commits” que
reflejadas todas las implementaciones de todo el
hemos ido haciendo a lo largo de la evolución de
equipo de programadores.
nuestro proyecto.
La creación de ramas es una función disponible en la
mayoría de los sistemas de control de versiones
Cada programador podrá crear una rama (una
modernos.
“copia”) del proyecto. De tal manera que podremos
La creación de ramas en otros sistemas de control de trabajar tanto en el original como en la copia.
versiones puede tanto llevar mucho tiempo como
Lo ideal es trabajar en la copia y una vez que
ocupar mucho espacio de almacenamiento.
tenemos la certeza de que nuestro trabajo está
En Git, las ramas son parte del proceso de desarrollo perfecto y que no da fallos, lo “inyectamos” en la
diario. Las ramas de Git son un puntero eficaz para rama master.
las instantáneas de nuestros cambios. Cuando
A efectos prácticos es como si nuestro proyecto se
queremos añadir una nueva función o solucionar un
dividiera en varios proyectos y cada uno de ellos
error, independientemente de su tamaño, generamos
trabajase de forma totalmente independiente. Una
una nueva rama para alojar estos cambios. Esto hace
vez que cada “sub-proyecto” está terminado, lo
que resulte más complicado que el código inestable
fusionamos con la rama principal.
se fusione con el código base principal, y nos da la
oportunidad de limpiar nuestro historial futuro antes Tenemos además la ventaja de que, si cometemos
de fusionarlo con la rama principal. algún fallo en el código de la rama secundaria,
podemos detectarlo y corregirlo antes de fusionar
La rama principal de un proyecto es la rama master.
con la rama master. De esta forma la rama master
Por defecto es la rama en la que se empieza a
siempre estará libre de errores.
trabajar.
Cuando se están modificando archivos diferentes en
Nosotros hemos estado trabajando hasta ahora en
cada rama no suele haber problemas, pero si varios
esta rama master.
programadores están modificando el mismo archivo
Pero GitHub nos da la posibilidad de que podamos en diferentes ramas, puede haber problemas de
trabajar en varias ramas simultáneamente. Esto es concurrencia.
muy útil para que varios programadores trabajen de
forma simultánea sin pisarse unos a otros.
3
IBM SkillsBuild | Introducción a Python
Imaginemos que en la rama master modificamos el Para movernos a la rama secundaria usaremos el
archivo index.html en la línea 70 y que en la rama comando:
secundaria modificamos igualmente el mismo
git checkout nombreRama
archivo en la misma línea. A la hora de fusionar
ambos cambios, ¿cuál prevalece? En este caso Git miPC@miPC MINGW64 /g/WORKSPACE/011
GitHub/Proyecto GIT (master)
nos indicará que hay un conflicto de concurrencia, ya
que se está modificando exactamente lo mismo $ git checkout segundaRama
(mismo archivo y misma línea) en diferentes ramas y Switched to branch 'segundaRama'
nos permitirá elegir con cual quedarnos.
Si volvemos a hacer un git branch:
Crear un Branch miPC@miPC MINGW64 /g/WORKSPACE/011
GitHub/Proyecto GIT (master)
Para crear una rama deberemos usar el comando $ git Branch
Branch y especificar el nombre que le queremos dar
main
a la rama: * segundaRama
miPC@miPC MINGW64 /g/WORKSPACE/011 Podemos comprobar que ya estamos en la
GitHub/Proyecto GIT (master)
segundaRama.
$ git branch segundaRama
A partir de este momento cualquier cambio que yo
Ya tenemos creada nuestra rama. Si hacemos un git
haga en mi código se verá reflejado únicamente en la
log -oneline para ver el estado de nuestro proyecto:
rama secundaria. Los archivos de la rama master no
miPC@miPC MINGW64 /g/WORKSPACE/011 sufrirán ningún cambio.
GitHub/Proyecto GIT (master)
$ git log –oneline Si hiciésemos algún cambio en el contenido del
28746f5 (HEAD -> main, tag: V1.0.3, archivo index.html, por ejemplo, deberíamos ejecutar
origin/main, origin/HEAD, segundaRama) un add y un commit. Como vimos anteriormente
Update index.html
75d4418 Version 1.0.3 podemos hacer ambas operaciones a la vez con el
fd8ada9 Version 1.0.2
093f1c5 Version 1.0.0 comando:
00350f8 Version 1.0.0
git commit -am “descripción”
Podemos ver que ya hay una referencia a nuestra
miPC@miPC MINGW64 /g/WORKSPACE/011
nueva rama (llamada segundaRama). GitHub/Proyecto GIT (master)
$ git commit -am "Versión 1.0.5"
Con el comando git branch veremos las ramas del
proyecto y en qué rama nos encontramos: [segundaRama a1bd1cc] Versión 1.0.5
miPC@miPC MINGW64 /g/WORKSPACE/011 1 file changed, 2 insertions(+)
GitHub/Proyecto GIT (master)
$ git branch Ya tenemos un primer cambio hecho en la rama
secundaria.
* main
segundaRama
4
IBM SkillsBuild | Introducción a Python
Pero la rama principal no va a reflejar dichos
cambios. De hecho, si ahora nos moviésemos a la
rama master, los cambios que acabamos de hacer no
se verían en el archivo index.html. Y si hacemos un
git log –oneline en la rama master, no nos saldrá el
commit que hemos hecho en la rama secundaria. Es
decir, tanto los commits como los cambios en los
archivos que hagamos en las ramas extra no serán
vistos desde otra rama, ni siquiera desde la principal.
Para borrar una rama que tengamos creada:
git branch -d “nombre de mi rama”
miPC@miPC MINGW64 /g/WORKSPACE/011
GitHub/Proyecto GIT (master)
git branch -d segundaRama
Deleted branch segundaRama (was
407013f).
5
IBM SkillsBuild | Introducción a Python
Merge Conflictos
Con el comando merge podremos fusionar una rama Vamos a insertar código en la misma línea de la rama
extra que hubiésemos creado con anterioridad a la master y de la secundaria. Al hacer el merge, Git
rama master. detectaría el conflicto y nos sacaría por consola un
mensaje como este:
miPC@miPC MINGW64 /g/WORKSPACE/011
GitHub/Proyecto GIT (master)
$ git merge segundaRama
Auto-merging index.html
CONFLICT (content): Merge conflict in
index.html
Automatic merge failed; fix conflicts
En nuestro proyecto teníamos creada una rama extra and then commit the result.
a la que habíamos llamado ramaSecundaria. Para
fusionar esta rama con la master deberíamos usar el
comando merge junto con al nombre de la rama que Nos está diciendo que hay conflictos, que los
queramos fusionar. arreglemos manualmente y que luego volvamos a
hacer el merge.
Lo primero es movernos a la rama master. Cualquier
merge que queramos hacer lo tendremos que hacer Y en nuestro IDE nos saldrá también un mensaje que
siempre desde la rama master. En nuestro caso, a la nos avisa del problema:
rama master la habíamos llamado main.
miPC@miPC MINGW64 /g/WORKSPACE/011
GitHub/Proyecto GIT (master)
$ git checkout main
Switched to branch 'main'
Your branch is up to date with
'origin/main'.
miPC@miPC MINGW64 /g/WORKSPACE/011 Vemos como Visual Studio nos detecta el problema y
GitHub/Proyecto GIT (master)
nos da la opción de aceptar una u otra versión,
$ git merge segundaRama compararlas, aceptar ambas…etc.
Updating 28746f5..a1bd1cc
Fast-forward Ahora tendríamos que decidir con qué versión nos
index.html | 2 ++
1 file changed, 2 insertions(+) quedamos, guardar, hacer el commit y luego el
merge.
Los cambios que hicimos en nuestro index.html
fueron en una línea en la que nadie más estaba
trabajando. Pero supongamos que hacemos un
cambio desde la rama secundaria en una línea y que
otro programador ha hecho un cambio en la misma
línea de la rama máster.
