Comando "git config"

Una vez instalado Git, lo primero que se debe hacer es configurar el nombre de usuario y la dirección de e-mail. Todos los commits (cambios confirmados) que se hagan llevarán esta información.

git config --global user.name "Juan Matachin"
git config --global user.email juan.matachin@gmail.com

Se pueden configurar muchos otros elementos, como el editor que se usará cuando Git necesite que se introduzca un texto:

git config --global core.editor nano

Para comprobar los parámetros configurados utilizar el siguiente comando:

git config --list

Comando "git init"

El comando git init sirve para inicializar un repositorio de Git.

cd proyecto
git init

El fichero .gitginore

El fichero .gitignore incluye los patrones de los ficheros y directorios que no se desea incluir en el repositorio (ficheros que no son código fuente: compilados, librerías, ficheros temporales, etc.).

GitHub mantiene una lista de ejemplos de ficheros .gitignore para distintos lenguajes de programación: https://github.com/github/gitignore

A continuación, se muestra un ejemplo para Java, en este caso se definen algunos patrones para que no se guarden en Git los archivos *.class, *.log, *.jar, *.war, etc:

# Compiled class file
*.class

# Log file
*.log

# Package Files #
*.jar
*.war
*.ear
*.zip
*.tar.gz
*.rar

Directorio oculto .git

Se habrá creado un directorio oculto .git en el que se guardará la base de datos de todos los cambios, así como distintos elementos de la configuración de Git:

$ ls -la

drwxr-xr-x  10 matachin juan    320 30 oct 17:36 .git
-rw-r--r--   1 matachin juan     10 30 oct 17:35 .gitignore
drwxr-xr-x   3 matachin juan     96 26 oct 13:52 css
drwxr-xr-x   4 matachin juan    128 26 oct 13:37 imagenes
-rw-r--r--   1 matachin juan   2501 30 oct 17:33 index.html

$ cd .git
$ ls -la 

-rw-r--r--   1 matachin juan   23 30 oct 17:36 HEAD
drwxr-xr-x   2 matachin juan   64 30 oct 17:36 branches
-rw-r--r--   1 matachin juan  137 30 oct 17:36 config
-rw-r--r--   1 matachin juan   73 30 oct 17:36 description
drwxr-xr-x  12 matachin juan  384 30 oct 17:36 hooks
drwxr-xr-x   3 matachin juan   96 30 oct 17:36 info
drwxr-xr-x   4 matachin juan  128 30 oct 17:36 objects
drwxr-xr-x   4 matachin juan  128 30 oct 17:36 refs

En este directorio se guardará el repositorio con todo el histórico de cambios. Aunque no se lo estudia, es importante conocer que existe.

Comando "git status"

El comando explica de forma concisa el estado del repositorio:

git status

Comando "git add"

Se define la versión inicial añadiendo ficheros al repositorio, con el primer commit. El comando git add selecciona los ficheros a incorporar en el commit. Se va a añadir el fichero index.html y el directorio css. Se deja el directorio de imágenes para un commit posterior.

git add index.html
git add css
git add .gitignore
git status

Comando "git commit"

git commit -m "Primera versión del proyecto"

[master (root-commit) 2442726] Primera versión del proyecto
 3 files changed, 66 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 css/layout.css
 create mode 100644 index.html

El parámetro -m indica que la cadena que hay a continuación es el mensaje del commit. Todo commit debe tener un comentario en el que se indica el objetivo de los cambios introducidos.

Si no se usa el parámetro -m se abrirá el editor por defecto en el que se deberá introducir el mensaje. Es recomendable que la longitud no sea mayor de 72 caracteres.

Comando "git log"

Con el comando git log se pueden ver los cambios añadidos al repositorio.

git log

commit e88ee6540c8f264e5ff735bd291c6bf9d2935039 (HEAD -> master)
Author: Domingo Gallardo <domingo.gallardo@ua.es>
Date:   Thu Nov 30 19:19:36 2017 +0100

    Primera versión del proyecto

Como parte de la información se puede observar lo siguiente:

• Identificador del commit

• Autor del commit

• Fecha de realización del commit

• Comentario introducido en el commit

Sistemas de control de versiones distribuidos

Cada desarrollador tiene su propio repositorio y su copia de trabajo en su máquina.

Después de hacer un commit de los cambios, los demás no tienen acceso a ellos hasta que se los sube (push) al repositorio remoto central.

Para obtener los cambios del repositorio central hay que bajarlos (fetch) al repositorio local y actualizar la copia de trabajo.

El ciclo de trabajo básico es:

