Índice
NOTA: Puede que te interese descargar este manual para git. Si rellenas el formulario correctamente nos darán $1.5 de comisión, una buena forma de mostrar tu apoyo al blog ;-)
Una de mis tareas pendientes era aprender GIT decentemente. Así que empecé a leer Pro Git, libro que recomiendo a todo desarrollador, disponible en PDF, EPUB, MOBI y versión en papel. En la página del libro puedes encontrar versiones en distintos idiomas. Conforme he ido leyendolo, he anotado los comandos. Como resultado he creado esta especie de chuleta de comandos git que comparto hoy con vosotros. Espero que os resulte útil.
Chuleta de comandos git
git help <command>git clone <uri> namedir# clona usando como nombre de directorio namedir.git add <dir># añade recursivamente todos los archivos del dir.git diff --staged# compares staged changes with last commitgit commit -v# muestra el diff en el editorgit commit -a -m "mensaje"# automatically stage tracked files. No hace falta git addgit rm --cached <file or regexp># Git no realiza un seguimiento del archivo, pero los deja en el directorio de trabajo. Útil cuando se olvida añadir archivos al .gitignore y ya hemos agregado dichos archivos al repositorio.git rm <file># borrarlos con git siempre.git rm -f <file># si ya está modificado y en el index.git mv <file> <renamed_file>gitk# tcl/tk. Herramienta gráfica para gitgit commit --amend# Modificar el mensaje del último commitgit reset HEAD <file># to unstagegit checkout -- <file># Descartar cambios en el directorio de trabajo.
AÑADIR ARCHIVOS
git add -i# interactive staggingit add -p# crea patch
STASH
git stash# guarda el estado en una pila y limpia el directorio para poder cambiar de ramagit stash list# muestra la pilagit stash apply# vuelve al estado original del dir. Stash{n} especifica uno concreto Y –index reaplica los cambios staggedgit stash pop# elimina el primero en la pila. O drop
LOGS
git log -p -2# Muestra 2 últimos commits con diffgit log --statgit log --pretty <short|full|fuller>git log --pretty=format:"%h - %an, %ar : %s"git log --pretty=format;"%h %s" --graphgit log --since=2.weeksgit log <branch> --not master# Muestra commit de<branch>sin incluir los de mastergit log --abbrev-commit --pretty=onelinegit diff master...contrib# Muestra solo el trabajo que la rama contrib actual ha introducido desde su antecesor común con mastergit log <branch1>..<branch2># Commits de branch2 que no están en branch1git log origin/master..master# Muestra qué commits se van a enviar al servidorgit log origin/master..# Igual que el anterior. Se asume master o HEADgit log refA refB --not refC# commits en refA y refB que no están en refCgit log master...experiment# commits de master o experiment, pero sin ser comunes. Con –left-right indica a qué rama pertenece cada uno
REMOTES # repos en internet
git remote -v# lista los repos remotosgit remote add [shortname] [url]# crea nuevo remote, es posible descargar el contenido de ese repo con git fetch [shortname]. Master branch en [shortcode]/mastergit fetch <remote># descarga trabajo nuevo a máquina local, no sobreescribe nada tuyo. ( git pull sí hace merge automaticamente si se esta realizando un seguimiento de esa branch)git push [remote-name] [branch-name]# sii nadie ha hecho push antesgit remote show [remote-name]# inspecciona remote.git remote rename <old-name> <new-name># también renombra branches: quedaría<new-name>/mastergit remote rm <remote-name># p.e si el contribuidor ya no contribuye más
Añadir varios repositorios remotos
git remote add bitbucket <url repositorio># Añadir un nuevo repositorio remoto con el nombre deseado. Por ejemplo si ya tenemos uno en github y queremos añadir otro para bitbucketgit push -u bitbucket -all# Subir el proyecto a bitbucket. A partir de ahora se puede seleccionar a qué repo publicar congit push nombre_repo_remoto
TAGGING # marcan puntos importantes en la histtoria del repo ( releases )
git tag# muestra las etiquetas actualesgit tag -l 'v1.4.2.*'# acepta regex- Dos tipos de tag:
- Lightweight : puntero a commit ( branch que no cambia )
- Annotated : se almacenan como objetos en la db, con checksum, nombre del creador, email, fecha, mensaje, posibilidad de firmarla con GPG. ( recomendada )
git tag -a <tagname> -m 'mensaje'# annotated taggit show <tag-name># muestra información asociada.git tag -s <tag-name> -m 'message'# la firma con gpggit tag <tag-name># lightweight taggit tag -v <tag-name># verifica tags firmadasgit tag -a <tag-name> [commit-chksum]# crea tag para commit con dicho chksum- Por defecto no se transfieren los tags, para subirlos al servidor:
git push origin [tag-name]# una solagit push origin --tags# Enviar todas
- Para usar GPG y firmar tags, hay que subir la clave pública al repositorio:
gpg --list-keys# Coges la id públicagpg -a --export <id> | git hash-object -w --stdin# Copia el SHA-1 devueltogit tag -a maintainer-gpg-pub <SHA-1>git push --tags# Comparte la clave con todos los usuariosgit show maintainer-gpg-pub | gpg --import# Cada usuario importa la clave asígit show <tag># Devuelve más información sobre la etiquetagit tag -d nombre_tag# eliminar la etiquetagit push origin :refs/tags/nombre_tag# Eliminar la etiqueta del repositorio remoto.
BRANCH
Las ramas simplememte son punteros a distintos snapshots
git branch <nombre-rama># crea rama. Puntero al commit actualgit checkout <nombre-rama># cambiar a la rama especificada.git checkout -b <nombre-rama># crea y cambia de ramagit merge <rama># Mezcla la rama actual con<rama>git branch -d <rama># elimina la ramagit push origin --delete <branchName># Elimina una rama del servidorgit mergetool# Herramienta gráfica para resolver conflictosgit branch# lista ramasgit branch -v# lista ramas mostrando último commitgit branch --merged# lista ramas que han sido mezcladas con la actual. Si no tienen un *, pueden borrarse, ya que significa que se han incorporado los cambios en la rama actual.git branch --no-merged# lista ramas que no han sido incorporadas a la actual.
REMOTE BRANCHES
git fetch origin# Descarga el contenido del servidorgit push <remote> <branch># Las ramas no se suben por defecto, has de subirlas explícitamentegit push <remote> <branch>:<nuevoNombre># Igual que la de arriba, pero en el servidor se llama a la rama con nuevoNombre en lugar de branch- Cuando se hace un git fetch que trae consigo nuevas ramas remotas, no se disponen de ellas localmente, solo se dispone de un puntero a la rama remota que no es editable. Para poder trabajar sobre esa rama, es necesario crearla Por ejemplo:
git fetch origin# Tras ejecutarlo, notamos que se ha creado una rama nueva (rama_nueva)git checkout -b rama_nueva origin/rama_nueva# Crea una rama local a partir de la remotagit merge origin/nueva_rama# Equivalente a la de arriba, pero sin establecer el tracking a la rama
git push [remotename] :[branch]# elimina una rama remotagit push [remotename] [localbranch]:[remotebranch]# La rama en el servidor tiene distinto nombre a la local
TRACKING BRANCHES
git checkout --track origin/rama# Equivalente a -b rama_nueva origin/rama_nuevagit chekout -b <nuevo_nombre> origin/<rama># Establece un nombre distinto para la rama local
REBASE
Rebase y merge se diferencian en que merge mezcla dos puntos finales de dos snapshots y rebase aplica cada uno de los cambios a la rama en la que se hace el rebase. No lo uses en repos publicos con mas colaboradores, porque todos los demas tendrán que hacer re-merges
git checkout <una rama>git rebase master# aplica todos los cambios de<una rama>a mastergit merge master# hay que hacer un merge de tipo fast forwardTenemos 3 ramas, master, client y server, en server y client tenemos varios commit y queremos mezclar client en master pero dejar server intacta:
git rebase --onto master server client# adivina los patches del antecesor común de las ramas server y client y aplica los cambios a master.git checkout mastergit merge client# fast-forward. Client y master en el mismo snapshot
Si se quiere aplicar también los cambios de server, basta con:
git rebase master servergit checkout mastergit merge server
git rebase [basebranch] [topicbranch]# sintaxis de rebasegit rebase -i# Rebase interactivo
SERVIDOR
git instawew# Muestra una interfaz web con los commits
GENERAR UN NÚMERO DE COMPILACIÓN (BUILD NUMBER)
git describe master# Solo funciona para tags creadas con -s ó -a
PREPARAR UNA RELEASE
git archive master --prefix="project/" | gzip > $(git describe master).tar.gzgit archive master --prefix="project/" --format=zip | $(git describe master).zip- test/ export-ignore # Al crear el tarball no incluye el directorio test/
GENERAR UN CHANGELOG
git shortlog --no-merges master --not <tag># Recopila todos los commits desde<tag>y los agrupa por autor
RECOMENDACIONES
Siempre hay que hacer pull antes de push en caso de que alguien haya subido cambios al servidor. Ejemplo:
- User1 clona el repo y hace cambios, realiza un commit
- User2 clona el repo, hace cambios, hace commit y sube los cambios con push
- User1 intenta hacer push, pero será rechazado con: ! [rejected] master -> master (non-fast forward). No puede subir los cambios hasta que no mezcle el trabajo que ha subido User2. Así que debe hacer lo siguiente:
- git fetch origin
- git merge origin/master
- git push origin master
Mientras User1 hacía estas operaciones, User2 ha creado una rama issue54 y realizado 3 commits, sin haber descargado los cambios de User1. Para sincronizar el trabajo, User2 debe hacer:
git fetch origingit log --no-merges origin/master ^issue54# Observa qué cambios ha hecho User1git checkout mastergit merge issue54 && git merge origin/mastergit push origin master
git diff --check# Antes de hacer commit, ejecutar esto para ver si hemos añadido demasiados espacios que puedan causar problemas a los demás.Commits pequeños que se centren en resolver un problema, no commits con grandes cambios.
git add --patch# En caso de hacer varios cambios en el mismo archivoEl mensaje del commit debe tener la estructura siguiente: Una linea de no más de 50 caracteres, seguida de otra línea en blanco seguida de una descripción completa del commit.
PASOS A SEGUIR PARA CONTRIBUIR A PROYECYOS AJENOS, MEDIANTE FORK
git clone <url>git checkout -b featureAgit commitgit remote add myFork <url>git push myFork featureAgit request-pull origin/master myFork# enviar la salida por mail al propietario del proyecto, o hacer click en pull request.- Buena practica tener siempre una rama master que apunte a origin/master, para estar siempre actualizado con los ultimos cambios en el proyecto original.
- Separar cada trabajo realizado en topic branch, que trackeen a origin/master
git checkout -b featureB origin/master- (Hacer cambios)
git commitgit push myFork featureB- (Contactar con el propietario del proyecto)
git fetch origin- Otro ejemplo, el propietario del proyecto quiere aceptar un pull tuyo, pero quiere que hagas algunos cambios, aprovechas la oportunidad y mueves tu trabajo para basarlo en el contenido actual de la rama origin/master, aplastas los cambios en featureB, resuelves conflictos, y haces push:
git checkout -b featureBv2 origin/mastergit merge --no-commit --squash featureB- (cambiar la implementacion)
git commitgit push myFork featureBv2--squashcoge todo el trabajo de la rama mezclada y la aplasta en un no-merge commit encima de la rama en la que estas. –no-commit no registra el commit automaticamente. Así puedes realizar todos los cambios necesarios y luego hacer el commit
REFLOG
En segundo plano, git crea un log de a donde han estado referenciando HEAD y el resto de ramas en los últimos meses.
git refloggit show HEAD@{n}# Muestra información sobre el reflog número ngit log -g master# Muestra el log formateado como la salida de refloggit show master@{yesterday}# Muestra los commits de ayer.
UTILIDADES
git show <short-SHA-1># Es posible ver un commit pasando la versión abreviada del SHA-1git rev-parse <branch># A qué SHA-1 apunta una ramagit show HEAD^# Muestra commit padregit show HEAD^2# Muestra segundo padregit show HEAD~2# El primer padre del primer padregit filter-branch --tree-filter 'rm -f <file>' HEAD# elimina el archivo de todos los commits
DEPURACIÓN
File anotation
git blame -L 12,22 <archivo># muestra cuando y por quién se modificaron de la linea 12 a la 22git blame -C -L 141,153 <file># cuando renombras un archivo o lo refactorizas en varios, muestra de donde vino originalmente.
Búsqueda Binaria: Cuando hay un bug que no puedes localizar, usas bisect para dererminar en qué commit empezó a producirse el bug.
git bisect startgit bisect bad# marcas el commit actual como rotogit bisect good [commit bueno]# último commit conocido que funcionaba
Ahora irá preguntando hasta que encuentres el commit culpable. Si esta bien indicas git bisect good. De lo contrario git bisect bad. Al terminar hay que resetear.
git bisect reset
SUBMODULOS
git submodule add <url># crea un directorio que contiene el comtenido de otro proyecto.Clonar un repo con submodulos
- git clone url
- git submodule init
- git submodule update
CONFIGURATION
git config --global <opcion> <valor># global para usuario, system todos y sin nada, especifico para el repo.git config {key}# muestra el valor de keygit config --global core.editor <editor># cambia el editor por defectogit config --global commit.template $HOME/.gitmessage.txt# plantilla para commitsgit config --global core.pager 'more|less'# paginador por defecto, puedes usar cualquieragit config --global user.signingkey <gpg-key-id># clave gpg para firmar tagsgit config --global core.excludesfile <file># como gitignoregit config --global help.autocorrect 1# autocorrige cuando se escribe un comando incorrecto. Solo en git >= 1.6.1git config --global color.ui true# colorea la salida de git. Valores: true|false|alwaysgit config --global core.autocrlf input# para que usuarios linux no tengan problemas con los retornos de carro de windowsgit config --global core.autocrlf true# para usuarios de windowsgit config --global core.whitespace trailing-space, space-before-tab, indent-with-non-tab, cr-at-eol# respectivamente: busca espacios al final de línea, busca espacios al inicio de tabulación, busca líneas con 8 o más espacios en lugar de tabulaciones, acepta retornos de carrogit apply --whitespace=warn <patch># advierte de errores de espacios antes de aplicar el patch. Con –whitespace=fix intenta arreglarlos
GIT ATTRIBUTES
Archivo en .gitattributes en el directorio de trabajo o en .git/info/attributes para no committearlo
Identificando archivos binarios Muchos archivos son para uso local y no aportan información al repositorio. Para decirle a git qué archivos son binarios hacer añadir al archivo atributes:
<nombre archivo o regexp> -crlf -diff# git no intentará corregir problemas de crlf ni mostrará los cambios con diff. En versiones >= 1.6 se pueden sustituir estos dos valores por la macro binary
Diffing binary files
En ocasiones es útil mostrar diffs de archivos binarios, como una archivo de word:
*.doc diff=word
tras esto hay que definir el filtro word para que git convierta archivos word a texto:
git config diff.word.textconv strings
Es posible hacer lo mismo para imágenes jpeg, es necesario instalar exiftool para extraer los metadatos y luego hacer:
$ echo ‘*.jpeg diff=exif’ » .gitattributes
$ git config diff.exif.textconv exiftool
Procesar archivos antes de hacer commit y antes de hacer checkout: Es posible crear tus propios filtros para hacer sustitución. Estos filtros se llaman smudge y clean. Los puedes configurar para distintos directorios y luego escribir un script que procesará cada archivo antes de que sea checkeado (smudge) y commiteado (clean). Para ello,escribe en el .gitattributes: (En caso que quieras procesar código C)
*.c filter=indent Luego:
git config --global filter.indent.clean indentgit config --global filter.indent.smudge cat
Otro ejemplo interesante es la expansión de la palabra clave $Date$. Para ello hay que escribir un script en ruby que recibe un archivo, encuentra la fecha de su último commit e inserta dicha fecha en el archivo:
#! /usr/bin/env ruby
data = STDIN.read
last_date = `git log --pretty=format:"%ad" -1`
puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$')
Puedes nombrar este script como expand_date. Crea un filtro en git, llamado dater y dile que use el script anterior:
git config filter.dater.smudge expand_dategit config filter.dater.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
Para usar el filtro, simplemente escribe la palabra clave en los archivos que desees:
echo '# $Date$' > date_test.txt
echo 'date.txt filter=dater' » .gitattributes
git add date_test.txt .gitattributes
git commit -m "Testing date expansion in Git"
rm date_test.txt
git checkout date_test.txt
cat date_test.txt
$Date: Tue Apr 21 07:26:52 2009 -0700$
GIT HOOKS
Hay dos tipos, de lado cliente y servidor, se guardan en el directorio .git/hooks. Para activarlos basta con que sean ejecutables.
CONCEPTOS
Fast forward: cuando se hace un merge y el commit de la rama a mezclar esta justo un commit adelantado, simplemente se hace apuntar la rama en la que se iba a mezclar al commit del merge.
GITIGNORE:
*.a # no .a files
*!lib.a # but do track lib.a, even though you’re ignoring .a files above
/TODO # only ignore the root TODO file, not subdir/TODO*
build/ # ignore all files in the build/ directory*
doc/*.txt # ignore doc/notes.txt, but not doc/server/arch.txt
¿Has visto algún error?: Por favor, ayúdame a corregirlo contactando conmigo o comentando abajo.