Git básico parte I

Creando un repositorio u obteniendo uno por ahí

En la publicación anterior pudimos ver como crear un repositorio nuevo utilizando el comando “git init“, pues bueno esa precisamente una forma de crear un repositorio.

Otra forma de crear un repositorio es usar la opción bare que nos permitirá crear un esqueleto de repositorio que podremos utilizar remotamente, pero esto lo veremos más adelante.

Otra forma de obtener un repositorio es copiar o “clonar” un repositorio ya existente, el cual puede ser de un sitio publico, como por ejemplo de github, o privado.

Para clonar un repositorio publico desde Internet basta con ejecutar el siguiente comando:

git clone

Por ejemplo:

git clone https://github.com/alexove/BadgetGenerator.git

Lo cual nos data un resultado similar al siguiente

[alexove@wayra Descargas]$ git clone https://github.com/alexove/BadgetGenerator.git
Cloning into 'BadgetGenerator'...
remote: Counting objects: 30, done.
remote: Total 30 (delta 0), reused 0 (delta 0), pack-reused 30
Unpacking objects: 100% (30/30), done.
Checking connectivity... done.
[alexove@wayra Descargas]$

Con estos simples pasos ya tenemos un repositorio clonado 🙂

Ciclo de vida de los archivos en git

Antes de entrar de lleno a guardar cambios, deshacerlos y todo lo demás, es importante conocer los estados por los que pasan los archivos dentro de nuestro repositorio. Solo dos estados son posibles:

  • Tracked.- O archivos en seguimiento, éstos están añadidos al repositorio y puede notarse si están modificados o no y otras operaciones.
  • Untracked.– Archivos que no están en el repositorio y no son seguidos.

¿Que quiere decir que esta en “seguimiento”?, aunque no hay una definición exacta de un “archivo en seguimiento” en este contexto, puedo decir que es algo similar a tener un documento de texto con contenido ya guardado, ese texto guardado “esta en seguimiento”. El nuevo texto que se agregue no estará en seguimiento hasta el momento que guardemos el documento. Cabe aclarar que cuando clonamos un repositorio, todos los archivos de este estan en el estado “Tracked” o en seguimiento.

A medida que editamos archivos, Git los ve como modificados, porque los hemos cambiado desde tu última confirmación. Se preparan estos archivos modificados y luego confirmamos todos los cambios, y asi el ciclo se repite. Este proceso queda ilustrado en la siguiente figura:

 

Guardando cambios en los repositorios

Preparando los archivos

Ya sea un repositorio clonado o un repositorio creado localmente, lo que debemos hacer antes de hacer un commit es preparar los archivos nuevos o modificados. esta operación consiste basicamente en ejecutar el comando: “git add”, el cual puede presentar las siguientes variastes:

git add <nombre/ruta a archivo>

Con el comando anterior se agregara o actualizara un archivo en el repositorio.

git add archivo1 archivo2 ...

Con esta variante en lugar de agregar un archivo agregamos más de uno en un solo comando.

git add *

Esta variante usa un caracter comodin y agrega todos los archivos.

git add .

Es similar a la anterior pero agrega el directorio actual.

Creo que hasta este punto es solo deducir otras variantes para agregar archivos al repositorio 🙂

Para ver en que estado anda nuestro repositorio ejecutamos el comando git status para poder ver si tenemos archivos listos, modificados o sin seguimiento en repositorio, por ejemplo:

[alexove@devmachine sgo]$ git status 
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
 
    modified:   README.md
 
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
 
    modified:   contributors.txt
 
[alexove@devmachine sgo]$

Como se puede ver en este ejemplo, tenemos un archivo listo (README.md) y un archivo que falta preparar (contributors.txt).

Ignorando archivos

Ahora bien, que pasa si NO queremos agregar un grupo de archivos, por ejemplo archivos generados por los compiladores o archivos de prueba, pues existe un modo muy simple que consiste en crear un archivo llamado “.gitignore”, no olvidar el punto delante del archivo, y escribir el nombre de los archivos o directorios que no queremos que se agreguen al repositorio.

Guardando de verdad

Una vez terminado el proceso de preparación lo que podemos hacer es confirmar los cambios, es decir guardar todos los cambios en el repositorio, con el comando git commit el cual mostrara un editor de texto en linea comandos donde podamos comentar los cambios en cada archivo individualmente:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#       new file:   README
#       modified:   benchmarks.rb
~
~
~
".git/COMMIT_EDITMSG" 10L, 283C

Otra forma es usar la variante git commit -m “Comentario” para que obviemos el hacer el comentario en cada archivo y se haga ese comentario de manera general.

El resultado de confirmar estos cambios sera una salida similar a la siguiente:

[alexove@devmachine sgo]$ git commit -m "Actualizacion de informacion general"
[master 2373530] Actualizacion de informacion general
 2 files changed, 3 insertions(+), 1 deletion(-)
[alexove@devmachine sgo]$

Viendo el histórico de cambios

Para ver el histórico de cambios simplemente se utiliza el comando git log el cual mostrara una salida similar a esta:

[alexove@devmachine sgo]$ git log
commit 23735302e428cd84afdaa8d36131c2c18d281015
Author: Alex Irmel Oviedo Solis <alexove@alexove.me>
Date:   Thu Dec 3 21:08:04 2015 -0500
    Actualizacion de informacion general
commit b2f0fa950bf7cbc18bdb308019f9aa64180c94c1
Author: Alex Irmel Oviedo Solis <alexove@alexove.me>
Date:   Sun Nov 8 20:40:16 2015 -0500
    README.md agregado
commit 4801f303b39e7a7e0bcd005a64cc268284d9252c
Author: Alex Irmel Oviedo Solis <alexove@alexove.me>
Date:   Sun Nov 8 20:38:52 2015 -0500
    Initial commit with contributors
       new file:   contributors.txt
commit 57f3afb0432f7bb6de870a898543fe9fb62f7b06
Author: Alex Irmel Oviedo Solis <alexove@devmachine.alexove.me>
Date:   Sun Nov 8 20:37:46 2015 -0500
    Avance dom nov  8 20:37:46 PET 2015

Pero si esta vista no es amigable, se puede usar la variante git log –graph para que muestre una vista grafica basica similar a la siguiente:

Una opción gráfica que me gusta mucho es gitg que nos ayudara a ver el historial más bonito 😉

Eso es todo por ahora, en la siguiente veremos otros aspectos del manejo de repositorios.

Saludos y mucha suerte 😀

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *