Git es nuestro amigo

Text

Text

Introducción

  • ¿Qué es un sistema de control de versiones?
  • Ventajas
    • Historial de cambios
    • Posibilidad de deshacer cambios
    • Trabajo en equipo

 

Breve historia de Git

  • Durante el mantenimiento de Linux entre 1991-2002 la mayoría de cambios se hacían en forma de parches y archivos.
  • En 2002 empezaron a usar un DVCS propietario, BitKeeper.
  • En 2005, la relación entre la comunidad de Linux  y BitKeeper se vino abajo.
  • La comunidad de Linux (Linus Torvalds en particular) desarrolló su propia herramienta a partir de la forma de trabajar que habían aprendido con BitKeeper.

 

Git: Fundamentos

  • Instantáneas, no diferencias.
  • Casi cualquier operación es local:
    • No necesitas acceder al servidor para navegar por el historial y volver a versiones anteriores.
    • No necesitas conexión para confirmar cambios.
  • Tiene integridad
    • Utiliza SHA-1 para generar el checksum, no puedes perder información o modificar archivos sin que Git lo sepa.
  • Muy dificil que el sistema haga algo que no se puede deshacer

Git: Estados

  • Confirmado (committed)
  • Modificado (modified)
  • No modificado (unmodified)
  • Preparado (staged)
  • Eliminados (deleted)
  • Bajo seguimiento (tracked)
  • Sin seguimiento (untracked)

Git: Secciones

  • Directorio de trabajo (working directory)
  • Área de preparación (staging area)
  • Git directory (repository)

Git: Configuración

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
$ git config --global core.editor emacs
$ git config --global merge.tool vimdiff
$ git config --list
user.name=Scott Chacon
user.email=schacon@gmail.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...
$ git config user.name
Scott Chacon

Git: Ayuda

$ git help <comando>
$ git <comando> --help
$ man git-<comando>
 git help config

Útil al no necesitar conexión para su consulta.

Se puede acceder de tres formas diferentes.

Git: Utilidades

$ git co<tab><tab>
commit config
$ git config --global alias.co checkout
$ git config --global alias.unstage 'reset HEAD --'

Git alias

Configurarte el autocompletado

 

https://librosweb.es/libro/pro_git/capitulo_2/consejos_y_trucos.html

Git: Comandos básicos

$ git init
$ git clone git://github.com/schacon/grit.git mygrit

Inicializar repositorio

Clonar repositorio

  • GIT
  • HTTP(S)
  • SSH

git status

$ git status
# On branch master
nothing to commit (working directory clean)

Comprobar el estado de tus archivos

Tip: Utiliza git status como guía.

$ vim README
$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   README
nothing added to commit but untracked files present (use "git add" to track)

git add

$ git add README

Seguimiento de nuevos archivos

Pasamos de estado untracked a estado staged (preparado)

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   README
#

Tip: Si quieres añadir a partir del directorio actual. Luego hablaremos de Git diff.

$ git add .

Git: Comandos básicos

Preparando archivos modificados

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   README
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#   modified:   benchmarks.rb
#
$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   README
#   modified:   benchmarks.rb
#

Git no añade directorios vacíos

Ignorando archivos: .gitignore

Excluir todos los archivos que no tengan que ver con la estructura de tu proyecto:

  • Cache y otros archivos generados: (.sass-cache)
  • Recursos que forman parte del contenido: Fotos de una noticia, adjuntos, etc.

 

 

.gitignore

