Perder el miedo a git en 90 minutos

Perder el miedo a Git en 90 minutos

Adeodato Simo

Zaragoza, 2009-02-20


Plan para esta hora y media

• La revolucion de los SCM distribuidos: verdades y mentiras

• SCM distribuidos: cosas a tener en cuenta

• Por que Git: caracterısticas interesantes

• Pilares basicos de Git

• Tour por los comandos mas interesantes

• Preguntas


La revolucion de los SCM distribuidos

• La gran mentira: La mayor ventaja de los SCM distribuidos esque tienes una copia local de la historia, y puedes hacer log y diffsin estar conectado.

• Lo anterior es una caracterıstica conveniente, pero losverdaderos beneficios de los SCM distribuidos son:

• Democratizacion de las herramientas• Derecho a la intimidad y la higiene


La democratizacion de los SCM

La metedura de pata de los SCM centralizados: hacer del nivel deacceso un discriminador clasista a nivel de herramienta

La pregunta del millon: ¿por que mis contribuidores no pueden utilizarlas mismas herramientas que yo, y para que puedanhacerlo, han de tener mi mismo nivel de acceso?

Caso ideal: tener acceso es un marron, y no una ventaja. (Tattoothat.)


Nuevo orden de cosas

• Los SCM distribuidos permiten a cualquier persona desarrollaren igualdad de condiciones

• El como y cuando dar acceso es ahora una cuestion social opolıtica, como siempre debio ser

• Para los escepticos que digan: ¿realmente hay tanta diferenciaentre ”svn commit” y ”svn diff — mutt”?

• Quiza no con Subversion, pero en los SCM distribuidos (y enparticular con Git) la diferencia se hace abismal


El derecho a la intimidad y la higiene

• En los SCM centralizados:• crear ramas ”impone”, pues todas han de ir al repositorio central,

y seran visibles incluso si son abandonadas despues• no hay Ctrl-Z

• Los SCM distribuidos:• permiten el desarrollo en privado• hay Ctrl-Z ilimitado en la copia local


Particularidades de los SCM distribuidos

• Indivisibilidad del arbol• no hay checkouts parciales como en SVN• hace falta cirugıa y magia para dividir un repositorio en dos (y eso

cuando es posible)• pero se pueden ”arrejuntar” repositorios

• Indivisibilidad de la historia• se copia siempre toda la historia del proyecto a la maquina local• existe funcionalidad para obtener solo una parte, pero el resultado

tiene limitaciones


¿Por que Git?

• Anecdota: mi historia y lo que leı en un blog• Ventajas:

• riqueza• flexibilidad• velocidad• eficiencia espacial• nivel de adopcion

• Sobre la curva de aprendizaje...• no es tanto la complejidad de la herramienta• como, en muchos aspectos, el cambio de paradigma


Git: algunas caracterısticas

• Disenado a lo Unix• un ejecutable distinto para cada tarea• estos se combinan entre sı facilmente• muchos no se usan normalmente (”plumbing”)

• Sin miedo a romper paradigmas• el ”index”• la cirugıa como accion cotidiana• una manera diferente de renombrar ficheros• $PAGER por omision

• Posibilidad de ignorar la magia y utilizarlo como un SCM ordinario


Modelo de datos interno

• Etiquetador⇒ Tag

• Flechas⇒ Branches (flecha roja: HEAD)• Grafo⇒ Commits

• meta-informacion (incl. padre/s)• tree

• blob• tree

• Concepto de ”committish” y ”treeish”

• La copia de trabajo y su relacion con la rama


Como referirse a los ”committish”

• Formas basicas:• SHA1: 9448a825ddb13c79a35e438c6d9d6bd485b66b52• SHA1 abreviada: 9448a8• nombres simbolicos (ramas y tags): HEAD, master, 0.9.2

• Refiriendose a los padres:• HEADˆ (el padre inmediato)• HEAD 1 (ıdem)• HEAD 2 (el padre del padre, etc.)

• Funcionalidad extra: HEAD@two weeks ago


El index (I): commit en los SCM tradicionales

• En una copia de trabajo en un SCM tradicional se diferenciaentre:

• (a) ficheros que el SCM conoce (via ‘svn add‘)• (b) ficheros que el SCM sabe que ha de ignorar• (c) ficheros de los que no sabe nada (limbo)

• La operacion ”commit” automaticamente detecta cambios en losficheros (a), y crea una nueva revision con ellos:

‘svn commit‘ <--> (a)(b) |-> ignorados por ’’commit’’(c) |/


El index (II): todo es limbo en Git

