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
- 603