En este tema vamos a ver sobre todo a tratar con ramas, merges y conflictos.

Mas información:

• Git Branching: Aprender Jugando con ramas en Git: Permite probar Git con ejemplos interactivos
• 17 Ways to Undo Mistakes with Git
• The Plumbing Guide: Comandos de bajo nivel de Git

El siguiente esquema muestra el sistema de ramas que se va a usar en clase. Mas información en A successful Git branching model

Ejemplo de Ramas

• Caos en las ramas
• Ramas lineales

Ramas a crear:

• develop: Lo que se ha desarrollando y el equipo de desarrollo dice que ya funciona. Cuando se quiera se pasa a release.
• release: Lo que se esta probando en un entorno similar al de producción. Cuando está probado, se copia a master.
• master: Lo que ya se puede instalar en el producción.
• rama de funcionalidad: Cada vez que alguien quiere hacer algo , crea una rama desde develop y cuando acaba la fusiona en develop.

Pasos a seguir para hacer una modificación.

• Crea la rama feature desde develop.
• Realizar la tarea con tantos commits como sea necesario.
• Mergear la rama develop en feature ya que así se resuelven los problemas de mergeo en la rama feature
• Ir a la rama develop y mergear la rama feature con –squash
• Borrar la rama feature
• Subir la rama develop
• Mergear la rama develop en release y subir release
• Mergear la rama release en master y subir master

Veamos ahora como se trabaja con ramas

• Crear una rama nueva y subirla

  git branch nuevaRama
  git switch nuevaRama
  git push --set-upstream origin nuevaRama
  git push -u             origin nuevaRama

• Bajar una nueva rama

  git fetch --prune   
  git switch nuevaRama

• Borrar una rama en local que ha sido mergeada o subida

  git branch --delete miRama
  git branch -d miRama

• Borrar una rama en local que NO ha sido mergeada ni subida (hay 3 formas distintas). Pero es usar el modificador -f o –force

  git branch --delete --force miRama
  git branch -d -f      miRama
  git branch -D         miRama

• Borrar una rama en remoto

  git push origin --delete miRama

El merge es unir los commit de una rama en otra. Hay muchas formas de hacer un merge , veamos algunas de ellas.

Pone los commits en la nueva rama siempre después de los que ya hay, es decir que los reordena.

Se usa para poner los commits de origin/develop en nuestra develop de antes que lo de develop porque hay commits distintos en cada rama pero del mismo commit origen

git commit -m "E"

git fetch –prune

git switch develop
git rebase origin/develop

Junta todos los "microcommits" de la rama en uno solo en la rama destino. Es necesario acto seguido el commit

Se usa para pasar los microcommits de una rama feature a develop

Solo adelanta el puntero de donde está la rama. Nunca crea nuevos commits en la rama destino pero falla si es necesario crear un nuevo commit,
por lo que –ff-only ayuda a detectar si hay algún problema.

Se usa De develop a Release.De release a master o para actualizar cualquier rama desde GitHub cuando no hay commits nuevos en local

git fetch –prune

git merge –ff-only origin/develop

Es el merge normal que puede crear nuevos commits | De una rama develop a feature.

Se usa para resolver los conflictos desde nuestra rama feature ya que nos da igual si hay nuevos commits

• Bajar (o actualizar) una rama ( como master, release o develop) desde Github,suponiendo que no va a haber problemas. Es decir que no hemos hecho nosotros un commit en ese rama desde la última vez que la bajamos.

  git fetch --prune
  git switch develop
  git merge --ff-only origin/develop

  git fetch --prune
  git switch release
  git merge --ff-only origin/release

  git fetch --prune
  git switch master
  git merge --ff-only origin/master

• mergear , develop en release o release en master (suponiendo que están actualizadas ambas ramas porque las hemos actualizado con las órdenes anteriores) y que no hemos hecho commits directamente ni en release ni en master.

  git switch release
  git merge --ff-only develop

  git switch master
  git merge --ff-only release

• Mergear (rebase) los cambios de origin/develop en nuestra develop si hay commits distintos en develop y origin/develop.

  git fetch --prune
  git switch develop
  git rebase origin/develop

Lo normal es hacer el rebase cuando al hacer un git push se produce el siguiente error:

 ! [rejected]        develop -> develop (fetch first)
error: falló el push de algunas referencias a 'https://github.com/usuario/repositorio.git'
ayuda: Actualizaciones fueron rechazadas porque el remoto contiene trabajo que
ayuda: no existe localmente. Esto es causado usualmente por otro repositorio 
ayuda: realizando push a la misma ref. Quizás quiera integrar primero los cambios
ayuda: remotos (ej. 'git pull ...') antes de volver a hacer push.
ayuda: Vea 'Notes about fast-forwards0 en 'git push --help' para detalles.

