Te explico el funcionamiento básico de git
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
- El desarrollo local (la carpeta de tu ordenador o working directory)
- 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
- 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
- Trabajar en una branch concreta (que puede ser siempre la master)
- A medida que avanzas vas haciendo stage y commit según tus criterios
- 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
- stage via
git add *
ogit add tu_archivo.js
- commit via
git commit -m "he añadido estos cambios"
- 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 nuevobranch
enlocal
antes que enremote
, entoncesgit
no sabrá qué vinculación hay entrelocal
yremote
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