• En Git, la operacion commit”no se interesa por el estado de losficheros en (a):

• a efectos de commit”, todos los ficheros estan en el estado (c), enel limbo

• (otras operaciones como status y diff sı pueden diferenciar entrelos tres estados)

• git commit decide que incluir en la revision mirando en un lugarespecial... el index

Git <--> Staging area <--> Limbo------------ -----

Index Working dir


El index (III): anadiendo cosas al index

• Con ‘git add‘, todos los cambios a un fichero pasan al index:

% edit foo.c% git add foo.c% git commit -m ’Arreglado no se que en foo.c’

• Cuidado:

% edit foo.c (#1)% git add foo.c% edit foo.c (#2)% git commit -m ’Cambios de #1 pero no de #2’


El index (IV): interaccion ‘diff‘ y ‘status‘

• ‘git diff‘ a secas muestra las diferencias entre la copia de trabajoy el ındice:

% edit foo.c% git add foo.c% git diff foo.c=> Diff vacıo!

• Optiones interesantes:

% git diff --cached # HEAD <--> index% git diff HEAD # HEAD <--> working dir

• Los tres estados de ‘git status‘


El index (y V): consejos y trucos finales

• Elegir que cambios anadir hunk a hunk:

% git add -p [fichero]

• Usos del index:• revisar codigo, de otros o de uno mismo (anadir al index lo ”ya

revisado”)

• Fingir que el index no existe:

% git commit -a% git diff HEAD


Trabajar con ramas

• Publicidad enganosa en SVN: ”Branching is O(1)”

• Branchear en la justa medidai• Comandos:

• git branch nueva rama• git checkout otra rama• (¿que pasa con los non-committed cambios?)• git checkout -b nueva rama2

• ‘git merge‘: merges vs ”fast forwards”


Repositorios locales y remotos

• Copia inicial (git clone):• las ramas remotas se copian a ”origin/¡rama¿”• se crea una rama local (normalmente ”master”)

• Actualizaciones sucesivas (git pull):• se reciben los datos, y se actualizan la ”tracking branches”,

incluyendo la actual

• Enviar (git push):• mapeo rama local <--> remota, y se actualizan• $PATH/repo/.git vs $PATH/repo.git


La cirugıa privada, piedra angular de este SCM

• Tambien denominada ”history rewriting”, pero no me gusta esenombre...

• ¿Por que privada/en privado?• Consecuencias de la cirugıa

• Cosas que se pueden hacer:• Cambiar cualquier commit• Unir dos o mas commits en uno• O dividir un commit en varios• Transplantar una serie de commits a otra rama


Integridad en Git y secuelas de la cirugıa

• Para dar nombres a las cosas, Git usa SHA1:• los objetos internos no tienen otro nombre que el SHA1 de su

contenido

• Es imposible cambiar algo en el repositorio y no cambiarle elnombre: git se quejarıa mucho

• posibilita detectar corrupcion de disco• si tienes un tag firmado, toda la historia que conduce a ese tag

queda verificada

• La cirugıa renombra todas las cosas que toca, y toda ladescendencia de esas cosas


Herramientas para la cirugıa

• Editar el ultimo commit: git commit –amend

• Editar commits ”enterrados”, unir o dividir commits: git rebase -i

• Transplantar historia: git rebase, git pull –rebase• Desechar commits: git reset, que viene en tres sabores:

• –soft• –mixed• –hard (cuidado!)

• y dos modelos (con y sin argumentos)


git reset (cont.)

• Sin argumentos, pone el estado al ultimo commit:

% git reset => resetea el ındice% git reset --hard => desechar todos los

cambios locales

• Con argumentos, pone el estado al commit especificado:• Para solo ”resetear” un fichero...

• git checkout FILE (muy intuitivo...)


Descubriendo git log

• Cosas basicas:

% git log --name-status% git log -p

• El motor de busqueda:

% git log --author=’John Doe’% git log --grep=’playlist’% git log -S’nombre_de_una_funcion’


Otros comandos

% git show $committish% git reflog% git stash% git format-patch% git archive% git clean% git gc% git config

• Ficheros: /.gitconfig, $REPO/.git/config

• Herramientas graficas: gitk, gitg, ...

• Otras: git-svn; /bin/git-¡tu comando¿

• Hooks


Escribir commit messages

| Incluir una lınea de sumario, corta y|| Luego una lınea en blanco, y el resto de la| descripcion, en tantos parrafos como haga| falta.

• ¿Por que ası? ¿Es obligatorio?


¿Preguntas?


Perder el miedo a git en 90 minutos

Technology

Transcript of Perder el miedo a git en 90 minutos