• Merge en develop de nuestra rama de feature con un solo commit con –squash (Antes hemos actualizado develop desde GitHub).

  git switch develop
  git merge  --squash lorenzo_42
  git commit -am "feat(#42):pantalla de Login"

• Mergear los cambios de develop en nuestra rama para ir solucionado los conflictos poco a poco (Antes hemos actualizado develop desde GitHub).

  git switch lorenzo_42
  git merge develop

logongas@beren:~/Documentos/ensenyament/2daw-daw/prueba_daw$ git pull
ayuda: Hacer un pull sin especificar cómo reconciliar las ramas es poco
ayuda: recomendable. Puedes eliminar este mensaje usando uno de los
ayuda: siguientes comandos antes de tu siguiente pull:
ayuda: 
ayuda:   git config pull.rebase false  # hacer merge (estrategia por defecto)
ayuda:   git config pull.rebase true   # aplicar rebase
ayuda:   git config pull.ff only       # aplicar solo fast-forward
ayuda: 
ayuda: Puedes reemplazar "git config" con "git config --global" para aplicar
ayuda: la preferencia en todos los repositorios. Puedes también pasar --rebase,
ayuda: --no-rebase, o --ff-only en el comando para sobreescribir la configuración
ayuda: por defecto en cada invocación.
ayuda: 

  git config --global pull.ff only

Mas información:

• Git: merge all changes from another branch as a single commit
• Squash commits when merging a Git branch with Bitbucket
• Handling merge conflicts with git rebase

En caso de hacer un git merge o un git rebase, etc. se puede producir un conflicto. Que consiste en que git no sabe como fusionar los ficheros. En ese caso lo primero es resolver cada conflicto en cada fichero.

Imaginemos el mismo fichero index.html en 2 ramas distintas:

<html>
	<body>
		<h1>Hola mundo</h1>
	</body>
</html>

<html>
	<body>
		<h1>Adios planeta</h1>
	</body>
</html>

Cuando se produce el conflicto, el fichero resultante queda de la siguiente forma:

  <html>
  	<body>
  <<<<<<< HEAD
  		<h1>Hola mundo</h1>
  =======
  		<h1>Adios planeta</h1>
  >>>>>>> Rama a Fusionar
  	</body>
  </html>

Ahora tenemos que decidir como resolver el conflicto que el resultado definitivo ya depende del código que estemos fusionando. Un posible resultado podría ser:

<html>
	<body>
		<h1>Hola y Adios mundo</h1>
	</body>
</html>

Imaginemos que queremos mergear la rama origin/develop sobre develop.

Si hay un conflicto se producirá el siguiente mensaje:

En primer lugar, rebobinando HEAD para después reproducir tus cambios encima de ésta...
Aplicando: feat(#50):Cabecera tercera
Usando la información del índice para reconstruir un árbol base...
M	index.html
Retrocediendo para parchar base y fusión de 3-vías...
Auto-fusionando index.html
CONFLICTO (contenido): Conflicto de fusión en index.html
error: Falló al fusionar en los cambios.
El parche falló en 0001 feat(#50):Cabecera tercera
Use 'git am --show-current-patch' para ver el parche fallido

Resuelva todos los conflictos manualmente ya sea con 
"git add/rm <archivo_conflictivo>", luego ejecute "git rebase --continue".
Si prefieres saltar este parche, ejecuta "git rebase --skip" .
Para abortar y regresar al estado previo al "git rebase", ejecuta "git rebase --abort".

Ahora debemos como antes arreglar el conflicto editando el fichero index.html pero ahora deberemos hacer dos cosas mas:

  git add index.html 
  git rebase --continue

Es decir añadir el fichero que ha dado el conflicto con un git add y luego hacer un git rebase –continue para que se acabe de fusionar.

El ejemplo completo lo podemos ver aquí:

git switch develop
git rebase origin/develop
vi index.html  #Arreglar el conflicto
git add index.html
git rebase --continue

Imaginemos que queremos mergear una rama de una funcionalidad llamada "Lorenzo_3" sobre develop.

Si hay un conflicto se producirá el siguiente mensaje:

Auto-fusionando index.html
CONFLICTO (contenido): Conflicto de fusión en index.html
Commit de squash -- no actualizando HEAD
Fusión automática falló; arregle los conflictos y luego realice un commit con el resultado.

Ahora debemos como antes arreglar el conflicto editando el fichero index.html y hacer el commit que de todas formas ya íbamos a hacer

  git commit -am "feat(#45):Nueva cabecera"

El ejemplo completo lo podemos ver aqui:

git switch develop
git merge --squash Lorenzo_3
vi index.html  #Arreglar el conflicto
git commit -am "feat(#45):Nueva cabecera"

Con un fast-forward nunca se puede producir un conflicto.

Imaginemos que queremos mergear los cambios de develop en la rama Lorenzo_3

Si hay un conflicto se producirá el siguiente mensaje:

Auto-fusionando index.html
CONFLICTO (contenido): Conflicto de fusión en index.html
Fusión automática falló; arregle los conflictos y luego realice un commit con el resultado.

Ahora debemos como antes arreglar el conflicto editando el fichero index.html y el –continue:

  git add index.html 
  git merge --continue

Es decir añadir el fichero que ha dado el conflicto con un git add y luego hacer un git merge –continue para que se acabe de mergear.

El ejemplo completo lo podemos ver aqui:

git switch Lorenzo_3
git merge develop
vi index.html  #Arreglar el conflicto
git add index.html 
git merge --continue

• Bajarse lo último de las 3 ramas.

git fetch --prune && git switch develop && git merge --ff-only origin/develop && git switch release && git merge --ff-only origin/release && git switch master && git merge --ff-only origin/master && git switch develop

• Hacer un merge de las 3 ramas

git switch release && git merge --ff-only develop && git switch master && git merge --ff-only release && git switch develop

• Subir las 3 ramas

git switch master && git push && git switch release && git push && git switch develop && git push

• Proceso completo para hacer una modificacion en la propia rama y ponerla en develop

#Día 1:Lunes
# Crear el issue. Tiene número 45
git fetch --prune && git switch develop && git merge --ff-only origin/develop && git switch release && git merge --ff-only origin/release && git switch master && git merge --ff-only origin/master && git switch develop
git branch lorenzo_45
git switch lorenzo_45
git push --set-upstream origin lorenzo_45
git commit -m "micro-commit-dia-1-a"
git push
git commit -m "micro-commit-dia-1-b"
git push
git commit -m "micro-commit-dia-1-c"
git push

#Día 2:Martes
git fetch --prune && git switch develop && git merge --ff-only origin/develop && git switch release && git merge --ff-only origin/release && git switch master && git merge --ff-only origin/master && git switch develop
git switch lorenzo_45
git merge develop
git commit -m "micro-commit-dia-2-a"
git push
git commit -m "micro-commit-dia-2-b"
git push
git commit -m "micro-commit-dia-2-c"
git push

#Día 3:Miercoles
git fetch --prune && git switch develop && git merge --ff-only origin/develop && git switch release && git merge --ff-only origin/release && git switch master && git merge --ff-only origin/master && git switch develop
git switch lorenzo_45
git merge develop
git commit -m "micro-commit-dia-3-a"
git push
git commit -m "micro-commit-dia-3-b"
git push
git commit -m "micro-commit-dia-3-c"
git push


#Día 4: Jueves
git fetch --prune && git switch develop && git merge --ff-only origin/develop && git switch release && git merge --ff-only origin/release && git switch master && git merge --ff-only origin/master && git switch develop
git switch lorenzo_45
git merge develop
git commit -m "micro-commit-dia-4-a"
git push
git commit -m "micro-commit-dia-4-b"
git push
git commit -m "micro-commit-dia-4-c"
git push


#Día 5: Viernes
git fetch --prune && git switch develop && git merge --ff-only origin/develop && git switch release && git merge --ff-only origin/release && git switch master && git merge --ff-only origin/master && git switch develop
git switch lorenzo_45
git merge develop

git switch develop
git merge --squash lorenzo_45
git commit -am "feat(#45):Crear la pantalla de login"
git push
#Si falla el push hacer el fetch y rebase
git fetch --prune 
git rebase origin/develop
git push 

git push origin --delete lorenzo_45
git branch --delete --force lorenzo_45

#Cerrar el issue 45

• Crea un proyecto de Git con dos ficheros
• Luego crea las siguientes tres ramas:
  • master
  • release
  • develop
• Sube las 3 ramas a GitHub.
• Desde develop ahora crea una rama llamada feature_40
• Añade un nuevo fichero a la rama feature_40 y modifica el fichero varias veces para crear varios "microcommits".
• Sube la rama feature_40
• Mergea la rama feature_40 en develop
• Borra la rama feature_40 en local
• Borra la rama feature_40 en remoto
• Mergea la rama develop en release
• Mergea la rama release en master
• Sube las ramas develop, release y master a GitHub

Vamos a seguir con el ejercicio anterior pero ahora con 2 usuarios distintos (se puede hacer en 2 carpetas distintas)

• Usuario 1:Desde develop ahora crea una rama llamada feat_50, añade un fichero y modifica el fichero varias veces para crear varios "microcommits". Sube la rama a GitHub
• Usuario 2:Desde develop ahora crea una rama llamada fix_51, añade otro fichero y modifica el fichero varias veces para crear varios "microcommits". Sube la rama a GitHub

• Usuario 1: Baja la rama develop de remoto
• Usuario 2: Baja la rama develop de remoto

• Usuario 1: Mergea la rama feat_50 en develop
• Usuario 2: Mergea la rama fix_51 en develop

• Usuario 1: Borra la rama feat_50 en local y en remoto
• Usuario 2: Borra la rama feat_51 en local y en remoto

• Usuario 1: Mergea la rama develop en release
• Usuario 1: Mergea la rama release en master
• Usuario 1: Sube las ramas develop, release y master a GitHub

• Usuario 2: Sube la rama develop a remoto. No te dejará.
• Usuario 2: Baja los cambios de develop en remoto y haz un rebase para mergearlos
• Usuario 2: Sube la rama develop a remoto. Ya te dejará.
• Usuario 2: Mergea la rama develop en release
• Usuario 2: Mergea la rama release en master
• Usuario 2: Sube las ramas develop, release y master a GitHub

Vamos a seguir con el ejercicio anterior pero ahora con 2 usuarios distintos (se puede hacer en 2 carpetas distintas).

• Usuario 1:Desde develop ahora crea una rama llamada feat_60, modifica un fichero y hazlo varias veces para crear varios "microcommits". Sube la rama a GitHub
• Usuario 2:Desde develop ahora crea una rama llamada feat_61, modifica el mismo fichero y en las mismas lineas y hazlo varias veces para crear varios "microcommits". Sube la rama a GitHub

• Usuario 1: Baja la rama develop de remoto
• Usuario 2: Baja la rama develop de remoto

• Usuario 1: Mergea la rama feat_60 en develop
• Usuario 2: Mergea la rama feat_61 en develop

• Usuario 1: Borra la rama feat_60 en local y en remoto
• Usuario 2: Borra la rama feat_61 en local y en remoto

• Usuario 1: Mergea la rama develop en release
• Usuario 1: Mergea la rama release en master
• Usuario 1: Sube las ramas develop, release y master a GitHub

• Usuario 2: Sube la rama develop a remoto. No te dejará.
• Usuario 2: Baja los cambios de develop en remoto y haz un rebase para mergearlos. Tendrás que solucionar el conflicto
• Usuario 2: Sube la rama develop a remoto. Ya te dejará.
• Usuario 2: Mergea la rama develop en release
• Usuario 2: Mergea la rama release en master
• Usuario 2: Sube las ramas develop, release y master a GitHub

Vamos a seguir con el ejercicio anterior pero ahora con 2 usuarios distintos (se puede hacer en 2 carpetas distintas).

• Usuario 1:Desde develop ahora crea una rama llamada feat_70, modifica un fichero y hazlo varias veces para crear varios "microcommits". Sube la rama a GitHub
• Usuario 1: Mergea la rama feat_70 en develop

• Usuario 2:Desde develop ahora crea una rama llamada feat_71, modifica el mismo fichero y en las mismas lineas y hazlo varias veces para crear varios "microcommits". Sube la rama a GitHub
• Usuario 2: Mergea la rama feat_71 en develop

• Usuario 2:Desde develop ahora crea una rama llamada feat_72, modifica el mismo fichero y en las mismas lineas y hazlo varias veces para crear varios "microcommits". Sube la rama a GitHub
• Usuario 2: Mergea la rama feat_72 en develop

• Usuario 1: Borra la rama feat_70 en local y en remoto
• Usuario 2: Borra la rama feat_71 en local y en remoto
• Usuario 2: Borra la rama feat_72 en local y en remoto

• Usuario 1: Mergea la rama develop en release
• Usuario 1: Mergea la rama release en master
• Usuario 1: Sube las ramas develop, release y master a GitHub

• Usuario 2: Sube la rama develop a remoto. No te dejará.
• Usuario 2: Baja los cambios de develop en remoto y haz un rebase para mergearlos. Tendrás que solucionar varias veces el conflicto ya que había varios commits pendientes.
• Usuario 2: Sube la rama develop a remoto. Ya te dejará.
• Usuario 2: Mergea la rama develop en release
• Usuario 2: Mergea la rama release en master
• Usuario 2: Sube las ramas develop, release y master a GitHub

Crea un nuevo proyecto en Git.

• Usuario 1:Crea una rama llamada prueba y la subes a Git
• Usuario 2: Haz un Pull y comprueba que existe la rama origin/prueba en local y prueba en remoto

• Usuario 1: Borra la rama prueba en local
• Usuario 2: Haz un Fetch y comprueba que aun está la rama origin/prueba en local y prueba en remoto

• Usuario 1: Borra la rama prueba en remoto
• Usuario 2: Fetch (SIN PRUNE) y comprueba que aun está la rama origin/prueba en local pero ya NO está prueba en remoto
• Usuario 2: Fetch (CON PRUNE) y ya NO está la rama origin/prueba en local