Git en Equipo

git.md

Empezando

• Cómo traigo los cambios? git fetch vs git pull
• Qué es origin? git remote add git remote -v
• De donde vienen los cambios? git branch --set-upstream-to=origin/branchname, git push --set-upstream origin branchname
• Cómo llevo mis cambios? git push, git push --force, git push --force-with-lease

Commits

• Por qué nos importan los historiales? Queremos dar contexto
  • Decir el por qué y no el cómo
• Ser atómico y conciso
  • Si revierto este commit, revierto mi cambio?
  • Estoy agregando ruido?
    • git diff HEAD siempre
    • git add . nunca
  • Menos de 50 caracteres
• Hacer un commit buscable
  • git log --grep "string"
  • git blame archivo -L 1,5
• Es lineal?
  • Es el código un desarrollo lineal? No! Pero hagamos lo mejor que podamos
  • git rebase -i master
• Evitar usar ANDs
  • En vez de 'Este commit arregla X y Z' -> hacer dos commits
  • git add --patch ayuda un monton
• Evitar hacer arreglos en el camino
  • git stash -> hago el commit intermedio -> git stash pop
• Darle órdenes al código (usar el modo imperativo)
  • Llenar la frase "This commit will x"
    • Merge This
    • Fix that
    • Fixes bug
    • Added logic
• Necesito aún más contexto? Agregar alguna referencia?
  • git commit -m "Summary" -m "Body"

When in Rome, do as the Romans do

• Que queremos? Consistencia!
• Cuando lo queremos? Absolutamente siempre!
• Me metí a un proyecto nuevo
  • Tienen alguna convención con el nombre de las branches?
  • Tienen alguna convención con el mensaje del commit?
  • Donde esta el contexto? En Git, en los pull requests, en el project tracker?
• Less is more
  • No agregar cambios triviales -> Buscar automatizarlos
  • No hacer code dumps -> Buscar cambios progresivos
  • El commit perfecto es cherry-pickeable
• Hay algun branching model como git flow o github flow?

Code Reviewing

Revisando

• Mundo ideal: Bajar los cambios, probarlos, revisarlos
• Parece joda, pero... ser cortés
• Darle el beneficio de la duda al programador
  • Por algo estará programado así
  • Preguntar, no asumir
• Revisar código de forma activa
  • Sugerir, no decir
• Mi pedido es algo bloqueante?
• Como lo pensó? -> Leer el historial de commits!

Siendo Revisado

• Separar el codigo del ego -> No es mí PR, es un PR
• Dar un paso para atras y revisar mi propio PR
  • Dejar comentarios en el código con mayor impacto
  • Explicar la mejor manera de revisarlo
• No explicarle a quien revisa, explicarle a toda persona que lee el código
• Darle todos los empates a quien revisa -> tienen mejor perspectiva y menos contexto

Merge Strategies

Merge

• Explicito
• Agrega un commit
• Seguro
• 100% fiel al historial

Rebase

• Implicito
• Deja un historial ordenado y lineal
• Reescribe el historial y deja de ser sincero al original
• Nos fuerza a pushear
  • Recordar siempre usar git push --force-with-lease!

Golden Rule of rebasing: never use it on public branches

Cómo lo hace Github?

• Merge: un merge explícito sin fast forward
• Squash and Merge: juntar todo el PR en un commit y mergearlo
• Rebase and Merge: se rebasea contra master y luego se hace un merge con fast forward

¿y qué es un squash?

• Junta todo feature en un solo commit
• La main branch queda más limpia
• Pero, para que me preocupe por los commits individuales?
• Como se pensó la branch?

¿y qué es un merge con fast-forward?

• Si las historias no divergieron y puedo llegar de un commit a otro, simplemente muevo la referencia y evito el merge commit extra (adelanto/fastforwardeo la historia de una branch)
• Cómo lo evito? git merge --no-ff