Repo para la charla de git workshop.
Instrucciones para instalar y configurar la última versión estable de git.
Para instalar la última versión de git es necesario tener homebrew primero. Luego, basta con abrir un terminal y ejecutar lo siguiente:
brew update && brew install git
Podemos verificar que contamos con la última versión ejecutando lo siguiente:
git --version
git version 1.8.5.2
Cualquier cosa por encima de 1.8.5 quiere decir que no estamos utilizando el binario provisto por defecto en OS X.
Para setear el username y password de forma global:
git config --global user.name gfestari
git config --global user.email gf@email.com
Reemplazar con las credenciales apropiadas ;)
Configuración con algunos tweaks prácticos para mejorar el gitflow.
Este repo cuenta con un archivo gitconfig de configuración con unos settings por defecto y aliases útiles para git.
La idea es que tomen prestado algunas de las configuraciones y aliases para hacer que el trabajo desde el terminal sea más sencillo.
El repo cuenta con un script que automatiza la copia del archivo de configuración de git. Para utilizarlo, basta con clonar el repo:
git clone https://github.com/gfestari/workshop.git
cd workshop
Y ejecutar el script install.sh, teniendo la precaución de haber actualizado previamente las las variables username e email con nuestras respectivas credenciales de GitHub:
username=gfestari
email=gaston.festari@email.com
Guardar los cambios al script, y ejecutarlo de la siguiente manera:
sh install.sh
Y listo.
Algunos atajos prácticos que van a poder utilizar después de ésto:
| comando | efecto |
|---|---|
| `git l` | log con grafo |
| `git cm "Mensaje de commit"` | idem a realizar `git commit -m "Mensaje de commit"` |
| `git news` | revisa qué cambios hay de nuevo en el repo |
| `git d viejo nuevo` | diff para comparar archivos, commits, etc. |
| `git pl` | `git pull --ff-only` una de las maneras indicada en el gitflow para hacer los `pull` |
| `git s` | git status |
| `git sb` | versión compacta de lo anterior |
| `git stache` | versión hipster de `stash` |
| `git alias` | imprime esta lista por extensión :P |
Flujo de trabajo sujerido para utilizar git.
Remember:
- NO REESCRIBIR EL HISTORIAL PÚBLICO
- NO HACER
amendDE COMMITS PUSHEADOS - NO HACER
rebaseDE COMMITS PUSHEADOS
Crea y cambia nuestra ref a un branch llamado topic-branch:
git checkout -b topic-branch
Una vez hechos los cambios en topic-branch, podemos actualizar develop con los cambios de upstream:
# [opcional] git checkout develop
git pull --rebase origin develop
Alternativamente, podemos hacer un forward-merge:
git pull --ff-only
E incorporar los cambios en upstream sin reescribir el histórico.
Cuándo conviene hacer un rebase?
- Necesitamos re-aplicar nuestros cambios sobre los cambios entrantes (upstream)
- El historial se mantiene más limpio
- Muchas veces es más sencillo no hacer
mergede los cambios en upstream - Los changesets más pequeños son más sencillos de visualizar
Conviene hacer un merge --ff-only cuando estamos lidiando con cambios permanentes que aplican a largo plazo.
Con la ref al día de lo que sucede upstream, cambiamos a nuestro topic-branch para actualizarlo con los cambios que sucedieron en develop:
git checkout feature-a
git rebase -i develop
Con los cambios de develop replicados en nuestro topic-branch podemos continuar trabajando.
Una vez completa la funcionalidad, volvemos a develop
git checkout develop
git merge feature-a
Como alternativa al rebase de develop (punto anterior), podemos hacer directamente un rebase de feature-a en develop:
git checkout develop
git rebase -i feature-a
Y subimos los cambios al branch develop en upstream de la siguiente manera:
git push origin develop
Finalmente, eliminamos el topic-branch que generamos localmente:
git checkout -d topic-branch
Alternativamente, podemos utilizar el flag -D para eliminar un branch que no fue mergeado íntegramente:
git checkout -D topic-branch
Para eliminar un branch remoto compartido en el repo upstream, basta con ejecutar lo siguiente:
git push origin :nombre_del_branch_eliminar
CUIDADO con los branches públicos compartidos que aún no han sido mergeados en develop.
Muchas veces, interesa crear y compartir nuevos branches con el resto del equipo.
De la siguiente manera, empujamos nuestro branch llamado local-branch a un remoto, bajo el nombre remote-branch:
git push -u origin local_branch:remote_branch
Para crear y conectar un branch local con uno existente upstream, basta con ejecutar la siguiente línea:
git checkout -b test origin/test
Esto crea y conecta el branch test con el remoto existente en origin/test
Aplicamos el hotfix a partir de un branch hotfix que deriva de master:
git checkout -b hotfix
# implementar hotfix
git checkout master
git merge hotfix
Una vez implementado y probado el cambio en producción, necesitamos replicar los cambios en develop.
Para ello, revisamos el histórico para obtener el id del commit que vamos a replicar:
git checkout master
git pull --ff-only
git log --color --graph --pretty --abbrev-commit
Esto nos proporciona el siguiente tree:
* 7a9b386 gfestari: Add ST git packages - (2 days ago)
* 592198d gfestari: Add warnings - (2 days ago)
Nos interesa realizar un backport de 592198d en develop. Para esto vamos a ejecutar un cherry-pick
sobre el commit:
git checkout develop
git cherry-pick 592198d
De esta manera, git re-aplica los mismos cambios sobre develop, sin forzar merges o integraciones innecesarias.
Configuración de SublimeText 3 para utilizar desde la línea de comando y como $EDITOR por defecto del sistema.
Esto permite utilizar el comando subl desde el terminal para invocar a SublimeText.
Generar el siguiente enlace simbólico desde un terminal:
ln -s "/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl"
Editar ~/.bashrc - o ~/.zshrc si utilizan zsh - y agregar la siguiente línea:
export EDITOR='subl -w'
Alternativamente, pueden ejecutar la línea en el terminal para contar con una solución temporal.
Si están utilizando Package Control con ST, se recomiendan los siguientes plugins:
Generar un histórico lineal en el repo de ejemplo de @vierja para ello, deberían:
- Hacer un fork del repo
- Corregir el histórico para lograr un grafo lineal (utilizar
rebase,mergeycommitsegún sea necesario) - Una vez que cuenten con el grafo lineal, hacer un pull request para proponer una respuesta al problema