• Hacer uno o varios commits de los cambios en el repositorio local.

• Cuando se desea que los compañeros vean todos los cambios se hace un pushal repositorio central.

• Los compañeros hacen un fetchpara actualizar su repositorio local.

• Después actualizan su copia de trabajo.

Se debe notar que la confirmación (commit) y actualización (pull) sólo mueven los cambios entre la copia de trabajo y el repositorio local. Y al contrario, push y fetch suben y bajan cambios entre el repositorio local y el repositorio remoto.

Repositorios remotos

Varias formas de crear el repositorio remoto:

1. Servidor remoto en el que instalamos Git en modo servidor.

2. Servicios como GitHub, Bitbucket o GitLab.

3. Servidor remoto en el que instalamos un servicio como GitLab.

La forma más sencilla es utilizar GitHub o Bitbucket.

Comando "git push"

Para subir el repositorio local al remoto hay que utilizar los comandos que indica cada proveedor del repositorio, por ejemplo GitHub o Bitbucket

• El comando git remote add origin URL define la URL del repositorio remoto denominado origin.

• El nombre origin se usa por convención como el nombre del repositorio remoto principal (en git se puede definir más de un repositorio remoto).

• El comando git push -u origin master sube al repositorio origin la rama master (la única que existe por ahora). La opción -u hace que origin sea el repositorio remoto por defecto de la rama. Las siguientes veces que se haga push no se tendrá que indicar origin (en terminología de Git: la rama local master está haciendo tracking de la rama remota master en origin).

git remote add origin https://github.com/juan.matachin/proyecto.git
git push -u origin master

Username for 'https://github.com': juan.matachin
Password for 'https://juan.matachin@github.com': 
...
To https://github.com/juan.matachin/proyecto.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

Para que la contraseña se guarde en el disco local utilizar el comando que se indica a continuación (cuidado: que se guarda en texto plano)

git config credential.helper store

Se comprueba el estado del repositorio y se añade el directorio css

Se comprueba el estado del repositorio con git status y se añade el directorio imagenes con git add.

git status

git add imagenes
git status

El comando git add no añade el fichero al repositorio, sino que lo deja preparado para que se añada en el siguiente commit.

Se añade un segundo commit y se lo sube al repositorio remoto

git commit -m "Añadido directorio imagenes"

[master a854b8d] Añadido directorio imagenes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 imagenes/increibles.png

git push

Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 369 bytes | 369.00 KiB/s, done.
Total 4 (delta 0), reused 0 (delta 0)
To https://github.com/juan.matachin/proyecto.git
   e88ee65..0038905  master -> master

El comando git commit añade los cambios preparados por add al repositorio local.

El comando git push sube el commit del repositorio local al remoto (GitHub, Bitbucket o GitLab). Explorar el repositorio remoto para comprobar que el segundo commit se ha subido correctamente.

Zona de trabajo, stage y repositorio

Se puede entender mejor el funcionamiento de los comandos git add y git commit introduciendo el concepto de zona de stage.

En Git no es obligatorio introducir todos los cambios en el siguiente commit, sino que es conveniente seleccionar los cambios que se desae introducir en el commit.

El comando git add añade a la zona de stage los cambios que se quiere incluir en el nuevo commit. Además de usarlo para añadir nuevos ficheros que antes no estaban trackeados, también hay que usarlo para incluir los cambios que se desea que vayan en el siguiente commit.

El comando git commit añade los cambios que están en la zona de stage al repositorio local.

El commit debe contener un conjunto de cambios coherentes, que se agrupan en una unidad lógica que se describe en el mensaje del commit.

Un commit representa una nueva versión del proyecto.

No se debe commitear ficheros con errores de compilación o que no pasen los tests unitarios.

Añadir el cambio al stage

Hay ficheros cambiados, pero no hay cambios en el stage. Para añadir los cambios al stage se puede hacer con cualquiera de los siguientes comandos:

• Añadir los cambios de los ficheros del directorio css:

    git add css
  

• Añadir los cambios de todos los ficheros cuyo path empiece por c:

    git add c*
  

• Añadimos todos los cambios existentes:

    git add .
  

Realizar el commit

Comprobar el estado con git status:

Se ve en verde los cambios que están en stage, que entrarían en el siguiente commit. Hacer el commit de la siguiente forma:

git commit -m "Añadidos márgenes al documento"

[master 45b531a] Añadidos márgenes a la web
 1 file changed, 5 insertions(+)

No subir todavía al repo remoto

Con git status se verá que se han añadido los cambios al repositorio local:

Informa que la rama local está por delante (ahead) de la rama remota en origin (origin/master) por 1 commit. Por ahora, no se sube los cambios al repositorio remoto; se continúa desarrollando en el repositorio local.

Realizar el commit

Si se hace git status se observará la siguiente información:

Hay ficheros modificados y los cambios no se han añadido al stage. Para incluir los cambios en el stage hay que hacer git add o git commit -a. Este último comando realiza directamente el commit de todos los cambios existentes sin pasar por stage.

git commit -am "Añadimos cabecera de navegación"

[master 0e1ceb4] Añadimos cabecera de navegación
 2 files changed, 25 insertions(+)

Historia de commits

Para ver la historia de commits se puede hacer git log y el modificador --oneline (una línea):

git log --oneline

Se puede observar lo siguiente:

• Identificador del commit

• Ramas (master y origin/master)

• HEAD (Indicador de en qué rama se está actualmente)

• Una línea con la descripción de cada commit

• La rama origin/master (la rama remota) está 2 commits detrás de la rama local.

• Examinar el repositorio remoto para comprobar los commits que se han subido.

Subir los dos últimos commits al repositorio remoto

Hacer git push para publicar los dos commits en el repositorio remoto. Como anteriormente ya se hizo push con el parámetro -u ya no hace falta indicar el nombre de la rama remota:

git push

Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (9/9), 981 bytes | 327.00 KiB/s, done.
Total 9 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/domingogallardo/curso-git-repo1.git
   0038905..0e1ceb4  master -> master

Comandos "git diff" y "git checkout fichero(s)"

¿Hay alguna forma de comprobar qué cambios se han realizado en la copia de trabajo antes de realizar algún commit?

Se pueden comprobar los cambios realizados con:

git status
git diff

El comando git diff indica exactamente todos los cambios entre el anterior commit y el estado actual del espacio de trabajo. Si se desea eliminar todos los cambios introducidos en el espacio de trabajo (y volver al estado del anterior commit) realizar lo siguiente:

git checkout .

Opciones de "git diff"

Para mostrar los últimos cambios introducidos en el último commit en master se puede hacer:

git diff master~1 master

...
@@ -3,3 +3,25 @@ body {
   width: 70%;
   margin: 0 auto;
 }
+
+nav {
+  height: 100px;
+  display: flex;
+}
+
+nav img {
+   flex-basis: auto;
+}
...

También se puede usar el puntero HEAD como referencia de diff. Por ejemplo, para ver los cambios introducidos en el commit Añadidos márgenes al documento se puede hacer lo siguiente:

git diff HEAD~2 HEAD~1

...
--- a/css/layout.css
+++ b/css/layout.css
@@ -1 +1,5 @@
 /* Fichero CSS para completar */
+body {
+  width: 70%;
+  margin: 0 auto;
+}

En el comando anterior HEAD~1 indica el commit anterior al actual (59e0464) y HEAD~2 indica el anterior (5853e04). Sería equivalente a poner los números de commits. Se puede ver los cambios introducidos en un commit concreto usando el número de commit y el símbolo ^ que indica el anterior:

git diff 5853e04^ 5853e04

Algunos comandos vistos hasta ahora

Mover cambios entre el espacio de trabajo y stage

Utilizar los siguientes comandos para comprobar cómo mover los cambios entre el espacio de trabajo y el stage:

• git status

• git add <fichero(s)>

• git reset HEAD <fichero(s)>

Añadir un fichero nuevo prueba.txt al espacio de trabajo y probar los comandos anteriores con él. Terminar eliminando todos los cambios y recuperando el estado del último commit haciendo:

git checkout .
git clean -fd

Eliminar y renombrar

Hay dos posibles formas de eliminar y renombrar ficheros en un repositorio:

• Se los elimina y renombra con los comandos del sistema operativo y después se hace un git add para incluir esos cambios en el stage.

• Se los elimina y renombra con los comandos propios de git:

  • git rm <fichero> para eliminar un fichero (o un patrón)

  • git mv <nombre-antiguo> <nuevo-nombre> para renombrar un fichero del repositorio.

Probar renombrar y eliminar (1)

Añadir un fichero prueba.txt al repositorio local mediante un commit. Modificar su nombre usando el sistema operativo. Git no se da cuenta de que es un archivo renombrado y lo ve como que se ha borrado un fichero y añadido otro:

mv prueba.txt nueva-prueba.txt
git status
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    prueba.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        nueva-prueba.txt

Cuando se añaden todos los cambios al stage, Git se da cuenta de que se había renombrado el fichero:

