En este tutorial te voy a guiar paso a paso en el uso del control de versiones Git. Vas a ver ejemplos con capturas de pantalla en las que aparece la información que muestra Git cada vez que ejecutas un comando y también te escribo cada comando para que puedas copiar y pegar fácilmente para aplicarlo en tu proyecto.
Para comenzar a trabajar con Git necesitarás un terminal desde el que ejecutar las instrucciones por línea de comandos y la aplicación instalada, que puedes descargar de la web oficial.
También puedes orientarte en este vídeo dónde explico los conceptos básicos y cómo funciona este tutorial:
Índice de contenidos del artículo
Si trabajamos en local (comenzamos en la imagen por la izquierda), inicializamos el directorio de trabajo (working directory). Podemos trabajar (editar ficheros) en el directorio de trabajo.
Con el comando Git add enviamos los cambios a staging, que es un estado intermedio en el que se van almacenando los archivos a enviar en el commit. Finalmente con commit lo enviamos al repositorio local.
Si queremos colaborar con otros, con push subimos los archivos a un repo remoto y mediante pull podríamos traer los cambios realizados por otros en remoto hacia nuestro directorio de trabajo.
Si comenzamos trabajando en remoto, lo primero que hacemos es un clon de la información en el directorio local.
Con git help en el terminal obtenemos ayuda.
Vamos a mirar la ayuda de configuración con
#git help config
Como mínimo debemos configurar el nombre y el email en la aplicación con los siguientes comandos:
git config --global user.name "Tu nombre aquí"
git config --global user.email "tu_email_aquí@example.com"
Para comprobar podemos usar:
git config -–global –list
Lo que hace el sistema es crear un archivo de texto llamado .gitconfig, por lo que podemos mostrarlo también con cat si estamos usando un sistema Linux:
cat ~/.gitconfig
Nos situamos en la carpeta en la que queremos trabajar. Nos aseguramos con pwd, para saber dónde estamos.
Ahora con git init y el nombre del proyecto, creamos un nuevo proyecto:
git init prueba01
Esto crea una carpeta con el mismo nombre y en su interior, podemos observar con ls -a que se crea una subcarpeta oculta .git para el control y gestión de la herramienta.
Usamos Initializr para descargar un proyecto demo, lo ponemos en una carpeta, nos situamos en ella y ejecutamos simplemente git init.
Ahora vamos a crear algún archivo en el primero de los proyectos. Yo he creado un archivo README.md con el contenido: #Demo de Git.
Ahora, en la carpeta del proyecto ejecutamos
git status
Podemos ver los detalles. Estamos ubicados en la rama máster y que tenemos un archivo que no ha sido agregado aún.
Lo primero que vamos a hacer es agregarlo al staging, también llamado Git Index, mediante el comando git add:
git add README.md
Ahora vemos que el archivo ya está esperando a ser enviado al repo mediante commit.
Al ejecutar commit no especificamos qué archivos se enviarán. Se envían todos los que estén en staging. Vamos a agregar la opción -m para agregar un mensaje al commit, por ejemplo “commit inicial”:
git commit -m “commit inicial”
Veremos un mensaje similar a este:
Si hacemos un status ahora veremos que el área de staging está vacía y no hay ningún commit pendiente.
Ahora vamos a agregar más contenido al archivo README y hacemos un status.
Veremos que ahora el sistema nos indica que hay cambios no enviados al staging:
Con el mismo procedimiento de antes, agregamos (add) y hacemos un nuevo commit:
También podemos hacer el add y el commit en un solo paso con:
git commit -a
Tal como nos recomienda el propio Git en la captura de arriba. Si queremos también agregar el mensaje quedaría
git commit -am “msj”
Podemos hacer algunos cambios más y agregar otro archivo, por ejemplo, un index.html al proyecto.
En este caso vamos a agregar los archivos modificados o nuevos al staging de forma recursiva con
git add .
Un nuevo commit:
Vamos a volver a hacer algún cambio y lo agregamos al staging. Si nos fijamos en la captura de la anterior operación add, el sistema nos indica que podemos sacar un archivo del stage con git reset HEAD y el nombre del archivo. Lo probamos con README:
git reset HEAD README.md
Un nuevo status nos indicará que hay uno en el staging y otro por agregar:
Como podemos ver, también podemos descartar los cambios en el directorio de trabajo con checkout:
git checkout -- README.md
Esto devuelve nuestro archivo readme al estado anterior.
Recuerda que puedes consultar la ayuda para ver más opciones y comandos. Aquí puedes algunos ejemplos adicionales.
Con git log podemos ver el histórico de operaciones que hemos hecho:
git log
Podemos ver que los commit se han hecho en orden cronológico inverso con los distintos usuarios y que cada uno tiene asociado su clave y su fecha.
Con git help log podemos ver las opciones que existen. Un ejemplo de una vista compacta y colorida sería:
git log --oneline --graph --decorate --color
Imaginemos que uno de los archivos que ya están en el repositorio de git tras un commit no lo queremos allí. Podemos usar el comando rm de remove y el nombre del archivo:
git rm index.html
Podemos observar que el status nos indica que el cambio ejecutado para el archivo a eliminar está en el staging. Para eliminarlo debemos hacer un nuevo commit:
Ahora veremos que el archivo index ya no está en el directorio de trabajo.
Ahora vamos a agregar un nuevo archivo, lo agregamos al staging y hacemos un commit. Vamos a eliminarlo manualmente desde el sistema de archivos del SO, no desde Git.
Ahora elimino el archivo humans.txt y hacemos un status:
Como la misma pantalla indica, podemos usar add o rm para que definitivamente los cambios se agregan al staging.
En este caso se ha usado un add y tras un commit se ha ejecutado el borrado en el repo.
Vamos a crear una nueva carpeta “style” para alojar un nuevo archivo de estilos css que ahora se encuentra en la carpeta raíz del proyecto y ya en el repositorio.
Probamos primero a mover manualmente el archivo:
En este caso vamos a ejecutar git commit -a para agregar al staging y hacer el commit con una sola operación:
Ojo! Si volvemos a hacer un status veremos que la carpeta styles no se ha actualizado correctamente. Tendremos que hacerlo recursivo con git add . y luego el commit.
Ahora disponemos de un archivo que no queremos que se agregue nunca al repo, por ejemplo un archivo de log.
En Linux Debian, con el comando nano podemos editar un archivo en un editor de textos en el terminal.
Vamos a editar el archivo .gitignore, en el que especificamos los archivos a ignorar en líneas independientes.
nano .gitignore
Y en el archivo, que aparecerá vacío, agregamos en la primera línea *.log. Guardamos y salimos.
Ahora hacemos un status y veremos el archivo .gitignore para agregar a staging:
También hemos hecho un nuevo commit.
Lo primero es crear la autenticación SSH. Nos dirigimos a la carpeta raíz de usuario, creamos una carpeta llamada .ssh. Nos movemos a ella y mediante el comando shh-keygen creamos una clave asociada a la cuenta de correo. Vamos a emplear una clave tipo RSA, de modo que el comando quedaría:
ssh-keygen -t rsa -C “correo@dominio.com”
Nos pregunta que dónde queremos guardar el fichero con la clave. Podemos seleccionar la opción predefinida.
Con ls -al podemos ver en detalle nos nuevos archivos generados en la operación.
El archivo .pub es la clave pública, que enviaremos a GitHub. Para ello debemos abrir el documento y copiar su contenido.
El editor Nano puede ser un poco complejo de usar para estas operaciones. Aquí tienes otras alternativas para Linux: How to open a particular file from a terminal?. Yo usaré
xdg-open nombre_archivo
Ahora iniciamos sesión en GitHub y nos vamos a Settings à SSH Keys y creamos una nueva, indicando un nombre descriptivo, recuerda que esto se asocia al equipo desde el que trabajamos, y la clave pública que hemos copiado previamente.
Ahora ejecutamos
ssh -T git@github.com
Y deberíamos autenticarnos correctamente:
Primero vamos a crear un nuevo repositorio desde la aplicación web de GitHub con la sesión iniciada.
Una vez creado, en la siguiente pantalla hacemos clic en SSH en la parte superior para ver las instrucciones de envío mediante línea de comandos.
Ahora nos movemos al proyecto con el que queremos trabajar. Vemos que el status no hay nada pendiente y ejecutamos el primer comando. Usando después…
git remote -v
El comando remote sirve para ver los repositorios remotos asociados. con la opción -v vemos la URL:
Las URLs que vemos en la captura anterior son de tipo SSH, indicativo de que podríamos enviar. También podemos agregar repositorios de otros usuarios para recibir con el comando git remote add [nombre] [url].
Ejemplo: $ git remote add pb git://github.com/paulboone/ticgit.git
Para recibir los ficheros de uno de estos repositorios de otro usuario usamos el comando fetch seguido del nombre que hemos puesto en el comando anterior.
Ejemplo: git fetch pb
Ahora vamos a enviar los archivos en local al repo remoto con push y la opción -u para establecer un enlace entre ellos, especificando también el repositorio remoto (origin) y la rama de trabajo (master), quedando:
Una vez establecido el enlace no hará falta usar la opción -u, quedando la instrucción para actualizar los cambios en el repositorio remoto de la siguiente manera:
git push origin master
Ahora podemos ver el repositorio actualizado en GitHub:
Ahora vamos a modificar o agregar algún archivo al repo local y actualizar de nuevo el remoto.
Si vemos el status ahora, este nos indica que hay cambios pendientes de sincronizar con el remoto:
Aunque ahora estoy trabajando sólo, lo lógico es solicitar los últimos cambios mediante un pull, antes de enviar los nuestros con push, para evitar conflictos con otros miembros del equipo. De modo que ejecutamos:
git pull origin master
git push origin master
Ya podemos ver los nuevos cambios en el repositorio remoto.
Al hacer pull, el sistema recupera y trata de unir la rama remota con la local, mientras que con el comando fetch que veíamos antes no. Más info en la documentación oficial.
Para ejecutar el ejecutable de las guest additions en Debian podemos usar la instrucción
sh VBoxLinuxAdditions.run
Desde un terminal con privilegios.
[…] Tutorial de Git. Manual básico con ejemplos […]
Muy bueno
Muchas gracias Robeto, me alegra que te haya sido útil