Git

De Departamento de Informatica
Saltar a: navegación, buscar

Contenido

Introducción

Es un software de control de versiones, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente.

Estructura

Tu repositorio local esta compuesto por tres "árboles" administrados por git. El primero es tu Workspace que contiene los archivos, el segundo es el Index que actúa como una zona intermedia, y el último es el HEAD o Repository que apunta al último commit realizado. Git nos permite subir y bajar los cambios realizados, desde nuestro HEAD hacia un servidor remoto y viceversa.

Logicaglobal.png

Comandos

Add

Puedes registrar cambios (añadirlos al Index) usando:

git add <filename>
git add .

Commit

Este es el primer paso en el flujo de trabajo básico. Para hacer commit a estos cambios usando:

git commit -m "Commit message"

Ahora el archivo esta incluido en el HEAD, pero aún no en tu repositorio remoto. Es importante que el mensaje tenga contenido, esto será de mucha ayuda para el resto de los desarrolladores.

Envío de Cambios

Tus cambios están ahora en el HEAD de tu copia local. Para enviar estos cambios a tu repositorio remoto ejecuta:

git push origin master

Reemplaza master por la rama a la que quieres enviar tus cambios.

Remote

Crear/Clonar un nuevo repositorio de git.

git init/clone

Si no has clonado un repositorio ya existente y quieres conectar tu repositorio local a un repositorio remoto, usa:

git remote add origin <server>

Ahora podrás subir tus cambios al repositorio remoto seleccionado.

Branch

Las ramas son utilizadas para desarrollar funcionalidades aisladas unas de otras. La rama master es la rama "por defecto" cuando creas un repositorio. Crea nuevas ramas durante el desarrollo y fusiónalas a la rama principal cuando termines. Lista todas las ramas locales con:

git branch

Muestra el estado actual de la rama, como los cambios que hay sin commitear usando:

git status

Crea una nueva rama llamada "dev" y cámbiate a ella usando:

git checkout -b dev

vuelve a la rama principal ejecutando:

git checkout master

y borra la rama con:

git branch -d dev

Una rama nueva no estará disponible para los demás a menos que subas (push) la rama a tu repositorio remoto usando:

git push origin <branch>

Actualiza & Fusiona

Para actualizar tu repositorio local al commit más nuevo, ejecuta:

git pull

en tu directorio de trabajo para bajar y fusionar los cambios remotos. Para fusionar otra rama a tu rama activa (por ejemplo master), utiliza:

git merge <branch>

en ambos casos git intentará fusionar automáticamente los cambios. Desafortunadamente, no siempre será posible y se podrán producir conflictos. Tú eres responsable de fusionar esos conflictos manualmente al editar los archivos mostrados por git. Después de modificarlos, necesitas marcarlos como fusionados con:

git add <filename>

Antes de fusionar los cambios, puedes revisarlos usando:

git diff <source_branch> <target_branch>

Etiquetas

Se recomienda crear etiquetas para cada nueva versión publicada de un software. Este concepto no es nuevo, ya que estaba disponible en SVN. Puedes crear una nueva etiqueta llamada 1.0.0 ejecutando:

git tag 1.0.0 1b2e1d63ff

1b2e1d63ff se refiere a los 10 caracteres del commit id al cual quieres referirte con tu etiqueta. Puedes obtener el commit id con:

git log

también puedes usar menos caracteres que el commit id, pero debe ser un valor único.

Reemplaza Cambios Locales

En caso de que hagas algo mal, puedes reemplazar cambios locales usando el comando:

git checkout -- <filename>

Este comando reemplaza los cambios en tu directorio de trabajo con el último contenido de HEAD. Los cambios que ya han sido agregados al Index, así como también los nuevos archivos, se mantendrán sin cambio. Por otro lado, si quieres deshacer todos los cambios locales y commits, puedes traer la última versión del servidor y apuntar a tu copia local principal de esta forma:

git fetch origin
git reset --hard origin/master

For conflicting paths, the index file records up to three versions

Cherry-pick

Permite aplicar los cambios introducidos por algunos commits existentes. Dado uno o más commits existentes, se aplican los cambios que cada uno introduce, registrando un nuevo commit por cada uno. Pero cuando no es obvio cómo aplicar un cambio, ocurre lo siguiente:

1. El branch actual y HEAD pointer permanecen en el ultimo commit que se realizo con éxito.
2. El CHERRY_PICK_HEAD se establece en el punto en el cual el commit tuvo dificultades para realizar los cambios.
3. El trayecto en cual los cambios fueron aplicados limpiamente se actualiza tanto en el archivo del index como en el árbol de trabajo.
4. Para trayectos en conflicto, el archivo del index guarda hasta 3 versiones. 

Los archivos del árbol de trabajo incluirán una descripción del conflicto entre corchetes por las marcas de conflicto habituales <<<<<<< y >>>>>>>.

Ejemplos útiles

Aplicar el cambio introducido por el commit en la punta de la master branch y crear un nuevo commit con este cambio.

git cherry-pick master

Aplicar los cambios introducidos por todos los commits que son antepasados de master, pero no de HEAD para producir nuevos commits.

git cherry-pick ..master
git cherry-pick ^HEAD master

Cuando un parche no se aplica correctamente, pero ha realizado demasiados cambios, y necesitamos volver atrás para luego volver a intentar teniendo mas cuidado con cada linea, la secuencia ha realizar seria la siguiente:

git cherry-pick topic^ (1)
git diff (2)
git reset --merge ORIG_HEAD (3)
git cherry-pick -Xpatience topic^ (4)

En (1) se aplican los cambios, los cuales se podrían mostrar con el comando: "git show topic^". En este ejemplo, el parche no se aplica limpiamente, por lo que la información en conflicto se escribe en el Index y en el Arbol de Trabajo y no se hacen nuevos commit. Con (2) podemos ver un resumen de los cambios realizados. En (3) se vuelve al estado Pre-cherry-picking, pero preservando las modificaciones locales que tienes en el árbol de trabajo. Finalmente en (4) aplicamos los cambios introducidos por topic^ de nuevo, pero con cuidado extra para evitar errores en la base o en el emparejamiento de las lineas de contexto.

Sub-comandos

--continue

Permite continuar la operación en curso utilizando la información de .git/sequencer. Se puede utilizar para continuar después de la resolución de conflictos en una falla de cherry-pick o revert.

git cherry-pick --continue
--quit

Permite olvidar la operación actual en curso. Se puede utilizar para limpiar el estado del .git/sequencer después de una falla de cherry-pick o revert.

git cherry-pick --quit
--abort

Permite cancelar la operación y volver al estado previo del .git/sequencer.

git cherry-pick --abort

Revert

El comando "git revert" es esencialmente un git cherry-pick pero inverso. Se crea un commit pero aplicando exactamente lo contrario del cambio introducido por el commit, es decir deshacer o revertirlo. Por lo tanto, cuando lo usamos se deshace el merge commit.

Sub-comandos

Dado que "git revert" es como un cherry-pick, también posee los sub-comandos:

git revert --continue
git revert --quit
git revert --abort

Ejemplo

Para revertir los cambios especificados por el antepenúltimo commit en HEAD y crear un nuevo commit con los cambios reversos, se ocupa:

git revert HEAD~2'

Para revertir los cambios hechos por el antepenúltimo commit en HEAD al penúltimo commit en HEAD. Pero no crea ningún commit con los cambios reversos. El revert solo modifica el Arbol de trabajo y el Index.

git revert -n master~2..master~1

Patch

Un parche no sera otra cosa que la concatenación de los diffs, para cada uno de los commits que el parche incluirá. Por lo tanto, la creación de parches en Git es la mejor manera de compartir cambios que aun no están listos para un push a una rama publica de nuestro proyecto.

Al tener varias ramas, estas pueden tener distintos niveles de avance, para obtener las diferencias de acuerdo a los commit realizados en cada una de las ramas, ocupamos:

git log --oneline --all

Obteniendo por ejemplo:

 * b36f227 (experimental) third commit -- added file3
 * f39ebe8 second commit -- added file2
 * 04a26e5 (HEAD, master) first commit -- committed file1

Por lo tanto, para la creación de un parche ocupamos:

git diff from-commit to-commit > output-file

Es decir, nuestro parche se crearía de la siguiente manera para el ejemplo antes mencionado:

git diff 04a2 b36f > patch.diff

Y lo aplicaríamos de la siguiente manera:

git apply patch.diff

Ademas nos permite ocupar el parche creado para generar nuevos parches con cambios nuevos, repitiendo el proceso antes mencionado.

Datos Útiles

Hard Reset: Volver a un commit en particular. Borrar los cambios posteriores a este commit.

git reset –hard 1b2e1d63ff

Interfaz gráfica por defecto:

gitk

Colores especiales para la consola:

git config color.ui true

Mostrar sólo una línea por cada commit en la traza:

git config format.pretty oneline

Agregar archivos de forma interactiva:

git add -i

Referencias

Herramientas personales
Espacios de nombres
Variantes
Acciones
Navegación
Herramientas