TRUCOS Y CONSEJOS DE GIT

presentado por Tower - el mejor cliente Git para Mac y Windows

CREAR RAMAS & ETIQUETAS MERGE & REBASE

Clonar un repositorio existente Mostrar un listado de todas las ramas Integrar <rama> en el HEAD actual
$ git clone ssh://user@domain.com/repo.git existentes $ git merge <rama>
$ git branch -av
Crear un nuevo repositorio local Hacer rebase del HEAD actual a <rama>
$ git init Cambiar a la rama HEAD No hagas rebase de commits publicados!
$ git checkout <rama> $ git rebase <rama> 

CAMBIOS LOCALES Crea una nueva rama basada en tu HEAD Abortar un rebase
actual $ git rebase --abort
Ficheros modificados en el directorio de
$ git branch <nueva-rama>
trabajo Continuar con un rebase después de resolver
$ git status Crear una nueva rama de seguimiento basada conflictos
en una rama remota $ git rebase --continue
Cambios en los ficheros bajo seguimiento
$ git checkout --track <rama/remota>
$ git diff Usa el editor para resolver conflictos manu-
Eliminar una rama local almente y (después de resolver) marcar el
Añadir todos los cambios actuales en el sigui- archivo como resuelto
$ git branch -d <rama>
ente commit
$ git mergetool
$ git add . Marcar el commit actual con una etiqueta
$ git tag <etiqueta> Usa el editor para resolver conflictos manu-
Agrega algunos cambios en <fichero> al siguien- almente y (después de resolver) marcar el
te commit archivo como resuelto
$ git add -p <fichero> ACTUALIZACIÓN & PUBLICACIÓN $ git add <fichero-resuelto>
Confirmar todos los cambios locales en los Listar todos los repositorios remotos configu- $ git rm <fichero-resuelto>
ficheros bajo seguimiento rados actualmente
$ git commit -a $ git remote -v
DESHACER
Hacer commit de los cambios previamente Mostrar información sobre un repositorio
realizados remoto Descartar todos los cambios locales en el
directorio de trabajo
$ git commit $ git remote show <remoto>
$ git reset --hard HEAD
Modificar el último commit Agregar nuevo repositorio remoto, llamado
¡No modifiques los commits ya publicados! <nombre-corto>  Descartar cambios locales en un fichero
específico 
$ git commit --amend $ git remote add <nombre-corto> <url>
$ git checkout HEAD <fichero>
Descargar todos los cambios desde el reposi-
torio <remoto> (sin integrar en HEAD) Revertir un commit (produciendo un nuevo
HISTORIAL DE COMMITS
commit con los cambios inversos) 
$ git fetch <remoto>
Mostrar todos los commits, comenzando por $ git revert <commit>
el más nuevo Descargar cambios y directamente integrar
Resetea el HEAD a un commit anterior ... y
$ git log en HEAD
descarta todos los cambios desde entonces
$ git pull <remoto> <rama>
Mostrar cambios previos para un fichero $ git reset --hard <commit>
específico Publicar los cambios locales en el repositorio
...y preservar todos los cambios como cambios
$ git log -p <file> remoto
pendientes
$ git push <remoto> <rama>
¿Quién cambió qué y cuándo en <fichero>? $ git reset <commit>
$ git blame <fichero> Eliminar una rama en el repositorio remoto
... y preservar cambios locales no commiteados
$ git branch -dr <remoto/rama>
$ git reset --keep <commit>
Publicar tus etiquetas
$ git push --tags

Prueba gratuita de 30 días disponible en

www.git-tower.com El mejor cliente Git para Mac y Windows
 CONTROL DE VERSIÓN
BUENAS PRÁCTICAS

