Prólogo

Trabajar con git nos permite tener un control de la evolución del código y nos sirve (por ejemplo) para poder recuperar versiones anteriores sin esfuerzo

En esta entrada te explico lo básico de git, y lo hago con mi editor favorito, el Visual Studio Code que ya lleva incorporado git de serie y nos facilita la tarea (el editor te lo puedes descargar en su página web)

Funcionamiento

Git trabaja con branch (ramas) como manera de separar desarrollos que pueden ir paralelos y que se irán juntando a medida que estén terminados (la rama principal se conoce como master)

A partir de allí, la estructura de git estaría formada por 3 partes

1. El desarrollo local (la carpeta de tu ordenador o working directory)
2. El index, que es el registro donde añades aquellos archivos que quieres señalar (normalmente serán todos), lo que se conoce como stage
3. El head, que es donde guardarás todos los cambios de los archivos añadidos en el index, lo que se conoce como commit

Tu desarrollo típico por lo tanto se resume en

1. Trabajar en una branch concreta (que puede ser siempre la master)
2. A medida que avanzas vas haciendo stage y commit según tus criterios
3. Y cada día o cada cierto tiempo sincronizas con tu repositorio remote

El sistema de repositorios más popular del momento es github.com (con alternativas como gitlab.com)

Inicializar un repositorio de GitHub

Lo más rápido para trabajar con github, una vez has abierto tu cuenta allí, es crear un nuevo repositorio directamente allí y luego clonarlo en local

Para esto, una vez creado el repositorio necesitamos copiar la url

Luego, una vez instalado Visual Studio Code (vscode), nos vamos al terminal view -> terminal

Allí, en nuestra carpeta general (puedes moverte en el sistema de ficheros con los comandos cd 'carpeta' o cd ..) ejecutamos

$ cd mi_carpeta_general_de_programacion
$ git clone https://github.com/tu_usuario/tu_repositorio.git

Donde tenemos que poner la url del repositorio

Esto creará una nueva carpeta que contendrá una copia exacta del repositorio que acabamos de crear en github (y que está totalmente vacío)

Lo interesante de haber hecho un git clone es que ya tenemos vinculado el local (nuestro ordenador) y el remote (github.com), esto lo podemos ver con

$ cd tu_repositorio
$ git remote -v
origin  https://github.com/tuUsuario/tuRepositorio.git (fetch)
origin  https://github.com/tuUsuario/tuRepositorio.git (push)

Otra opción para prescindir de git clone sería crear la carpeta nosotros mismos para luego inicializar git y luego vincular el local y el remote con

$ mkdir mi_carpeta
$ cd mi_carpeta
$ git init
$ git remote add https://github.com/tu_usuario/tu_repositorio.git

Donde la última órden, si no le especificamos ningún nombre es lo mismo que hacer

$ git remote add origin https://github.com/tu_usuario/tu_repositorio.git

Al igual que master para nuestra branch por defecto, origin es el nombre por defecto de nuestro remote

Stage y Commit

Una vez hayamos terminado el desarrollo de lo que decidamos, nuestro workflow consistirá en

1. stage via git add * o git add tu_archivo.js
2. commit via git commit -m "he añadido estos cambios"
3. push via git push origin master

El primer paso es para añadir a index aquellos archivos que querremos hacer un commit después

Si no queremos fraccionar nuestros avances en distintos commit lo que haremos será añadir todos los archivos con un git add *

Después hacemos el commit que es la copia real de los archivos en git (lo que nos permitirá tener un histórico)

El commit nos obliga a poner un mensaje que describirá la justificación de este commit

Y el tercer paso es la sincronización con nuestro repositorio remote

Sincronizando cambios

Push

Una vez terminado el commit tendremos git haciendo su trabajo en local, pero lo que queremos es propagar estos cambios a remote por razones de seguridad y para poder trabajar con otros ordenadores u otras personas sin problemas

Esto lo hacemos con

$ git push origin master

O, puesto que tanto origin como master son los nombres por defecto de nuestro remote y branch, podemos simplemente hacer

$ git push

Qué utilidad tiene el tener que especificar tanto el branch como el remote?

Poder publicar en distintas ramas distintas, lo que puede por ejemplo ejecutar una compilación automática si vinculamos una rama concreta a servicios como Netlify

Pull

Pero y cuando hemos desarrollado en otros ordenadores y queremos sincronizar en la dirección opuesta, esto es, que nuestro local esté al dia de nuestro remote?

Lo hacemos con

$ git pull

Esto por defecto equivale a escribir

$ git pull origin master

Esto cojerá nuestro remote origin, de allí cogerá nuestra branch master, y lo copiará y fusionará con nuestro local

Algunas veces un git pull no funciona y nos pide que especifiquemos el remote y el branch

Con el git clone esto no debe suceder, pero si creamos un nuevo branch en local antes que en remote, entonces git no sabrá qué vinculación hay entre local y remote

Esto lo solucionamos especificando el vínculo entre remote y branch bien cada vez con git pull origin master o bien

$ git branch --set-upstream-to=origin/master master
$ git pull

Añadir un directorio vacío con .gitignore

Para añadir un directorio vacío, tan sencillo como crearlo

Pero si esto lo sincronizamos al remote, veremos que el directorio no existe, no se ha sincronizado

Para forzar esa sincronización sin tener que añadir ningún archivo dentro, podemos añadir un archivo .gitignore

En este archivo se añade todo aquello que queremos que git nos ignore, y en este caso lo utilizamos como archivo que nos permitirá sincronizar la carpeta

Dentro nos limitamos a poner

*
!.gitignore

Con esto le decimos a git que lo ignore todo (con el símbolo *) excepto el propio archivo .gitignore (con la segunda línea del código), con lo que al haber un archivo (el .gitignore) en el directorio (y por lo tanto no estar vacío) éste se sincronizará a remote (más información, en la pregunta de stack overflow)

La solución no es ideal, porque ahora cualquier cosa que añadas al directorio se ignorará (bastará con borrar el .gitignore)

La alternativa fácil es añadir cualquier README.txt para forzar lo mismo