nuestro de cada día
Nociones y algo más
Alan Descoins
Tryolabs, 2014
Objetivos
● Entender mejor lo que hacemos diariamente
● Hacer menos preguntas (entender el man)
● Mejorar algunas práctica...
Orígenes y filosofía
● 2005, kernel de Linux
● Eficiencia, diseño simple
● Desarrollo no lineal (miles de
branches en para...
Distribuído
● Casi toda operación es
local
● Todas las máquinas
tienen TODA la
información
● Contraste SVN, CVS,
etc.
Algo de teoría
● git init inicializa un repositorio
● Crea un único directorio .git en la raíz (no contamina)
● Mini files...
Git y el contenido
● Tracking de contenido, NO archivos
● Vocabulario: tracked / untracked
● Objetos de git
○ Blob (conten...
Blob
● Un archivo por “contenido”
● SHA-1 del contenido (zlib) + un
header
● Inicialmente, loose object
● Luego packfile (...
Tree
● Como una estructura de
directorios
● Punteros a blobs u otros trees
● Representa un snapshot
completo del estado
● ...
Commit
● Información sobre los trees
● Quién, cuándo, por qué guardó el tree
● Apunta al tree de “más arriba” (top level) ...
Commit (2)
Tags
● Puntero a un commit
● Información adicional, firma
● Para no tener que acordarse del
SHA-1...
La santa Trinidad
Un contenido puede estar en tres estados
● Committed
● Modified
● Staged
La santa Trinidad (2)
Tres partes un proyecto:
● Working directory
● Staging area (o index)
● .git (repository)
Comandos básicos
● git add - agrega al index (staging)
● git commit - guarda el index actual con el autor,
mensaje, fecha,...
Saltear el staging
● A veces, puede ser más fácil saltear el
staging
● git commit -a | git commit <archivo>
● Agregan auto...
Branches
● Simplemente un puntero a un commit
● Tan rápido como escribir 41 caracteres a un
archivo (SHA-1 + n)
● Por defe...
Branches (2)
● git checkout
para cambiarse
de branch
Referencias
● El puntero HEAD es un caso particular
● Los tags también: “una branch inamovible”
(lightweight tags)
Ejemplo...
Remotes
● No hay servidor central
● Se pueden agregar varios remotes, copias
externas del repositorio (URL)
● El famoso or...
Branches remotas
● Guardan el estado de las branches en los repositorios
remotos
● Son locales, pero no se pueden mover; s...
Fetch, push
● git fetch - sincroniza y actualiza branches remotas
(mueve punteros)
● Ej. git fetch <remote>
● git pull - e...
Tracking branches
● Branches locales pueden “seguir” remotas
● Dos posibilidades:
○ git checkout --track <remote>/<branch>...
Merges
● Fast-forward: git es
inteligente y solo necesita
mover un puntero
● Integrar cambios de una branch en otra
Merges (2)
● Three way merge: commit no es ancestro
directo de lo que se mergea (no lineal)
● Git determina el mejor ances...
Three way merge
Rebasing
● Otra forma de introducir cambios de una
branch en otra
● Rewind & replay, reescribe los commits
● A partir de u...
Rebasing (2)
● git rebase <new-base>
mueve los commits de la
branch actual a la nueva
base
● git rebase -i <new-base>
sele...
Reglas doradas
● Nunca hacer rebase de una branch que está
pusheada, o pulleaste de otra persona
○ Commits duplicados si s...
Rebase vs Merge
¿Por qué rebase?
● Historial limpio
● Colaboración open-source, muchos lo exigen
● Más fácil code review
¿...
git reset
● Se usa a menudo
● Mal usado, puede generar pérdida de
datos (workdir unsafe)
● Tres opciones más usadas:
○ --s...
git reset...
● mueve la branch a la que apunta HEAD para que
apunte al commit destino (frena si --soft)
● luego hace que e...
Ejemplos git reset
● Con HEAD en branch dev, hago git reset master
○ ahora dev y master apuntan al mismo commit
● Con HEAD...
Unstaging de archivos
● Al hacer git reset <file> no especifica branch
ni commit SHA
● Equivalente a git reset --mixed HEA...
git checkout
● git checkout <branch> es superficialmente
parecido a git reset --hard <branch>
● Dos diferencias:
○ Workdir...
git checkout de archivo
● git checkout <branch> <file>
○ Al igual que reset, ahora no tiene sentido que mueva
HEAD. Reempl...
Situaciones comunes (1)
● “Necesito hacer pull pero tengo cambios en
los que estoy trabajando y no quiero
commitear todaví...
Situaciones comunes (2)
● “Hay un bug en una branch, necesito saber
qué commit lo introdujo”
○ git bisect
○ Búsqueda binar...
Situaciones comunes (3)
● “Hice uno (o varios) commits en la branch
equivocada, todavía no pushee!”
○ Si la branch correct...
Situaciones comunes (4)
● “Tengo muchos cambios en un archivo y
solo quiero comittear parte de ellos”
○ git add -p o git c...
Situaciones comunes (5)
● “Necesito cambiar unos commits”
● “Necesito borrar unos commits”
● “Necesito cambiar de orden un...
Situaciones comunes (6)
● “Estoy haciendo un merge con muchos
conflictos y quiero volver a como estaba
antes de comenzarlo...
(Imágenes de git-scm y demás ;) )
No aprendió git
Upcoming SlideShare
Loading in …5
×

El git nuestro de cada dia

692 views
557 views

Published on

Nociones de git, comandos importantes y casos de uso.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
692
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

El git nuestro de cada dia

  1. 1. nuestro de cada día Nociones y algo más Alan Descoins Tryolabs, 2014
  2. 2. Objetivos ● Entender mejor lo que hacemos diariamente ● Hacer menos preguntas (entender el man) ● Mejorar algunas prácticas ● Cometer menos errores ● Hacer algo super puntual ;)
  3. 3. Orígenes y filosofía ● 2005, kernel de Linux ● Eficiencia, diseño simple ● Desarrollo no lineal (miles de branches en paralelo) ● Completamente distribuído
  4. 4. Distribuído ● Casi toda operación es local ● Todas las máquinas tienen TODA la información ● Contraste SVN, CVS, etc.
  5. 5. Algo de teoría ● git init inicializa un repositorio ● Crea un único directorio .git en la raíz (no contamina) ● Mini filesystem ● Snapshots, no diferencias!
  6. 6. Git y el contenido ● Tracking de contenido, NO archivos ● Vocabulario: tracked / untracked ● Objetos de git ○ Blob (contenido) ○ Tree (estructura) ○ Commit (apunta a un tree, + data) ○ Tag (apunta a un commit, + data) SHA-1
  7. 7. Blob ● Un archivo por “contenido” ● SHA-1 del contenido (zlib) + un header ● Inicialmente, loose object ● Luego packfile (eficiencia, heurísticas…) ● Ejemplo: find .git/objects -type f
  8. 8. Tree ● Como una estructura de directorios ● Punteros a blobs u otros trees ● Representa un snapshot completo del estado ● Ejemplo: git ls-tree <sha-1>
  9. 9. Commit ● Información sobre los trees ● Quién, cuándo, por qué guardó el tree ● Apunta al tree de “más arriba” (top level) del proyecto ● Jerarquía de árbol ● También SHA-1, diferente hash que el tree al que apunta
  10. 10. Commit (2)
  11. 11. Tags ● Puntero a un commit ● Información adicional, firma ● Para no tener que acordarse del SHA-1...
  12. 12. La santa Trinidad Un contenido puede estar en tres estados ● Committed ● Modified ● Staged
  13. 13. La santa Trinidad (2) Tres partes un proyecto: ● Working directory ● Staging area (o index) ● .git (repository)
  14. 14. Comandos básicos ● git add - agrega al index (staging) ● git commit - guarda el index actual con el autor, mensaje, fecha, etc. ● git status - muestra los archivos con diferencias en working dir, staging, y los untracked ● git diff - lo que cambió pero no está staged ● git diff --cached - lo que va para el próximo commit ● git log
  15. 15. Saltear el staging ● A veces, puede ser más fácil saltear el staging ● git commit -a | git commit <archivo> ● Agregan automáticamente al staging, luego commitean
  16. 16. Branches ● Simplemente un puntero a un commit ● Tan rápido como escribir 41 caracteres a un archivo (SHA-1 + n) ● Por defecto master ● Puntero especial HEAD (branch actual) ● Ejemplo: cat .git/HEAD
  17. 17. Branches (2) ● git checkout para cambiarse de branch
  18. 18. Referencias ● El puntero HEAD es un caso particular ● Los tags también: “una branch inamovible” (lightweight tags) Ejemplo: find .git/refs
  19. 19. Remotes ● No hay servidor central ● Se pueden agregar varios remotes, copias externas del repositorio (URL) ● El famoso origin :)
  20. 20. Branches remotas ● Guardan el estado de las branches en los repositorios remotos ● Son locales, pero no se pueden mover; solo cuando se hacen operaciones en la red (ej. git fetch). ● Forma <remote>/<branch> Ejemplo: cat .git/refs/remotes/origin/master
  21. 21. Fetch, push ● git fetch - sincroniza y actualiza branches remotas (mueve punteros) ● Ej. git fetch <remote> ● git pull - equivalente a git fetch y luego git merge, mergea la branch local con cambios en la remota ● git push - actualiza branch remota con lo local ● Ej. git push <remote> <branch>
  22. 22. Tracking branches ● Branches locales pueden “seguir” remotas ● Dos posibilidades: ○ git checkout --track <remote>/<branch> ○ git push --set-upstream <remote> <branch> ● Así, al pushear no hay que escribir el nombre del remote y la branch :)
  23. 23. Merges ● Fast-forward: git es inteligente y solo necesita mover un puntero ● Integrar cambios de una branch en otra
  24. 24. Merges (2) ● Three way merge: commit no es ancestro directo de lo que se mergea (no lineal) ● Git determina el mejor ancestro común ● Se crea un merge commit, especial pues tiene más de un padre ● Conflictos...
  25. 25. Three way merge
  26. 26. Rebasing ● Otra forma de introducir cambios de una branch en otra ● Rewind & replay, reescribe los commits ● A partir de un ancestro común ● Historia queda siempre lineal, más allá de que originalmente fue en paralelo
  27. 27. Rebasing (2) ● git rebase <new-base> mueve los commits de la branch actual a la nueva base ● git rebase -i <new-base> selecciona acciones para cada commit ● git pull --rebase
  28. 28. Reglas doradas ● Nunca hacer rebase de una branch que está pusheada, o pulleaste de otra persona ○ Commits duplicados si se hace merge ○ Discutible: si la branch remota la usa solo uno a modo de backup. ○ Usar git push --force, si se sabe que otros developers no trabajan en la branch. ● Si se hace rebase para traer cambios de otros developers al local, hacerlo tan seguido como sea posible.
  29. 29. Rebase vs Merge ¿Por qué rebase? ● Historial limpio ● Colaboración open-source, muchos lo exigen ● Más fácil code review ¿Por qué merge? ● Más fácil solucionar conflictos ● Menor riesgo
  30. 30. git reset ● Se usa a menudo ● Mal usado, puede generar pérdida de datos (workdir unsafe) ● Tres opciones más usadas: ○ --soft ○ --mixed ○ --hard
  31. 31. git reset... ● mueve la branch a la que apunta HEAD para que apunte al commit destino (frena si --soft) ● luego hace que el staging se vea como eso (frena si -- mixed, opción por defecto) ● luego hace que el working dir se vea como eso (si -- hard, es workdir usafe!)
  32. 32. Ejemplos git reset ● Con HEAD en branch dev, hago git reset master ○ ahora dev y master apuntan al mismo commit ● Con HEAD en branch master, hago git reset --hard origin/master ○ ahora mi branch master es idéntica a la remote (descartar cambios locales) ● git reset --soft HEAD~ ○ Deshace el último commit sin perder cambios
  33. 33. Unstaging de archivos ● Al hacer git reset <file> no especifica branch ni commit SHA ● Equivalente a git reset --mixed HEAD <file> ● Saca un archivo particular del staging, opuesto de git add :)
  34. 34. git checkout ● git checkout <branch> es superficialmente parecido a git reset --hard <branch> ● Dos diferencias: ○ Workdir safe! :D Chequea por pérdida de datos. ○ reset mueve la branch a la que apunta HEAD, checkout mueve el puntero HEAD.
  35. 35. git checkout de archivo ● git checkout <branch> <file> ○ Al igual que reset, ahora no tiene sentido que mueva HEAD. Reemplaza solamente <file> en workdir (workdir usafe!). ○ Sería lo mismo que git reset --hard <branch> <file> ○ Pero ese comando no existe :)
  36. 36. Situaciones comunes (1) ● “Necesito hacer pull pero tengo cambios en los que estoy trabajando y no quiero commitear todavía” ○ git stash ○ Es un stack ○ Vaciarlo con git stash pop.
  37. 37. Situaciones comunes (2) ● “Hay un bug en una branch, necesito saber qué commit lo introdujo” ○ git bisect ○ Búsqueda binaria, conducida por git. Muy fácil! ○ git bisect start git bisect bad <commit> git bisect good <commit> ● Probamos en cada paso (git hace checkout)
  38. 38. Situaciones comunes (3) ● “Hice uno (o varios) commits en la branch equivocada, todavía no pushee!” ○ Si la branch correcta no existe ■ git checkout -b <branch correcta> ■ git reset sobre vieja branch ○ Si la branch ya existía ■ git cherry-pick (o git rebase --onto) ■ git reset sobre vieja branch
  39. 39. Situaciones comunes (4) ● “Tengo muchos cambios en un archivo y solo quiero comittear parte de ellos” ○ git add -p o git commit -p ○ git va a preguntar por cada parte, si queremos agregarla o no
  40. 40. Situaciones comunes (5) ● “Necesito cambiar unos commits” ● “Necesito borrar unos commits” ● “Necesito cambiar de orden unos commits” ○ git rebase -i (--interactive) ○ Fácil de usar ○ Reescribiendo la historia, preguntándonos qué queremos hacer por cada commit
  41. 41. Situaciones comunes (6) ● “Estoy haciendo un merge con muchos conflictos y quiero volver a como estaba antes de comenzarlo” ○ git merge --abort
  42. 42. (Imágenes de git-scm y demás ;) ) No aprendió git

×