HAZ COMMIT SÓLO DE LOS CAMBIOS PRUEBA TU CÓDIGO ANTES DE HA- UTILIZA RAMAS
RELACIONADOS CER COMMIT La ramificación es una de las características
Un commit debe ser un envoltorio para los Resiste la tentación de hacer commit de algo más potentes de Git, y esto no es casualidad:
cambios relacionados. Por ejemplo, la correc- que «creas» que se ha completado. Pruébelo desde el primer día, la ramificación rápida y
ción de dos errores diferentes debería producir sencilla fue un requisito fundamental. Las
a fondo para asegurarte de que realmente
dos commits separados. Hacer pequeños ramas son la herramienta perfecta para evitar
commits facilita a los demás desarrolladores está completo y no causa efectos secunda-
rios (hasta donde alcanza tu conocimiento). que se mezclen diferentes líneas de desar-
la comprensión de los cambios y el retroceso
de los mismos en caso de que algo saliera Mientras integrar cosas hechas a medias en rollo. Deberías utilizar las ramas de forma
mal. tu repositorio local sólo te causa problemas extensiva en tus flujos de trabajo de desar-
Con herramientas como el área de staging a ti, tener tu código probado es aún más rollo: para nuevas funciones, correcciones de
y la capacidad de incluir sólo partes de un importante cuando se trata de compartir tu errores, ideas....
archivo, Git facilita la creación de commits
código con otros.
muy granulares.

HAZ COMMITS FRECUENTEMENTE ESCRIBE TÍTULOS DESCRIPTIVOS ACORDAD UN FLUJO DE TRABAJO

Hacer commits muy a menudo ayuda man- Comenza tu mensaje con un breve resumen Git te permite elegir entre una gran variedad
tener tus commits pequeños y, de nuevo, te de tus cambios (hasta 50 carácteres como de flujos de trabajo: ramas de larga duración,
ayuda a commitear sólo los cambios relaci- guía). Sepáralo del siguiente cuerpo incluyen- ramas temáticas, merge o rebase, git-flow...
onados. Además, te permite compartir tu do una línea en blanco. El cuerpo de tu men- La elección depende de un par de factores: tu
código con otros con más frecuencia. De esta saje debe proporcionar respuestas detalladas proyecto, tus flujos de trabajo generales de
manera es más fácil para todos integrar los a las siguientes preguntas: desarrollo e implementación y (quizás lo más
cambios regularmente y evitar conflictos de › ¿Cuál es fin del cambio? importante) tus preferencias personales y las
integración. Tener pocos commits grandes y de tus compañeros de equipo. Independiente-
› ¿En qué se diferencia de la implementación
compartirlos de forma no habitual, en cambio, mente de cómo se decida trabajar, aseguraos
anterior?
dificulta la resolución de conflictos. de acordar un flujo de trabajo común que
Usa el imperativo, presente («cambiar», en
todos sigan.
lugar de «he cambiado» o «cambios en...»)
para ser consistente con los mensajes genera-
NO HAGAS COMMIT DE TRABAJO dos desde comandos como git merge.
HECHO A MEDIAS AYUDA Y DOCUMENTACIÓN

EL CONTROL DE VERSIONES NO ES UN Obtén más ayuda en la línea de comandos

Sólo debes integrar el código cuando esté
completo. Esto no significa que tengas que SISTEMA DE COPIAS DE SEGURIDAD $ git help <comando>

completar una función completa y grande

Hacer una copia de seguridad de tus archivos
antes de hacer un commit. Todo lo contrario:
en un servidor remoto es un agradable efecto
divide la implementación de la función en RECURSOS GRATUITOS EN LÍNEA
secundario de tener un sistema de control de
partes lógicas y recuerda hacer commit pronto http://www.git-tower.com/learn
versiones. Pero no deberías usar tu VCS como
y con frecuencia. Pero nunca debes hacer
si fuera un sistema de respaldo. Al realizar el http://rogerdudler.github.io/git-guide/
commit sólo para tener algo en el repositorio
control de versiones, debes prestar atención http://www.git-scm.org/
antes de salir de la oficina al final del día. Si
a hacer commits semánticamente (ver «cam-
estás tentado a hacer un commit sólo porque
bios relacionados») - no debes simplemente
necesitas una área de trabajo limpia (para re-
poner más ficheros.
visar una rama, hacer cambios, etc.) considera
usar la función «Stash» de Git en su lugar.

Prueba gratuita de 30 días disponible en

www.git-tower.com El mejor cliente Git para Mac y Windows