Text
Text
$ 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 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 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 init
$ git clone git://github.com/schacon/grit.git mygrit
Inicializar repositorio
Clonar repositorio
$ 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 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 .
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
Excluir todos los archivos que no tengan que ver con la estructura de tu proyecto:
.gitignore admite:
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
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
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
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:
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
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
Algunas opciones
Git te ayuda a solucionar tus errores
Hice commit demasiado rápido:
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend
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
#
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.
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
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
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.
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
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
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
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
$ 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.
<<<<<<< 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.
$ 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
$ 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.
$ git branch --no-merged
# feature/ZEL-455
Podemos tener el resultado contrario con:
git branch --no-merged
$ 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 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.
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
Vuelve al commit común y empiezan a aplicarse los cambios de una rama a otra, teniendo las siguientes opciones en caso de conflicto:
$ 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.
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.
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
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.
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:
git no acaba aquí, hay más comandos y posibilidades muy útiles.