git add .
git status
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        renamed:    prueba.txt -> nueva-prueba.txt

Probamos renombrar y eliminar (2)

Hacer commit para incluir los cambios en el repositorio:

git commit -m "Cambiado nombre fichero"
[master 2cbc265] Cambiado nombre fichero
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename prueba.txt => nueva-prueba.txt (100%)

Por último, eliminar el fichero con el comando de Git git rm:

git rm nueva-prueba.txt
rm 'nueva-prueba.txt'

El comando almacena el cambio en el stage:

git status
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        deleted:    nueva-prueba.txt

Se confirma el borrado para eliminar el fichero del espacio de trabajo y del repositorio:

git commit -m "Borrado fichero"
[master ee1b1db] Borrado fichero
 1 file changed, 1 deletion(-)
 delete mode 100644 nueva-prueba.txt

Moverse atrás en el tiempo con "git checkout"

El comando git checkout commit permite mover el espacio de trabajo a un commit determinado.

• Examinar la historia de commits con git log --oneline y copiar el identificador de uno de ellos.

• Ejecutar git checkout:

git checkout 0bf82cd
Note: checking out '0bf82cd'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 0bf82cd... Layout principal y margen

El identificador HEAD

El identificador HEAD representa la posición del espacio de trabajo:

git log --all --oneline
e498cdc (origin/master, master) Últimos ajustes
77a127a Añadida tipografía y colores
0bf82cd (HEAD) Layout principal y margen
3fd14f1 Añadimos cabecera de navegación
59e0464 Añadidos márgenes al documento
5853e04 Añadido directorio imagenes
2442726 Primera versión del proyecto

Crear nuevos commits en el pasado

Estando en un commit pasado, con un HEAD detached (significa que HEAD no está en la cabeza de ninguna rama) se puede mirar, hacer cambios, probar cosas y hacer commits con esos cambios. Esos commits quedarán al margen de la rama principal.

# Cambiamos el fichero index.html
git commit -am "Cambiado el título"
git log --oneline --graph --all
* 9b4ef00 (HEAD) Cambiado el título
| * e498cdc (origin/master, master) Últimos ajustes
| * 77a127a Añadida tipografía y colores
|/ 
* 0bf82cd Layout principal y margen
* 3fd14f1 Añadimos cabecera de navegación
* 59e0464 Añadidos márgenes al documento
* 5853e04 Añadido directorio imagenes
* 2442726 Primera versión del proyecto

Grafo de commits

La figura muestra el grafo de commits del proyecto hasta ahora. El espacio de trabajo se encuentra en HEAD, en el commit que se acaba de crear. Las ramas master y origin/master (rama remota) se siguen encontrando en el mismo sitio, el último commit de la rama principal.

Volver al presente

Se puede volver al presente haciendo un git checkout master.

git checkout master
Warning: you are leaving 1 commit behind, not connected to
any of your branches:

  9b4ef00 Cambiado el título

If you want to keep it by creating a new branch, this may be a good time
to do so with:

 git branch <new-branch-name> 9b4ef00

Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

Git informa que se debería crear una rama en el commit que se ha hecho si quiere conservarlo en la historia. Durante un tiempo se podría acceder a este commit por su identificador.

Grafo de commits después de volver a master

¿Cuál sería el grafo de commits después de volver a master?

Comando "git tag"

Una etiqueta (tag) no es más que un nombre con el que nos referimos a un commit concreto. Se puede añadir una anotación a la etiqueta con la opción -a y -m. Por ejemplo, se puede etiquetar el commit actual con:

git tag -a v0.1 -m "Mi versión 0.1"

También se pueden etiquetar commits pasados (esta vez no se usa -a y sólo se define el nombre de la etiqueta)

git tag v0.0 5853e04

El resultado en la historia de los commits:

git log --oneline
e498cdc (HEAD, tag: v0.1, origin/master, master) Últimos ajustes
77a127a Añadida tipografía y colores
0bf82cd Layout principal y margen
3fd14f1 Añadimos cabecera de navegación
59e0464 Añadidos márgenes al documento
5853e04 (tag: v0.0) Añadido directorio imagenes
2442726 Primera versión del proyecto

Subir los tags al repositorio remoto

Para subir las etiquetas al repositorio hay que usar la opción --tags al hacer un push:

git push --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 173 bytes | 173.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To https://github.com/domingogallardo/curso-git-repo1.git
 * [new tag]         v0.0 -> v0.0
 * [new tag]         v0.1 -> v0.1

Resumen de los últimos commandos