Git(III)

Hoy quiero continuar la breve introducción de que hice sobre el funcionamiento de esta herramienta de control de versiones, en este caso centrarme en los comandos que nos van a servir para construir un repositorio Git, para ello vamos a utilizar Git Bash. Para ello vamos a ver como podemos empezar un repositorio:

• $git init: se utiliza para inicializar un repositorio en un directorio en un directorio ya existente. Decir que cuando se ejecuta en el directorio creado , nos crea un archivo oculto .git, este nos provee de una serie de archivos que nos ayudan con el Sistema de control de versiones. Además, debemos tener en cuenta que si no utilizamos git init, el archivo o directorio no se convierte en un repositorio.
• $git add *.c o $git add NombreArchivo: si queremos añadir archivos que hemos creado aparte en Git atendiendo a su extensión o en el otro caso añadir un archivo por su nombre. Debemos tener en cuenta que estos archivos estarían en el staged.
• $git commit -m 'primera versión del proyecto': esta orden la utilizamos para poner un mensaje que nos indica cuando hemos hecho el commit.
• $git clone git://github.com/ o $git clone git://github.com/ migrit: para clonar archivos que hemos creado, u otros códigos de otros proyectos distintos. Con la orden migrit lo que indicamos es que clone el repositorio en otro indicando el nombre. También, para clonar se pueden utilizar diferentes protocolos: git, http(s), ssh.

En referente a los archivos que tenemos en nuestro directorio pueden estar en 2 estados: untracked o tracked.

• untracked (no rastreado): son todos los demás archivos, los que fueran después de haber realizado el commit.
• tracked (rastrado): son los archivos que fueron en el último commit. Estos archivos pueden estar en tres estados: unmodified, modified y staged.

Por ejemplo, si clonamos un repositorio los archivos serían tracked y unmodified, dado que, no hemos hecho ningún cambio. Para que un archivo no sea un archivo tracked, habría que eliminar ese archivo del repositorio. Pero bueno, lo más importante es que para ver el estado de los archivos vamos a utilizar $git status.

Es muy importante saber que guardar un archivo no tiene nada que ver con el control de versiones. Cuando modificamos un archivo, y después lo añadimos, su estado sería modified en el stage (color verde), pero si ahora al modificar ese mismo archivo y lo guardamos. El archivo tendría el estado modified pero no en el stage (color rojo).

Una vez en este punto, voy a intentar exponer un caso que me surgió cuando yo lo probé por mi mismo. Bien partimos desde la posición donde ya hemos realizado el commit, ahora para que podamos tener el archivo en el que trabajamos en GitHub debemos utilizar el siguiente código $git remote add origin git@github.com:tunombre/AprendiendoGit.git, después, $git push -u origin master. Al ejecutar por primera vez esta orden me daba un error a grosso modo, es el siguiente:

Este error indica que la punta de tu rama está detrás de la rama remota, es decir, que hay modificaciones posteriores a tu última sincronización. Rechaza por lo tanto el push, pero ahora bien, vamos a hacer un pull para ver qué es lo que ha fallado, para ello utilizamos $git pull -u origin master. Al hacer esto podemos ver que sale:

Este git pull indica algo así como que el conflicto de fusión no tiene forma de combinar los dos ficheros porque hay cambios en la misma línea. Lo que yo puedo entender, es que hay un problema con los dos master, el que creemos en Git y el de GitHub; por tanto si ejecutamos ahora otra vez $git push -u origin master, lo tendríamos bien. Ahora si miramos el repositorio en GitHub ya lo tendríamos.