.gitignore admite:

  • Comentarios (#)
  • Expresiones regulares
  • Indicación de directorios (/)
  • Negar un patrón (!)

Dada una estructura de files & folders:

kitkat (archivo)

despensa(d)/kitkat(d)/juanen

kitkat # se ignora todo
kitkat/ # se ignora sólo el directorio kitkat

kitkat
!kitkat/ # se ignoran todos los archivos kitkat excepto el directorio kitkat

git diff

Antes de preparar cualquier archivo, super recomendable

$ git diff [directorio|archivo]

Muestra las diferencias de los archivos trackeados y modificados.

Revisar diferencias de los archivos preparados:

$ git diff --cached
$ git diff --staged

Tip: Puedes crear un parche con:

$ git diff > parche.patch

git diff

Aspecto de git diff

$ git diff
diff --git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..da65585 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
           @commit.parents[0].parents[0].parents[0]
         end
 
+        run_code(x, 'commits 1') do
+          git.commits.size
+        end
+
         run_code(x, 'commits 2') do
           log = git.commits(`master`, 15)
           log.size

git commit

Confirmando nuestros cambios: pasamos del área de preparación a guardar los cambios en el directorio de git.

$ git commit # Resumen de cambios, necesitamos introducir un mensaje.
$ git commit -v # Igual pero te muestra también un diff
$ git commit -m 'A fregar' # Introducimos directamente el mensaje
$ git commit -am 'Comer a las 10:00' # Te añade al commit los archivos trackeados

Tips:

  • Commits descriptivos para facilitar futuras búsquedas
  • Utilización de infinitivos en los mensajes.
  • Evitar realizar commits con cambios a medio hacer.

git rm

Hay varias formas de eliminar archivos de seguimiento.

# Elimina el archivo pero no de git
$ rm grit.gemspec 

# Elimina el archivo de git (staged), 
# y si existe también del disco duro.
$ git rm grit.gemspec 

# Si un archivo ha sido eliminado podemos también pasarlo a staged.
$ git add . --all 

# Similar a git reset HEAD readme.txt, quita la eliminación del stage.
$ git rm --cached readme.txt 

También existe git mv para archivos que cambian de ruta o de nombre.

$ git mv file_from file_to

git log

Viendo el histórico de confirmaciones

$ git log
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2008 -0700
 
    changed the version number
 
commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Sat Mar 15 16:40:33 2008 -0700
 
    removed unnecessary test code
 
commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Sat Mar 15 10:31:28 2008 -0700
 
    first commit

git log

Algunas opciones

  • Se pueden añadir las diferencias introducidas (-p)
  • Limitar las entradas a mostrar (-2)
  • Estadísticas (--stat)
  • Formateo CUSTOM (--pretty)
  • Ver un gráfico de ramas (--graph)
  • Filtrar por fechas (--since y --until)

Oooops

Git te ayuda a solucionar tus errores

git commit --amend

Hice commit demasiado rápido:

  • Me equivoqué en el mensaje
  • Se me olvidaron añadir archivos.
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend

git reset HEAD <file>

Hice git add . y añadí archivos que no quería.

$ git add .
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   README.txt
#       modified:   benchmarks.rb
#

git reset HEAD <file>

Quitamos los archivos del stage.

$ git reset HEAD benchmarks.rb
benchmarks.rb: locally modified
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   README.txt
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   benchmarks.rb
#

Tip: git status ya nos dice cómo hacerlo.

git checkout <file>

Este cambio no me vale!

$ git status
# En la rama master
# Cambios no preparados para el commit:
#   (use «git add <archivo>...» para actualizar lo que se ejecutará)
#   (use «git checkout -- <archivo>...« para descartar cambios en le directorio de trabajo)
# 
# 	modified:   despensa/kitkat/juanen
# 
# no hay cambios agregados al commit (use «git add» o «git commit -a»)
$ git checkout .
$ git status
# En la rama master
# nothing to commit, working directory clean

acabo de commitear datos sensibles

contraseñas, cuentas bancarias, fotos de la mujer de mi mejor amigo

Con git filter-branch podemos borrar un archivo sin dejar rastro en el repositorio, es decir, ese archivo no aparecerá en ningún commit, su funcionalidad es reescribir grandes porciones del historial de forma automática.

$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
Ref 'refs/heads/master' was rewritten

eliminar el último commit subido a un remote: git revert

Con git revert realizamos un nuevo commit que deshace los cambios a partir del commit que le digamos bajo la nomenclatura HEAD~N

git revert HEAD~3

Crea un commit deshaciendo los 3 últimos commits.

eliminar un archivo del repo sólamente: git rm --cached <archivo>

El típico caso que has subido al repositorio algún archivo de configuración de tu IDE o de tu sistema operativo.

git rm --cached .idea

remotes

  • Para trabajar en equipo es necesario gestionar los repositorios remotos. 
  • Con ellos obtendremos (pull) y enviaremos (push) nuestros cambios.
  • Normalmente tenemos origin como remote por defecto, pero podemos tener más.

ramas

git branch

Con git branch podemos obtener un listado de las ramas disponibles, crear ramas nuevas y eliminarlas.

$ git branch develop # Creamos la rama develop
$ git branch feature/ZEL-455 # Creamos otra rama
$ git branch # Listamos las ramas disponibles
#   develop
#   feature/ZEL-455
# * master
$ git branch -d feature/ZEL-455 # Borramos la rama de forma local
$ git branch -r # Obtener sólo las ramas remotas
$ git branch -a # Obtener sólo ramas remotas y locales

Eliminando las ramas de tu repositorio remoto

$ git push origin :feature/ZEL-455

git checkout

Ya vimos como rechazar los cambios con git checkout .

git checkout también tiene otras utilidades

# Cambiamos a la rama develop con todos los archivos del área de trabajo si los hay
$ git checkout develop
# Cambiamos a una rama que creamos
$ git checkout -b feature/ZEL-455
# Consultamos un commit, pero no para trabajar sobre él
$ git checkout 84ac4b0

git merge <rama>

Una vez creada la rama feature/ZEL-455 queremos unir nuestros cambios a la rama de desarrollo y posteriormente eliminar la rama ya no usada.

$ git checkout -b feature/ZEL-455
$ git checkout develop
$ git merge feature/ZEL-455
$ git branch -d feature/ZEL-455
$ git push origin :feature/ZEL-455

resolución de conflictos

$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

 Si hay modificaciones dispares en una misma porción de un mismo archivo en las dos ramas distintas que pretendes fusionar, Git no será capaz de fusionarlas directamente.

Podemos encontrar conflictos que deberemos resolver manualmente.

resolución de conflictos

 <<<<<<< HEAD:mergetest
 This is my third line
 =======
 This is a fourth line I am adding
 >>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest

 Si accedemos al archivo conflictivo tenemos:

<<<<<<< Comienzo del conflicto

======= Break point de la comparación

>>>>>>> Final del conflicto

Una vez seleccionado el código correcto, preparamos y confirmamos los cambios.

gestión de ramas

$ git branch
#   develop
#   feature/ZEL-455
#   feature/ZEL-461
#   feature/ZEL-464
#   feature/ZEL-466
#   feature/ZEL-467
# * master

Es importante tener unos remotes ordenados y controlar el número de ramas que hay en ellos. Un buen truco para eliminar ramas que ya no son usadas y están incluidas en otras es:

git branch --merged

gestión de ramas

$ git branch --merged
#   develop
#   feature/ZEL-461
#   feature/ZEL-464
#   feature/ZEL-466
#   feature/ZEL-467
# * master

La rama feature/455 tiene nuevos cambios, mientras que el resto de ramas ya fueron fusionadas con master y develop. Si hacemos git branch --merged desde la rama master obtendremos todas las ramas que ya se fusionaron en ella y que podrían borrarse con tranquilidad. Es decir, todas menos la 455.

gestión de ramas

$ git branch --no-merged
#   feature/ZEL-455

Podemos tener el resultado contrario con:

git branch --no-merged

git pull <remote> <branch>

$ git pull origin master
#   remote: Counting objects: 7, done.        
#   remote: Compressing objects: 100% (4/4), done.        
#   remote: Total 4 (delta 2), reused 0 (delta 0)        
#   Updating 361303d..f2cd831
#   Fast forward
#    _layouts/default.html |    1 +
#     1 files changed, 1 insertions(+), 0 deletions(-)

Para obtener los cambios de un repositorio remoto utilizaremos git pull, al realizar la descarga se producirá una fusión con el código actual, que como vimos anteriormente con merge ocasionalmente puede provocar conflictos.

git push <remote> <branch>

$ git push origin serverfix
#  Counting objects: 20, done.
#  Compressing objects: 100% (14/14), done.
#  Writing objects: 100% (15/15), 1.74 KiB, done.
#  Total 15 (delta 5), reused 0 (delta 0)
#  To git@github.com:schacon/simplegit.git
#   * [new branch]      serverfix -> serverfix

Para publicar nuestros cambios en un repositorio remoto utilizaremos git push. 

Si un colaborador ha hecho cambios, git rechazará tu subida para que en primer lugar bajes sus cambios, los fusiones y entonces ya puedes realizar la subida.

git rebase

En lugar de mezclar los cambios, podemos reorganizarlos con git rebase en una sóla rama. 

$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

git rebase

Vuelve al commit común y empiezan a aplicarse los cambios de una rama a otra, teniendo las siguientes opciones en caso de conflicto:

  • --continue
  • --skip
  • --abort
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

En este caso se aplicarían los commits de la rama experiment encima de los de la rama master, a partir del commit común.

viajando al pasado:

git reset

Con git reset podemos volver a commits anteriores o bien para desechar los commits que queden por el camino, o para continuar desde el punto en el que se cometió un error manteniendo todos los cambios actuales.

git reset --soft <commit>

De esta manera podemos volver a un commit anterior, manteniendo todos los cambios que se hicieron hasta dicho commit en nuesto área de preparación. 

git status
En la rama master
nothing to commit, working directory clean

$ git log
commit 0bef7ddd058c408d0d0ebd68bedcff4c04cc9b44
Author: Juanen <jbernal@murdock.es>
    Add kitkat for Juanen

commit 14563bab48595a829d5e469afc458d94f3e66f05
Author: Juanen <jbernal@murdock.es>
    First commit.

$ git reset --soft 14563bab48595a829d5e469afc458d94f3e66f05
$ git status
En la rama master
Cambios para hacer commit:
  (use «git reset HEAD <archivo>...«para eliminar stage)

	modified:   despensa/kitkat/juanen
	new file:   parche.patch

git reset --hard <commit>

Queremos definitivamente volver a un commit y no mirar atrás, perdiendo los cambios de los commits intermedios.

git status
En la rama master
nothing to commit, working directory clean

$ git log
commit 0bef7ddd058c408d0d0ebd68bedcff4c04cc9b44
Author: Juanen <jbernal@murdock.es>
    Add kitkat for Juanen

commit 14563bab48595a829d5e469afc458d94f3e66f05
Author: Juanen <jbernal@murdock.es>
    First commit.

$ git reset --hard 14563bab48595a829d5e469afc458d94f3e66f05
$ git status
En la rama master
$ git log
commit 14563bab48595a829d5e469afc458d94f3e66f05
Author: Juanen <jbernal@murdock.es>
    First commit.

política de ramas

Evita trabajar en master, usa una política de ramas que te facilite el trabajo en equipo y cambiar rápidamente en casos de emergencia, como git flow:

  • master
  • develop
  • feature
  • release
  • hotfix

Gitflow

y más y más y más

git no acaba aquí, hay más comandos y posibilidades muy útiles.

 

  • --force
  • git blame
  • git grep
  • git cherry-pick
  • etc, etc

Bibliografía

  • https://librosweb.es/libro/pro_git
  • http://git-scm.com/docs

¿Preguntas?

Introducción a GIT

By gabrielc

Introducción a GIT

  • 574