Introduccion a Git
En esta entrada os voy a dar unas pinceladas, el ABC imprescindible para poder manejarse con GIT. Antes de empezar os contaré un poco de historia sobre el Git. Allá por 1991, Linus Torwalds andaba con el desarrollo del kernel de Linux. Este proyecto se llevaba de forma colaborativa por un conjunto de personas que contribuian desinteresadamente al mismo. Hasta 10000 personas y mas de 1000 empresas llegaron a participar en el proyecto. Para poder coordinar a este equipo de desarrollo distribuido por todo el mundo rapidamente se hizo necesaria una herramienta para colaborar.
El 25 de agosto de 1991 Linus Torwalds publicó en una entrada en las newsreaders del grupo comp.os.minix lo siguiente:
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).
Pues se equivocó, y de largo. Sí acabaría siendo profesional, sí se hizo muy grande y afortunadamente, en general, sigue siendo un sistema gratuito.
Inicialmente se empezó usando una herramienta, un DVCS o distributed version control systems llamado BitKeeper. Con el tiempo la relación con la empresa y el equipo se interrumpió y Torwalds su propia herramienta: Git. El resto es historia.
Pero vamos al tema. Lo primero que hay que entender es que Git es un sistema distribuido en el que todos los nodos tienen toda la información de todos los archivos, con lo que cualquiera de éstos puede comportarse como un cliente o un servidor.
Lo segundo que hay que interiorizar es los estados por lo que puede pasar un archivo: Sin seguimiento, sin modificar, modificado y en stage o escenario.Pues ya está, ya sabes todo lo necesario para poder trabajar con Git, ;^)
Git se basa en la gestión de tres arboles de archivos, Working directory, Stage (o Index) y Head, que apunta al ultimo commit.
Ahora veremos como se gestionan cada uno de los estados como se transiciona entre ellos y que implicaciones tienen. A continuación miraras esta imagen, con detenemiento, la interiorizaras y memorizaras a fondo:
Basicamente: tenemos un archivo nuevo, sin seguimiento, lo añadimos y asi que pasa a stage, lo comiteamos y entonces pasa a Head o Repositorio.
Vamos a ver un ejemplo:
Entramos en nuestro proyecto, que no es mas que una carpeta normal y corriente y creamos un archivo:
daniel@botijito:~/proyectos/gitdoc$ ls
t1.txt
daniel@botijito:~/proyectos/gitdoc$ cat t1.txt
hola mundo
Ejecutamos git init:
daniel@botijito:~/proyectos/gitdoc$ git init
Initialized empty Git repository in /home/daniel/proyectos/gittest/.git/
Ya tenemos un repositorio!!! vamos a ver el estado en el que está, con git status. Este va a ser un comando importantisismo que nos dará informacion de lo que está pasando:
daniel@botijito:~/proyectos/gitdoc$ git status
En la rama master
Commit inicial Archivos sin seguimiento:
(use «git add <archivo>...» para incluir en lo que se ha de confirmar)
t1.txt
Nos dice qu estamos en la rama master y nos propone un add, pues se le aplicamos: git add, y pasamos nuestro archivo a Stage:
daniel@botijito:~/proyectos/gitdoc$ git add t1.txt
daniel@botijito:~/proyectos/gitdoc$ git status
En la rama master
Commit inicial
Cambios para hacer commit:
(use «git rm --cached <archivo>...» para sacar del stage)
new file: t1.txt
Excelente! ya tenemos un archivo en stage, y nos informa de la posibilidad de sacar del stage con un: git rm --cached
Vamos a por el commit:
daniel@botijito:~/proyectos/gitdoc$ git commit -m "Primer commit"
[master (root-commit) 2093519] Primer commit
1 file changed, 1 insertion(+)
create mode 100644 t1.txt
Ya hemos hecho nuestro primer commit, veamos el estado a ver que dice:
daniel@botijito:~/proyectos/gitdoc$ git status
En la rama master
nothing to commit, working directory clean
Perfecto, todo en orden, no hay cambios y todo está subido. Editamos nuestro archivo y lo volvemos a poner en estado con cambios. Consultamos su estado:
daniel@botijito:~/proyectos/gitdoc$ git status
En la rama master
Cambios no preparados para el commit:
(use «git add <archivo>...» para actualizar lo que se confirmará)
(use «git checkout -- <archivo>...» para descartar cambios en el directorio de trabajo)
modificado: t1.txt
No hay cambios agregados al commit (use «git add» o «git commit -a»Efectivamente nos dice que esta modificado y nos sugiere o bien un add o 'commit -a'. Se puede hacer add y luego un commit o hacerlo todo en un paso, con '-a', esto nos ahorrará tiempo.
daniel@botijito:~/proyectos/gitdoc$ git commit -a -m "otro commit"
[master bb13b9a] mensaje
1 file changed, 1 insertion(+), 1 deletion(-)
Añadimos y comiteamos, hecho!, nos informa de que han habido un archivo cambiado, un añadido y un borrado. Si quisieramos ver una vista global tenemos el log, que nos dará una entrada por cada commit que haya habido, identificado por un id, escribimos: git log:
daniel@botijito:~/proyectos/gitdoc$ git log
commit bb13b9aebaaced4646951ea472c59064e89bc392
Author: Daniel Gimeno <daniel.gimeno@gmail.com>
Date: Sat Dec 23 20:25:48 2017 +0100
otro commit
commit fb23c3ec9dfd55ec83da77d2b81c26259496483d
Author: Daniel Gimeno <daniel.gimeno@gmail.com>
Date: Sat Dec 23 20:25:26 2017 +0100
Primer commit
Vemos como hay 2 commits. Si quisieramos revisar un comit, para ver que ocurrio ahi podríamos consultarlo con un git show <hash>, asi:
daniel@botijito:~/proyectos/gitdoc$ git show 20935191e77538868c1ecacfb71fbb0fc126adda
commit 20935191e77538868c1ecacfb71fbb0fc126adda
Author: Daniel Gimeno <daniel.gimeno@gmail.com>
Date: Sat Dec 23 19:34:10 2017 +0100
Hola
diff --git a/t1.txt b/t1.txt
new file mode 100644
index 0000000..bc17c93
--- /dev/null
+++ b/t1.txt
@@ -0,0 +1 @@
+hola!
Hasta aquí es lo que aplica a la gestion de un archivo en local. Hemos dicho que se trata de un repositorio distribuido, quiere decir que podriamos subirlo a un repositorio remoto o por el contrario hacer una copia de un servidor remoto en nuestro local. Tenemos el siguiente escenario: queremos una copia de un servidor git remoto, por ejemplo de un proyecto molón de github, vamos a nuestra carpeta que albergará nuestra copia y hacemos:
git clone url-del-proyecto-git.
Vamos a clonar un proyecto, pero como no tenemos ningun sitio desde donde hacer un clone vamos a hacer una cosa, nuestro anterior proyecto, el que tenia un archivo, lo vamos a colgar en Github. Así que nos vamos a github.com y le damos a crear un proyecto. Habrá que crearse una cuenta obviamente. Le damos a new Project, le ponemos un nombre, una descripción y le damos a next y nos contesta que hagamos lo siguiente:
1.- echo "# test" >> README.md
2.- git init
3.- git add README.md
4.- git commit -m "first commit"
5.- git remote add origin https://github.com/danielgimeno/test.git
6.- git push -u origin master
Vamos a comentar las lineas. En la primera vuelca en el archivo readme la salida del comando echo con un '# test'. En la 2nda creamos un repo, esto ya lo hemos hecho, 3ra y 4a, añadimos y comitemamos el archivo readme. Hasta ahora nuestro repo era una isla y estaba aislado, ahora viene lo interesante. En la quinta linea le indicamos a nuestro repositorio local que esta conectado con el repositorio remoto indicado por esa url y por ultimo ejecutamos un push que llevará nuestros cambios al repositorio remoto. Una vez conectado nuestro local con el remoto podemos comprobar que esta correctamente dado de alta con remote -v
daniel@botijito:~/proyectos/gitdoc$ git remote -v
origin https://github.com/danielgimeno/test.git (fetch)
origin https://github.com/danielgimeno/test.git (push)
Y como dijimos anteriormente podriamos clonar nuestro proyecto en el ordenador de la oficina con un :
git clone https://github.com/danielgimeno/test.git
Ahora imeginemos que han pasado varios dias y nuestro proyecto ha quedado dessincronizado con respecto a lo que tenemos arriba, ejecutaremos un git pull. Esto nos descargará todos los cambios del resto de desarrolladores a nuestra copia local:
daniel@botijito:~/proyectos/gitdoc$ git pull
Already up-to-date.
Como nadie ha subido nada, nos indica que estamos al dia.
Con esto ya hemos dado nuestros primero pinitos con el tema de movernos dentro de un repo, subir y bajar archivos. En un segundo capitulo os hablaré de las ramas donde radica uno de sus grandes virtudes. Git tiene una curva de aprendizaje relativamente complicada, ahora solo resta practicar, practicar y practicar.