Git Basics y Git Flow
Cada equipo de trabajo tiene un flujo diferente. En cuanto más crece, es más difícil mantener el control, evitar conflictos, establecer prioridades y fechas de lanzamiento.
Utilizar Git es el primer paso para resolver estos problemas, ya que se puede adaptar a prácticamente todo tipo de flujo de trabajo. A continuación, les mostrare algunos de los tipos de flujo de trabajo más populares de Git.
Primero… ¿Qué es Git?
En pocas palabras, es un software de control de versiones diseñado por Linus Torvalds.
Pero, ¿qué es control de versiones?
Se define como la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo; es decir, es lo que se hace al momento de subir o actualizar el código de un software o una página web en la nube.
Y entonces, ¿a qué le llamamos sistema de control de versiones? Muy sencillo, son las herramientas que nos permiten hacer todas esas modificaciones en nuestro código y que sea más fácil la administración de las distintas versiones de cada producto desarrollado.
Algunas de las características más importantes de Git son:
- Rapidez en la gestión de ramas. Git nos dice que un cambio será fusionado mucho más frecuentemente de lo que se escribe originalmente.
- Gestión distribuida. Los cambios se importan como ramas adicionales y pueden ser fusionados de la misma manera como se hace en la rama local.
- Gestión eficiente de proyectos grandes.
- Realmacenamiento periódico en paquetes.
Ahora que sabemos que es Git y para qué funciona, veamos algunos comandos básicos al momento de trabajar con esta herramienta. Para esto, abriremos nuestra terminal.
git clone
Para crear una copia local de un repositorio ejecutaremos el siguiente comando.
git clone /path
Una vez clonado en nuestra carpeta, instalaremos todas nuestras dependencias con el comando npm i.
git remote
Este comando nos mostrará los nombres de cada uno de los remotos que tenemos especificados. Si ya clonamos nuestro repositorio, deberiamos ver al menos origin. Este es el nombre que por defecto Git le da al servidor del que hemos clonado.
git fetch
Este comando baja los cambios de una rama determinada y la coloca en una rama espejo. Esta es una clase de rama escondida, en la cual puedes mirar los cambios para posteriormente hacer merge con tu rama local.
git add
Podemos añadir los cambios que vayamos realizando para enviarlos al repositorio central. Para esto, utilizaremos el comando git add, en el cual puedes especificar el archivo a subir (git add <filename>)o subir todos los archivos en los cuales hicimos cambios (git add .).
git commit
El comando commit sirve para agregar nuestros cambios a nuestro árbol HEAD, para poder enviarlos a nuestro repositorio remoto.
git push
Ahora que los cambios estan en nuestro HEAD local, ejecutaremos el comando git push para enviarlos a nuestro repositorio remoto.
git branch
Este comando nos dará el listado de ramas que tengamos en un proyecto. Pero hay que advertir que las ramas de un repositorio local pueden ser distintas de las ramas de un repositorio remoto.
Por ejemplo, cuando clonas un repositorio de GitHub, generalmente estás clonando únicamente la rama master, no todas las ramas que se hayan creado a lo largo del tiempo.
Otro ejemplo es cuando creas una rama en tu repositorio local. En este caso, la rama la tendrás solo en tu proyecto local y no se subirá al repositorio remoto hasta que lo especifiques.
git checkout
El comando git checkout te permite desplazarte entre las ramas creadas por git branch. Al ejecutar la operación de cambio de rama, se actualizan los archivos en el directorio de trabajo para reflejar la versión almacenada y se indica a Git que registre todas las confirmaciones nuevas en esa rama.
Puedes pensar en ello como una forma de seleccionar en qué línea de desarrollo trabajas.
git pull
Para actualizar tu repositorio local al commit más nuevo, ejecutata git pull en tu directorio de trabajo, así bajas y fusionas los cambios remotos.
Si quieres fusionar otra rama a tu rama activa (por ejemplo master), utiliza git merge <branch>.
En ambos casos git intentará fusionar automáticamente los cambios. Desafortunadamente, no siempre será posible y puede producir conflictos. Eres responsable de fusionar esos conflictos manualmente al editar los archivos mostrados por git.
git diff
La comparación es una función mediante la cual se toman dos conjuntos de datos de entrada y se muestran los cambios entre estos.
git diff es un comando multiusos de Git que, cuando se ejecuta, lleva a cabo una función para establecer las diferencias en las fuentes de datos de Git.
Dichas fuentes pueden ser confirmaciones, ramas y archivos, entre otras posibilidades. El comando git diff suele utilizarse junto con git status y git log para analizar el estado actual de un repositorio de Git.
git log
Después de haber hecho varios commits, probablemente quieras mirar atrás para ver qué modificaciones se han llevado a cabo. La herramienta más básica y potente para hacer esto es el comando git log.
Por defecto, si no pasas ningún parámetro, git log lista los commits hechos sobre nuestro repositorio en orden cronológico inverso. Es decir, los commits más recientes se muestran al principio.
Como puedes ver, este comando lista cada confirmación con su suma de comprobación SHA-1, el nombre y dirección de correo del autor, la fecha y el mensaje de confirmación.
git reset
El comando git reset es una herramienta compleja y versátil para deshacer cambios. Tiene tres formas de invocación principales. Estas formas se corresponden con argumentos de líneas de comandos: soft, mixed, hard.
Cada uno de los tres argumentos se corresponde con los tres mecanismos de gestión de estados internos de Git: el árbol de commits ( HEAD ), el índice del entorno de ensayo y el directorio de trabajo.
Después de revisar algunos de los comandos, lo siguiente es diseñar o elegir el flujo de trabajo que se adapte mejor a tu equipo.
Algunos de los flujos mas populares son los siguientes:
Git workflow: Basic
Este es el flujo de trabajo más popular entre los desarrolladores que usan Git. Es muy simple: existe un repositorio central y cada desarrollador lo clona, trabaja localmente en él, agrega sus cambios y los envía al repositorio central para que los otros involucrados puedan utilizar su trabajo.
Git workflow: Feature branch
El flujo de trabajo básico es muy útil, pero… ¿qué pasa si hay más desarrolladores involucrados en el proyecto y quieren realizar dos funcionabilidades dentro del mismo? Aquí es cuando comienzan a surgir los problemas.
Supongamos que un desarrollador terminó una funcionabilidad y quiere enviar esos cambios; como otra función no esta lista, subir un cambio podría resultar fatal.
Para esto funciona el flujo de trabajo por ramas. Estas ramas son áreas de trabajo independientes dentro del proyecto. Para cada nueva funcionalidad, se crea una nueva rama, donde se desarrolla y prueba la nueva característica.
Una vez que la función está lista, la rama se puede fusionar con la rama maestra.
Git workflow: Gitflow
Cuando un proyecto es demasiado grande, es necesario controlar qué se acepta y qué va directo a produccion.
Para esto, se requiere unit testing e integration, que se puede resolver con Gitflow. Este flujo de trabajo utiliza ramas paralelas para llevar a cabo un mejor control: master y develop.
La rama master siempre está lista para ir a producción, en este punto todo debe estar probado y aprobado.
En develop se fusionan todas las ramas donde se realizan nuevas funcionabilidades y aquí mismo se realizan todas las pruebas. Solo cuando estén revisadas a fondo, esta rama se puede fusionar con la principal (master).
Ahora que sabemos todo esto, podemos llegar a la conclusion de que la mayor característica de Git es que se adapta a tus necesidades y crea su propio flujo de trabajo.
