Describiendo el flujo de trabajo en Git

Emmanuel Orozco
Laboratoria Developers
4 min readMar 17, 2017

Si estas leyendo esto asumiré que ya sabes cómo funciona Git y cuál es la diferencia con Github. Si aún no lo sabes te recomiendo que leas este artículo.

Ya sabemos los 3 comandos básicos para agregar nuestro proyecto a Github, los cuales son:

git add .
git commit -m "Nombre de la nueva version"
git push -u origin master

Sin embargo, ¿qué significa “add” y “commit”? ¿Por qué nuestro código tiene que pasar por esas 2 fases en lugar de sólo una?

Para explicar eso analicemos la siguiente imagen.

Como podemos ver, nuestro repositorio local (el folder que clonamos a nuestra computadora) tiene 3 diferentes fases por la cual pasa nuestro código:

  1. Working Directory
  2. Staging Area
  3. Git Repository

Al igual que las 3 fases, el código tiene 3 estatus en cada diferente fase:

  1. Modificado
  2. Preparado
  3. Confirmado

Fase 1: “Working Directory”.

Aquí es donde podemos hacer cualquier cambio y no afectar nuestro repositorio en lo absoluto.

En cuanto modificamos algo de nuestro código, éste tiene status de modificado.

Si ejecutamos el comando git status, nos mostrará qué archivos han sido modificados (o creados).

“Untracked file” es para archivos recién creados y “modified” para los modificados

Una vez que hemos hecho los cambios necesarios, pasamos nuestros archivos al “staging area” con el comando:

git add nombreDelArchivoModificado.js

Nota que no es necesario escribir:

git add nombreDelArchivoModificado.js

si escribimos:

git add .

Agregamos todos los archivos modificados dentro de working directory a staging area.

Cuando pasas el código de Working Directory a Stagin Area, cambias el estado del código de modificado a preparado.

Fase 2: “Staging Area”

Aquí es donde le podemos dar nombre a nuestra nueva versión. Y crear una “copia” de cómo quedaría nuestra nuestro repositorio en producción.

Para pasar nuestro código de staging area al Git Repository (aun no se publica el código en Github), escribimos el siguiente comando:

git commit -m "Nombre del la nueva versión"

Nota que cuando haces el commit el código pasa de estado preparado a confirmado.

Fase 3. “Git repository”

Una vez que el código esta confirmado ya esta listo para sincronizarse con el servidor de Git (github, bitbucket,etc). Para hacer esto, escribimos:

git push -u origin master

Como truquito adicional, te cuento que -u sirve para recordarorigin” que es la dirección de tu repositorio de git y “master” que es la branch del repositorio que se esta usando.

Como estamos “recordando” origin y master, para el próximo pusheo, únicamente podríamos hacer:

git push

Y git ya sabe que significa:

git push origin master

Si estas trabajando en un repositorio con varias personas en algún momento vas a querer descargar las cosas que tus compañeros agreguen o modifiquen.

Para eso ejecutamos:

git pull origin master

Y git automáticamente agrega los cambios, (y se pasa por el proceso checkout the proyect, mostrado en el diagrama de arriba).

Este nuevo diagrama, te puede ayudar entender un poco mejor el flujo que acabamos de explicar.

Y ¿cuáles son las ventajas de tener add y commit? ¿No podría solo existir una fase para sincronizar mi código con github?

Buena pregunta, en teoría sí, se podría tener solo una fase. Sin embargo existe una ventaja fundamental en tener los 2 procesos separados.

Esta ventaja es poder nombrar CUALQUIER cambio de una forma especifica.

Por ejemplo:

Si creamos 2 archivos, un archivo index.hmtl y otro archivo funciones.js, para agregarlos a Git, podríamos escribir:

git add .
git commit -m "Agregado index y Javascript"

Pero también podemos hacer esto:

git add index.html
git commit -m "Agregado HTML"
git add funciones.js
git commit -m "Agregado JS"

Y pushear con un simple:

git push origin master

Y en github al momento de pushear nuestros commits se verian separados y por tanto, es mucho mas legible nuestro control de versiones:

Ahora que hemos visto cuales son las fases y estatus de nuestro código de Git, podemos con mas confianza ejecutar comandos y perder el miedo a romper cosas.

--

--

Emmanuel Orozco
Laboratoria Developers

Ingeniero de software. Me encanta lo que hago. Odio el vodka. Voy a cambiar el mundo.