En esta ocasión Oscar Vítores compartió con nosotros su experiencia en el uso de git-flow. La presentación fue muy interesante ya que no sólo se limitó a exponer qué es y cómo funciona, sino que nos contó cómo la usa con su equipo, qué le sirvió y cuándo git-flow empezó a quedarse corto.

El meetup estuvo muy bien, con muchas preguntas y comentarios durante la exposición. Gracias a todos los que estuvisteis allí y a Oscar por venir a contarnoslo en persona.

Aquí tenéis la grabación que hicimos a través de hangout (y aquí las diapositivas):

Una agradecimiento desde la organización de los meetups al espacio de coworking Kunlabori por cedernos la sala, micro y conexión para reunirnos y hacer la grabación.

Otros enlaces:

• Serie de artículos sobre git-flow en aprendegit.com
• Taller de git-flow en la Drupalcamp de 2013

• En la introducción, vimos por qué surge esta extensión de git, qué hace y qué tipo de flujos de trabajo nos permite implementar.
• Después instalamos git-flow, creamos un repositorio e inicializamos la extensión en el mismo.
• Creamos las ramas develop y master y empezamos a desarrollar las historias de usuario del sprint usando feature branches.
• Cuando terminamos nuestro sprint, utilizamos un release branch para testar y ajustar nuestro código antes de pasarlo a producción.
• Finalmente vimos cómo corregir bugs urgentes en producción mediante el uso de hotfix branches.

 Qué nos aporta git-flow

• Un flujo de trabajo básico para organizar el repositorio y nuestro trabajo.
• Un convenio de nombres para nuestras ramas que permite a todos los miembros del equipo saber qué es cada cosa.
• Unas reglas comunes a la hora de mover la información de una rama a otra.
• Un conjunto de comandos que nos ahorra tiempo.
• ¡Sourcetree tiene soporte en la aplicación! Si has entendido cómo funciona, puedes investigar cómo usarlo en la interfaz gráfica. Tienes el botón en la barra de herramientas.

A lo largo de la serie siempre hemos relacionado los comandos de git-flow con los comandos git que la extensión ejecuta por detrás. Aunque nos facilite el trabajo, el uso de git-flow no nos exime de entender cómo funcionan las ramas, saber utilizar merge y rebase o entender la diferencia entre un pull y un fetch. Es entendiendo estos conceptos como le sacarás rendimiento a esta y a cualquier otra extensión de git.

He utilizado este flujo de trabajo en proyectos en los que he trabajado solo y proyectos con equipos de entre 3 y 5 personas.  Mi experiencia es que esta forma de organizar el repositorio es un buen punto de partida para el desarrollo de procesos más complejos, especialmente si el equipo no tiene mucha experiencia en el uso de git.

Como dijimos en la introducción, estas no son reglas absolutas. Y aunque funcionan en un gran número de equipos, puede que en tu caso necesites adaptarlas a tu forma de trabajar. Confío en que después de haber leído los artículos de esta serie, estés en condiciones de hacerlo.

¿Qué son las hotfix branches de git-flow?

Recordemos cómo había quedado nuestro repositorio tras la puesta en producción:

• La rama master, que actualmente contiene la versión 1.0, ya ha sido desplegada en producción
• La rama develop, que ya incorpora todos los cambios y ajustes que hicimos durante la puesta a punto de la versión 1.0, está lista para avanzar en el desarrollo de la versión 1.1

Recordemos cómo dejamos el repositorio en la entrega anterior:

Estamos listos para empezar un nuevo sprint. Tenemos una reunión de planificación, ponemos en el backlog las historias de usuario que vamos a desarrollar para la versión 1.1, y empezamos a trabajar.

A los pocos días, recibimos un aviso de nuestros compañeros del departamento de atención al cliente: ¡hay un bug de la aplicación en producción! Git-flow utiliza hotfix branches para implementar un flujo de trabajo que permite:

• Interrumpir el trabajo que estamos haciendo en la rama develop para la versión 1.1
• Resolver el bug
• Incorporar la corrección del bug en la rama master para desplegarlo en producción lo más rápido posible
• Incorporar la corrección del bug en la rama develop (si procede)
• Retomar el trabajo que estábamos haciendo en la rama develop

Para los que estáis familiarizados con la administración de sistemas, a mí cada vez que me pasa esto me siento como el kernel de Linux haciendo context switching. Cada vez que tenemos que dejar cambiar de rama tenemos que cambiar de contexto. Eso implica recordar qué estábamos haciendo, qué teníamos en la nueva rama y en qué estado estábamos. Sin una herramienta como git, que permite hacer este cambio de forma rápida y viendo la historia de las dos ramas, el tiempo necesario para hacer el cambio de contexto nos hace menos productivos. Las ramas hotfix nos ayudan a hacer estos cambios de contexto de forma más eficiente y a corregir el problema con el mínimo impacto sobre el resto del trabajo que estamos haciendo.

Creando la rama hotfix/bug-14

Como hemos comentado antes, supongamos que ya llevamos unos cuantos días trabajando en el sprint. Habremos creado una (o varias) feature branches y el estado de nuestro repositorio puede ser algo parecido a esto:

Estado de la rama develop antes del aviso de bug

Nos encontramos trabajando en la historia de usuario H5 cuando recibimos la llamada de nuestros compañeros avisándonos del bug.

Lo primero que haremos será almacenar el trabajo que estamos haciendo y que vamos a tener que interrumpir porque tenemos que cambiar de contexto. El objetivo es guardar este trabajo a medias y recuperarlo cuando hayamos terminado de corregir el bug. Hay varias formas de hacer esto, nosotros lo guardaremos en el stash ya que prevemos que la corrección del bug no nos llevará mucho tiempo:

$ git stash save 'Antes de empezar a corregir el bug #14'
Saved working directory and index state On feature/h5: Antes de empezar a corregir el bug #14
HEAD is now at f6609a9 Primera implementación de las páginas estáticas

Podemos ver el contenido del stash con el comando git stash list

$ git stash list
stash@{0}: On feature/h5: Antes de empezar a corregir el bug #14

El objetivo de esta entrada no es hablar del stash, así que entraremos en detalle en otra ocasión. Si no sabes lo que es, puedes consultar este enlace. Seguimos.

Una vez tenemos nuestro trabajo almacenado y listo para cambiar de contexto, creamos la rama hotfix/bug14:

$ git flow hotfix start bug14
Switched to a new branch 'hotfix/bug14'

Follow-up actions:
- Bump the version number now!
- Start committing your hot fixes
- When done, run:

git flow hotfix finish 'bug14'

Estado del repositorio tras crear la rama hotfix/bug14

Los comandos que git-flow ha ejecutado por nosotros son en este caso bastante sencillos:

$ git checkout master
$ git checkout -b hotfix/bug14

Con la rama creada, empezamos a trabajar en la corrección del bug. Pasadas unas horas y unos cuantos commits después, tenemos el bug corregido y listo para subir a producción. Este es el estado del repositorio:

Estado del repositorio después de haber localizado y corregido el bug.

Cerrando la rama hotfix/bug14

Nos acercamos al final. Una vez corregido el bug, procedemos a cerrar la rama hotfix:

$ git flow hotfix finish bug14

Cuando ejecutamos este comando, git-flow nos pide que introduzcamos tres mensajes:

• El primero de ellos es el mensaje del merge commit resultado de incorporar los cambios de hotfix/bug14 en master

Se abre el editor predeterminado para introducir el mensaje del merge commit

• El segundo es el mensaje que git-flow pondrá a la etiqueta que va a crear para identificar esta versión (vbug14)

Mensaje para la etiqueta de versión

• El tercero y último será el mensaje que git-flow pondrá en el merge commit resultado de incorporar la rama hotfix/bug14 en develop

Se abre el editor predeterminado para introducir el mensaje del merge commit con la rama develop

Al igual que cuando cerramos la rama release/1.0, al finalizar la ejecución del comando se muestra un resumen de todas las acciones que han tenido lugar:

En rojo hemos indicado las acciones que git-flow ha ido ejecutando y que pueden resumirse en los siguientes comandos:

git checkout master
git merge hotfix/bug14 --no-ff
git tag vbug14
git checkout develop
git merge hotfix/bug14 --no-ff
git branch -d hotfix/bug14

El nombre que git-flow ha puesto a la etiqueta no es precisamente el más adecuado, así que borramos esa etiqueta y creamos una nueva que se llama v1.0.1. El repositorio queda de la siguiente manera:

Y ya está, casi hemos terminado… Sólo nos falta volver a cambiar de contexto y recuperar el repositorio como lo teníamos antes de empezar a corregir el bug.

Volviendo a la rama feature/h5

Este paso es el más sencillo, basta ejecutar el comando

$ git checkout feature/h5

Ahora bien: ¿cómo recuperamos ese trabajo a medias que habíamos tenido que interrumpir y que almacenamos en el stash?

$ git stash list
stash@{0}: On feature/h5: Antes de empezar a corregir el bug #14

$ git stash pop stash@{0}
Auto-merging 

(Nota: dado que sólo tenemos una cosa guardada en el stash, podríamos ejecutar sencillamente git stash pop).

Y con esto hemos terminado, ya tenemos todo listo para seguir trabajando en la historia de usuario H5.

Conclusión

En esta entrega hemos visto cómo git-flow nos ayuda a gestionar la corrección de bugs del sistema en producción a través de hotfix branches. Creando una rama específica para corregir el bug, conseguimos que mientras una parte del equipo está trabajando en la rama develop, otra parte pueda corregir el bug. Si es una misma persona la que tiene que hacer este trabajo, la creación de estas ramas auxiliares facilita el cambio de contexto al desarrollador.

Este tipo de ramas no tienen mucho sentido en las ramas develop ya que la detección y corrección de bugs forma parte del proceso de desarrollo de nueva funcionalidad

En la siguiente entrega haremos un pequeño resumen de lo que hemos visto en esta serie de artículos y daremos por terminada la serie.

¿Para qué necesitamos una release branch?

El objetivo de estas ramas es preparar nuestra aplicación para su puesta en producción. En algunos equipos, estas ramas son las que se vuelcan en los servidores de pre-producción para hacer el testing final: se corrigen bugs, se pule la interfaz, se ajusta la maquetación…se hace la puesta a punto final de la aplicación antes de liberar la versión definitiva. Vamos a crear una release branch para la versión 1.0. Utilizando la línea de comandos, ejecutamos

$ git flow release start 1.0

Switched to a new branch 'release/1.0'
Summary of actions:
- A new branch 'release/1.0' was created, based on 'develop'
- You are now on branch 'release/1.0'

Follow-up actions:

- Bump the version number now!
- Start committing last-minute fixes in preparing your release

- When done, run:

git flow release finish '1.0'

Tras ejecutar estos comandos el repositorio queda de la siguiente manera:

Una vez creada la rama, empezamos el proceso de corrección y depuración, que en el ejemplo que nos ocupa da como resultado varios commits a la rama release/1.0. Así queda el repositorio cuando hemos terminado de arreglar todos los bugs y estamos listos para que nuestro proyecto pase a producción:

Cerrando la rama release con git-flow

En este punto, nuestro código fuente está testado, todos los bugs corregidos (o eso pensamos) y todo está listo para entregar la versión 1.0. Para cerrar la rama, ejecutamos

$ git flow release finish 1.0

Cuando ejecutamos este comando git-flow nos va a pedir que introduzcamos tres mensajes:

• El primero de ellos es el mensaje del merge commit resultado de incorporar los cambios de release/1.0 en master

• El segundo mensaje es el mensaje que git-flow pondrá a la etiqueta que va a crear para identificar esta versión

• El tercero y último será el mensaje que git-flow pondrá en el merge commit resultado de incorporar la rama release/1.0 en develop

Cuando el comando termina, se nos muestra un resumen de todas las acciones que han tenido lugar:

En rojo hemos indicado las acciones que git-flow ha ido ejecutando y que pueden resumirse en los siguientes comandos:

git checkout master
git merge release/1.0 --no-ff
git tag v1.0
git checkout develop
git merge release/1.0 --no-ff
git branch -d release/1.0

El repositorio queda de la siguiente manera:

Despliegue en producción

Dado que en este ejemplo estamos trabajando con una web HTML, el despliegue en producción es muy sencillo:

• Sincronizamos las rama master con git push
  

git checkout master
git push

• En el servidor en producción ejecutamos

git checkout master
git pull

Variaciones de este flujo

Cuando estamos trabajando en la rama release, puede darse el caso de que algunos bugs sean más complicados de resolver de lo esperado. Si eso ocurre, siempre podemos crear una rama dentro de release para corregir ese bug y, una vez terminado, incorporar los cambios a la rama release.

Conclusión

En esta entrega hemos visto cómo git-flow nos ayuda a gestionar la liberación de nuevas versiones de nuestro código fuente. Creando una rama específica para la puesta a punto de la versión, conseguimos que mientras una parte del equipo está trabajando release/1.0, otra parte puede avanzar en nuevas funcionalidades usando feature branches en la rama develop.

Lo que se debe evitar es utilizar la rama release para desarrollar nuevas funcionalidades. Si esto ocurre quiere decir que hemos pasado el código a pre-producción demasiado pronto.

En la siguiente entrega veremos cómo prepara hotfixes para nuestro código en producción.

Trabajaremos con una sencilla página HTML como ejemplo. No queremos complicar la explicación ni distraernos con el código fuente; el objetivo es entender el flujo que vamos a implementar con git.

Git-flow y metodologías ágiles

Los próximos artículos vamos a escribirlos en el contexto de las metodologías ágiles. Hablaremos de iteraciones, reuniones de planificación, reuniones diarias del equipo… El objetivo es poner git-flow en contexto y ver cómo nos puede ayudar.

Supongamos que ya hemos pasado por la reunión de planificación y hemos acordado en el equipo qué historias de usuario vamos a implementar en la primera iteración.

Las historias de usuario del primer sprint son las siguientes:

• H-1: La web dispondrá de una home con un menú de acceso al resto de páginas
• H-2: La página de inicio dispondrá de un hero con un texto y un botón de enlace al último artículo

Implementaremos la primera de las historias de forma manual y la segunda con git-flow. De esta forma entenderemos bien qué es lo que estas extensiones hacen por debajo.

Antes de empezar: git-flow-init

Dado que se trata de un proyecto nuevo, lo primero que haremos antes de empezar el desarrollo es, como no, crear el repositorio y prepararlo para usar git-flow. Para ello seguimos los siguientes pasos:

$ mkdir nuestro-proyecto
$ cd nuestro-proyecto
$ git init
$ git-flow init

No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? [] v

Al ejecutar el último comando, entramos en un menú interactivo que nos va preguntando las opciones que aparecen arriba:

• Al inicializar git-flow, nos pregunta el nombre de la rama de producción y de la rama de desarrollo (master y develop respectivamente). Seleccionamos los nombres por defecto.
• Después nos preguntará los prefijos que asignará a las ramas de tipo feature, release, hotfix y support. Volvemos a seleccionar los nombres por defecto.
• Por último, nos pregunta el prefijo que queramos utilizar para etiquetar las versiones.

Si no os gustan los prefijos que usa git-flow por defecto, podéis utilizar otros. En un artículo posterior veremos como cambiar a posteriori estos nombres.

¿Y en qué estado queda nuestro repositorio después de hacer esto? Aquí tenéis una captura de SourceTree:

Estado del repositorio tras ejecutar git-flow

Vemos el commit inicial así como las ramas master y develop. Desde la línea de comandos, el repositorio tiene este aspecto:

$git branch -av
* develop 87ee184 Initial commit
  master  87ee184 Initial commit

Desarrollando H-1: gestionando las ramas manualmente

En el proyecto, en una de las reuniones diarias, se decide que vamos a usar bootstrap para maquetar la web, así que en la primera historia descargaremos bootstrap, lo incluiremos en la carpeta vendor y crearemos la página de inicio (nota para los usuarios más avanzados: somos conscientes de que hay mejores maneras de añadir bootstrap al proyecto como por ejemplo usar submódulos. Usamos este enfoque más simple porque no queremos distraernos con detalles ajenos al objetivo de esta serie que es entender git-flow).

Dado que se trata de un desarrollo planificado que formará parte de un futuro release (la versión 0.1) usaremos una feature branch.

Recordamos: las feature branches nacen de la rama develop y se incorporan a esa misma rama. Así que creamos una nueva rama a partir de develop que llamamos feature-H-1:

$ git checkout -b feature-H-1 develop
$ git branch -av
  develop     87ee184 Initial commit
* feature-H-1 87ee184 Initial commit
  master      87ee184 Initial commit

Una vez creada la rama feature-H-1, hacemos la siguiente serie de commits:

• Añadimos bootstrap al proyecto
• Creamos la página de inicio
• Ponemos el menú

Cuando terminamos el desarrollo de la historia H-1, este es el estado de nuestro repositorio:

Así queda el repositorio cuando terminamos de hacer el desarrollo de la historia H-1 en la rama feature-H-1

Ya hemos terminado nuestra primera historia, así que ha llegado el momento de incorporar los cambios a la rama develop (recuerda, las feature branches se incorporan a la rama develop):

$ git checkout develop
$ git merge --no-ff feature-H-1

Si no sabes qué es la opción –no-ff y porqué la usamos, lee este artículo. Al ejecutar el comando se nos pide el mensaje para el merge commit:

Merge branch 'feature-H-1' into develop

# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.

Cuando guardamos y cerramos, este es el estado del repositorio:

Estado del repositorio después de incorporar la rama feature-H-1

Como la rama feature-H-1 ha quedado visibles en el repositorio con un merge commit, podemos borrarla:

$ git branch -d feature-H-1
Deleted branch feature-H-1 (was 765ce08).

Pues bien, ya hemos terminado nuestra primera historia, vamos a por la segunda.

Desarrollando H-2: gestionando las ramas con git-flow

Para hacer esta historia, necesitaremos crear una nueva feature branch que llamaremos feature-H-2. Esta vez usaremos git-flow:

$ git-flow feature start H-2
Switched to a new branch 'feature/H-2'

Summary of actions:
- A new branch 'feature/H-2' was created, based on 'develop'
- You are now on branch 'feature/H-2'

Now, start committing on your feature. When done, use:

     git flow feature finish H-2

Notar que no necesitamos poner el prefijo “feature” para crear la rama, git-flow lo hace por nosotros. El propio git-flow se encarga de activar la rama feature/H-2 y de decirnos qué tenemos que hacer cuando terminemos. El estado del repositorio después de ejecutar el comando es el siguiente:

Estado del repositorio después de crear la rama feature/H-2 con gitflow

Con la rama creada, nos ponermos a trabajar. Implementamos el hero de la página de inicio y hacemos los commits correspondientes:

Estado de la rama feature/H-2 una vez terminado el desarrollo

Así vemos las ramas desde la línea de comandos:

$ git branch -av
  develop     b7bd517 Merge branch 'feature-H-1' into develop
* feature/H-2 4604003 Introduciendo el texto definitivo
  master      87ee184 Initial commit

Si en un momento dado queréis listar las ramas de tipo feature desde la línea de comandos, basta con ejecutar git flow feature:

$ git flow feature
* H-2

Esto mismo es aplicable para las ramas hotfix, release y support.

Continuamos con el desarrollo. Revisamos y testamos nuestro código y cuando vemos que hemos terminado, utilizamos git-flow para cerrar la rama:

$ git flow feature finish H-2
Switched to branch 'develop'
Merge made by the 'recursive' strategy.
  | 7 +++++++
 1 file changed, 7 insertions(+)
Deleted branch feature/H-2 (was 4604003).

Summary of actions:
- The feature branch 'feature/H-2' was merged into 'develop'
- Feature branch 'feature/H-2' has been removed
- You are now on branch 'develop'

Es decir, hemos vuelto a la rama develop, se ha incorporado la rama feature/H-2 a develop y la feature branch se ha borrado. Después de ejecutar el comando, este es el resultado:

Estado del repositorio tras cerrar la feature branch

Si os fijáis, hemos hecho lo mismo ejecutando menos comandos.

En esta captura vemos cómo en este flujo de trabajo queda reflejado en la historia del repositorio de forma bastante limpia y clara, cuándo se empezó y finalizó el desarrollo de cada una de las feature branches.

Ahora toca prepararlo todo para hacer el release a producción, aunque eso lo haremos en la siguiente entrega.

Hemos subido este repositorio a nuestra cuenta de github. Podéis verlo en este enlace: https://github.com/aprendegit/articulo-sobre-gitflow

Instalación de git-flow

Mac

Si habéis instalado git a través de homebrew o macports, la instalación se muy sencilla:

$ brew install git-flow
$ port install git-flow

Si tienes problemas con XCode 4.2 y Macports 2.0.4, sigue las instrucciones que se dan en la página de git-flow. También es posible utilizar la instalación a través de wget usando el script de instalación de Rick Osborne:

wget --no-check-certificate -q -O - https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | sudo bash

Linux

git-flow tiene paquetes para distribuciones basadas en debian y Ubuntu. Utiliza el gestor de paquetes de tu distribución, busca el paquete e instálalo. En debian/Ubuntu, el paquete se llama git-flow, en fedora gitflow y en Archlinux gitflow-git.

Si tu distribución no tiene paquete disponible en los repositorios oficiales como ocurre con centos 5, la mejor manera de instalarlo es utilizar el script de instalación:

wget --no-check-certificate -q -O - https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | sudo bash

Windows

Las instalación es un poco más tediosa, aunque no es complicada. Seguiremos las instrucciones que se dan en la página de git-flow aunque con un poco más de detalle:

• En la página del paquete util-linux-ng para windows, nos bajamos los binarios y las dependencias

• Descomprimimos los dos ficheros descargados: util-linux-ng-[version]-bin.zip y util-linux-ng-[version]-dep.bin
• Dentro de la carpeta “util-linux-ng-[version]-bin”, copiamos el fichero bin/getopt.exe a la carpeta C:\Program Files\Git\bin
• Dentro de la carpeta “util-linux-ng-[version]-dep”, copiamos  el fichero bin/libintl3.dll a la carpeta C:\Program Files\Git\bin
• Nota: en mi caso, tuve que hacer esto desde la línea de comandos lanzando un terminal de git bash como administrador de la máquina

• Una vez copiados los ficheros, se clona el repositorio git://github.com/nvie/gitflow.git. Puedes clonarlo utilizando la línea de comandos o tu cliente gráfico favorito.
• Por último, abrimos una terminal de windows dentro del repositorio que acabamos de clonar y ejecutamos el comando contrib/msysgit-install.cmd “C:\Program Files\Git” (sustituyendo la ruta si en tu máquina la tienes en una carpeta diferente). Nota: este terminar también tuve que lanzarla como usuario administrador, mi usuario de trabajo no tiene permiso en la carpeta C:\Program Files\Git.

Listo, para confirmar que lo tenemos instalado, abrimos git bash, creamos una carpeta vacía y dentro inicializamos el repositorio con el siguiente comando:

$ git flow init

Si todo ha ido bien, esto es lo que deberíamos observar:

Si quieres seguir esta serie, debes disponer de una máquina con git instalado:

• Windows: msysgit que puedes descargar de este enlace
• Mac: a través de homebrew o macports
• Linux: a través del gestor de paquetes de tu distribución

Flujos de trabajo

Hace unos días participé en el Open Space de Calidad del Software organizado en Madrid este mes de febrero. En la reunión se abordaron varios temas que iban desde responder a preguntas como ¿qué se calidad del software? ¿cuánto cuestan los tests funcionales? o ¿cómo hacer testing de desarrollos para dispositivos móviles? pasando por otros tan exóticos como el Pirata Roberts, llegando incluso a plantearse hasta la eliminación de los responsables de calidad de la faz de la tierra.

En casi todas las conversaciones en las que tuve la oportunidad de participar había un denominador común: las ramas. Se hablaba de ramas para hacer hot-fixes urgentes, ramas para desarrollar nuevas versiones separadas de las ramas maestras donde está la versión en producción. Ramas para probar nuevas versiones, ramas y repositorios para trabajar con proveedores externos, ramas para hacer pruebas en pre-producción, ramas para que los departamentos de calidad hagan sus pruebas antes de liberar nuevas versiones. Con git podemos crear ramas “como churros” y ese fin de semana tuve la oportunidad de compartir con varios colegas de profesión cómo utilizar las ramas para hacer el bien. Sin embargo, esta facilidad para crear ramas también se puede utilizar para hacer el mal y sembrar el terror. Más de una vez he visto ramas creadas sin ningún criterio, sin ningún flujo de información detrás que las sustente. Esta situación suele llevar al repositorio al caos más absoluto.

Para no acabar en el caos, debemos establecer unas “reglas del juego” que todo el equipo debe respetar. Aunque a grandes rasgos casi todos los proyectos pueden utilizar unas reglas de base comunes, las reglas deben ser flexibles para adaptarse a los cambios que puedan surgir en el tablero de juego; al fin y al cabo, las necesidades y particularidades de cada equipo, empresa o proyecto no son las mismas.

¿Y cuáles son estas reglas base comunes? En enero de 2010 Vincent Driessen publicó en su blog un artículo en el que compartía con la comunidad un flujo de trabajo que a él le estaba funcionando: “A successful Git branching model”. Como él mismo cuenta en el artículo (te recomiendo encarecidamente que lo leas) Vincent propone una serie de “reglas” para organizar el trabajo del equipo.

Ramas master y develop

El trabajo se organiza en dos ramas principales:

• Rama master: cualquier commit que pongamos en esta rama debe estar preparado para subir a producción
• Rama develop: rama en la que está el código que conformará la siguiente versión planificada del proyecto

Cada vez que se incorpora código a master, tenemos una nueva versión.

Además de estas dos ramas, Se proponen las siguientes ramas auxiliares:

• Feature
• Release
• Hotfix

Cada tipo de rama, tiene sus propias reglas, que resumimos a continuación.

Feature or topic branches

fuente: nvie http://nvie.com/posts/a-successful-git-branching-model/

• Se originan a partir de la rama develop.
• Se incorporan siempre a la rama develop.
• Nombre: cualquiera que no sea master, develop, hotfix-* o release-*

Estas ramas se utilizan para desarrollar nuevas características de la aplicación que, una vez terminadas, se incorporan a la rama develop.

Release branches

• Se originan a partir de la rama develop
• Se incorporan a master y develop
• Nombre: release-*

Estas ramas se utilizan para preparar el siguiente código en producción. En estas ramas se hacen los últimos ajustes y se corrigen los últimos bugs antes de pasar el código a producción incorporándolo a la rama master.

Hotfix branches

• Se origina a partir de la rama master

  fuente http://nvie.com/posts/a-successful-git-branching-model/

• Se incorporan a la master y develop
• Nombre: hotfix-*

Esas ramas se utilizan para corregir errores y bugs en el código en producción. Funcionan de forma parecida a las Releases Branches, siendo la principal diferencia que los hotfixes no se planifican.

¿Qué es git-flow?

Si queremos implementar este flujo de trabajo, cada vez que queramos hacer algo en el código, tendremos que crear la rama que corresponda, trabajar en el código, incorporar el código donde corresponda y cerrar la rama. A lo largo de nuestra jornada de trabajo necesitaremos ejecutar varias veces al día los comandos git, merge, push y pull así como hacer checkouts de diferentes ramas, borrarlas, etc. Git-flow son un conjunto de extensiones que nos ahorran bastante trabajo a la hora de ejecutar todos estos comandos, simplificando la gestión de las ramas de nuestro repositorio.

La flexibilidad de git…y el sentido común

Las «reglas» que Vincent plantea en su blog son un ejemplo de cómo git nos permite implementar un flujo de trabajo para nuestro equipo. Estas no son reglas absolutas, bien es cierto que pueden funcionar en un gran número de proyectos, aunque no siempre será así. Por ejemplo ¿qué pasa si tenemos que mantener dos o tres versiones diferentes de una misma aplicación? digamos que tenemos que mantener la versión 1.X, la 2.X y la 3.X. El tablero de juego es diferente así que necesitaremos ampliar y adaptar estas reglas para poder seguir jugando.

git es una herramienta que nos permite modificar estas reglas y, lo que es más importante, irlas cambiando y adaptando a medida que el proyecto avanza y el equipo madura. Una vez más, una buena dosis de sentido común será nuestra mejor aliada para responder las preguntas que nos surjan durante el camino.

Referencias:

• A successful branching model
• git-flow en github

Forzar merge commits

Lo más claro, como siempre, es verlo con un ejemplo. Imaginad que llegáis por la mañana al trabajo y empezáis como siempre a picar código como locos en la rama devel. De repente surge la necesidad de atender un bug. Siguiendo las buenas prácticas, lo que haremos será crear una rama HotFix, arreglar el problema haciendo cuantos commits necesitemos a esa rama y finalmente hacer un merge a la rama que corresponda cuando terminemos de corregir el bug.

En la siguiente captura se muestra el estado del repositorio justo después de haber hecho el último commit a la rama hotfix_14523 que arregla el problema en cuestión:

Si en este momento se hace un merge de la rama hotfix_15423 a la rama devel, se hará un fast-forward:

$ git checkout devel
$ git merge hotfix_15423
Updating 2d1d1c4..2b9d126
Fast-forward
Gemfile | 2 ++
app/views/home/.erb | 1 +
2 files changed, 3 insertions(+)

Así queda el grafo después de hacer el merge:

Como vemos, mirando la historia del repositorio, no queda constancia de cuándo se empezó el desarrollo de la rama hotfix_15423 y cuándo se incorporó a la rama devel. Una solución podría ser etiquetar los commits correspondientes, como se muestra en la siguiente captura:

Esta solución es válida cuando tenemos pocas ramas. Si tenemos muchas ramas de las que queramos saber su inicio y final, podemos acabar con un número de etiquetas difícil de gestionar.

Forzar un merge commit

Volvamos a la situación inicial:

$ git reset --hard 2d1d1c4
HEAD is now at 2d1d1c4 Update README.rdoc

En esta situación, volvemos a ejecutar el merge de la siguiente forma:

$ git merge --no-ff hotfix_15423 -m'Incorporando rama hotfix_15423'
Merge made by the 'recursive' strategy.
 Gemfile | 2 ++
 app/views/home/.erb | 1 +
 2 files changed, 3 insertions(+)

Después de ejecutar el comando, este es el estado del repositorio:

Haciéndolo de esta forma, en lugar de hacerse un fast-forward, vemos que se crea un merge-commit, lo que resulta en una bifurcación que indica claramente el fin y el inicio de la rama hotfix_15423.

Si sois de los que os gusta ver claramente dónde empiezan y terminan vuestras ramas, este pequeño truco es resultará de utilidad.

Recordamos brevemente qué es lo que nuestros usuarios aalbagarcia y aprendegit-user1 hicieron en las dos entradas anteriores:

• El usuario aalbagarcia crea un repositorio en github: https://github.com/aprendegit/fork
• El usuario aprendegit-user1 crea un fork (bifurcación) para trabajar en él: https://github.com/aprendegit-user1/fork
• Los dos usuarios realizan modificaciones cada uno en su repositorio, cada uno de ellos hace un commit y posteriormente un push. Cada uno sube los cambios a su correspondiente repositorio
• El usuario aprendegit-user1 configura un repositorio remoto adicional (upstream) e incorpora, haciendo un merge, los cambios en el código que hizo aalbagarcia. Después de hacer el merge, aprendegit-user1 hace un push para actualizar su repositorio remoto.

Lo último que nos falta por hacer es que el usuario aalbagarcia, que es el propietario del repositorio inicial (https://github.com/aprendegit/fork), incorpore el trabajo del usuario aprendegit-user1 que se encuentra en el fork https://github.com/aprendegit-user1/fork.

¿Qué es un pull request?

Un pull request es una petición que el propietario de un fork de un repositorio hace al propietario del repositorio original para que este último incorpore los commits que están en el fork. En el caso que nos ocupa, el usuario aprendegit-user1 le enviará la petición a aalbagarcia para que este último incorpore los commits que tiene en su fork.

Lo primero que hará el usuario aprendegit-user1 será crear una rama que apuntará al último commit que ha hecho y que contiene las modificaciones a la página de inicio. El procedimiento es el de siempre:

• Se selecciona a la izquierda la rama master y se hace clic sobre el último commit de la rama
• Se hace click sobre el icono «Branch»
• Se introduce el nombre de la rama, en este maso mycommits
• Se hace clic sobre «Create Branch»

Si se usa la línea de comandos, la secuencia sería:

$ git checkout master
Switched to branch 'master'
$ git checkout -b mycommits
Switched to a new branch 'mycommits'

Una vez creada la rama, el usuario aprendegit-user1 hace push de la rama «mycommits» a su fork:

• Se selecciona la rama mycommits a la izquierda asegurándonos de que esta queda como rama activa haciendo doble clic sobre ella
• Se selecciona el último commit de la rama
• Se hace clic sobre el icono Push de la bara de herramientas
• En el desplegable, se selecciona en la columna «Push?» la rama mycommits y se marca en la columna de la derecha (Track) la rama local como tracking branch.
• Se hace clic sobre OK.

$ git checkout mycommits
$ git push -u origin mycommits
Total 0 (delta 0), reused 0 (delta 0)
To git@github-aprendegit-user1:aprendegit-user1/fork
    * [new branch] mycommits -> mycommits
Branch mycommits set up to track remote branch mycommits from origin.

Al terminar, el estado del repositorio es el siguiente:

Solicitando el pull request

En este momento, el usuario aprendegit-user1 accede a su cuenta de github y abre en su navegador la página de su fork https://github.com/aprendegit-user1/fork.

Una vez hemos accedido, cambiamos a la rama mycommits como se indica en la siguiente captura:

Una vez se ha cambiado a la rama mycommits, aprendegit-user1 hace clic sobre el botón «Pull Request»

Esta es la pantalla que se presenta a aprendegit-user1:

En la parte superior, aprendegit-user1 selecciona la rama que contiene los commits que aalbagarcia (el destinatario del pull request) debe incorporar en su repositorio. En la parte de abajo se ven tres pestañas en las que se puede:

• Poner un título y descripción al pull request
• Ver los commits que aalbagarcia incorporará al repositorio si acepta el pull request (pestaña Commits)
• Ver un diff que los cambios que se incluyen en los commits (pestaña Files Changed)

Es una buena práctica poner un título y descripción que reflejen el motivo del commit. Estos pull requests los ven todos los colaboradores del proyecto (si el proyecto es público lo ve todo el mundo) Así que aunque aalbagarcia y aprendegit-user1 hayan hablado por teléfono acerca de este pull request, el resto del mundo seguramente no ha escuchado la conversación. Pensando en el resto del equipo, aprendegit-user1 incluye un mensaje descriptivo de qué contiene el pull request. Cuando termina, hace clic sobre el botón «Send Pull Request». Esta es la pantalla a la que aprendegit-user1 llega después de enviarlo:

La captura es bastante sencilla de entender. Vemos el título y descripción introducidos por aprendegit-user1, los commits y una interfaz para intercambiar comentarios con el equipo.

Aunque en pequeño, se nos indica qué es lo que tendríamos que hacer para añadir commits a este pull request: enviar más commits a la rama «mycommits» del fork de aprendegit-user1.

¿Porqué podemos necesitar añadir más commits? Imagínate que el equipo revisa el pull request y se determina que todavía queda trabajo pendiente de hacer. ¿Cómo se procede? aprendegit-user1 continúa el trabajo en la rama rama «mycommits» de su fork y cuando termina lo sube a su repositorio remoto. El pull request se actualiza y todo el equipo puede ver el nuevo código. Esto lo veremos en detalle en otro artículo, de momento, seguimos con el proceso.

Aceptando el pull request

Cuando aprendegit-user1 envía el pull request, Github envía al propietario un email avisándole de que tiene un pull request listo para revisar. En este caso, el usuario aalbagarcia recibe el email, accede a su cuenta de Github y va a su repositorio https://github.com/aprendegit/fork:

En esta pantalla, seleccionamos la pestaña «Pull Requests» y accedemos a una interfaz que nos muestra todos los que tenemos. Dado que este es el primero, en este listado seleccionamos el único que hay:

Cuando aalbagarcia selecciona «Añadiendo logotipo», accede a una pantalla muy parecida a la que hemos visto con el usuario aprendegit-user1. En la siguiente captura indico cuáles son las diferencias:

Las diferencias son:

• Existe un botón «Merge pull request» que el propietario aalbagarcia utilizará para incorporar los commits al repositorio
• Existe un botón «Close» que el propietario utiliza para cerrar el pull request sin incorporar los cambios

Una vez revisado el código y confirmado que todo está bien, aalbagarcia hace clic sobre el botón «Merge Pull Request». En ese momento Github le pedirá que introduzca un comentario para el merge commit. Una vez introducido, aalbagarcia hace clic sobre el botón «Commit merge» y ya está, Github automáticamente cierra el pull request. También envía un email a los dos interesados (aalbagarcia y aprendegit-user1) avisándoles de que se han incorporado los cambios en el repositorio.

Si volvéis a la página de commits del repositorio en github (https://github.com/aprendegit/fork/commits/master) veréis que tras hacer el pull request, aparece un nuevo commit en el repositorio:

¿Cómo quedan los repositorios de aalbagarcia y aprendegit-user1?

En este momento, el repositorio remoto de aalbagarcia ya contiene el merge commit que se ha creado a través del pull request. La pregunta es ¿el de aprendegit-user1 también? ¿verán estos nuevos commits los dos usuarios?

…la respuesta es que, efectivamente, no lo verán hasta que hagan un fetch en sus respetivos repositorios. Tras hacer los dos usuarios un fetch de todos sus repositorios remotos (recuerda que aprendegit-user1 tiene 2 remotos,  origin y upstream) así quedan sus respectivas copias de trabajo:

Para terminar:

• aalbagarcia tiene que hacer un merge de la rama origin/master a la rama master
• aprendegit-user1 tiene que hacer un merge de la rama upstream/master a la rama master y después hacer un push de su rama master

Una vez hecho esto, los repositorios quedan de la siguiente manera:

Y como podéis ver, están sincronizados.

¿Quieres hace un pull request?

Si quieres hacer tú mismo el proceso para ver cómo funciona, ve al repositorio https://github.com/aprendegit/fork, haz un fork y envíanos las modificaciones siguiendo los pasos que hemos seguido en esta serie de artículos. Si tienes alguna duda no dudes en preguntarnos.

Seguiremos hablando de pull requests, aunque eso ya será en otros artículos.

1. El usuario aprendegit-user1 hizo un fork del repositorio https://github.com/aprendegit/fork
2. El usuario aprendegit-user1 modificó la página de inicio del proyecto (ficticio) que estamos usando e hizo un push de sus modificaciones a su fork (https://github.com/aprendegit-user1/fork)
3. Vimos cómo las modificaciones que aprendegit-user1 hizo a su fork no se «sincronizan» automáticamente con el repositorio original

A la vez que prendegit-user1 ha avanzado con su tarea, nuestro primer usuario (aalbagarcia) y administrador del repositorio original (https://github.com/aprendegit/fork), ha continuado también trabajando. A la vez que el usuario aprendegit-user1 ha cambiado la página de inicio, aalbagarcia ha añadido un nuevo campo a la clase Post de nuestro blog. Cuando aalbagarcia ha acabado su trabajo, lo sube al repositorio original (https://github.com/aprendegit/fork) haciendo un push.

El estado de ambos repositorios es el siguiente:

En la parte superior de la imagen tenemos una captura del estado del repositorio de aprendegit-user1 (fork) y en la parte inferior una captura del repositorio de aalbagarcia. Vemos que cada uno tiene en su repositorio su trabajo. Ha llegado la hora de sincronizarlos, cosa que haremos en dos pasos:

• Paso 1: aprendegit-usuario1 traerá a su fork el trabajo de aalbagarcia (en este caso el commit c3e3f5b que podéis ver arriba)
• Paso 2: aalbagarcia incluirá en el repositorio original el trabajo de aprendegit a través de un pull request.

Trabajando con múltiples repositorios remotos

Lo primero que aprendgit-user1 tiene que hacer es añadir el repositorio original a su lista de remotes. El usuario aprendegit-user1 abre SourceTree y va a Repository->Repository settings:

Dentro de la pantalla de «Repository settings», selecciona la pestaña «Remotes». En esta pantalla está su fork (origin). Se hace clic sobre el botón «Add» para añadir el repositorio original:

En la ventana emergente, se introduce «upstream» como nombre del remote (upstream es una sugerencia, podéis poner otro si lo preferís) y se pone la URL del repositorio original (https://github.com/aprendegit/fork). Rellenado el formulario, se hace clic en OK y de nuevo clic en OK en la ventana de preferencias. Una vez cerradas todas las ventanas de diálogo, el repositorio de aprendegit-user1 tendrá este aspecto:

En la sección «REMOTES» aparece junto a origin el nuevo origen upstream, pero si se despliega el contenido veremos que está vacío. Pulsando sobre «Fetch» descargaremos el contenido del repositorio remoto «upstream»:

…y cuando el fetch finaliza, el repositorio queda de la siguiente manera:

El fork de aprendegit-user1 ya muestra las ramas del repositorio original ¿véis el commit c3e3f5b? ¡ya lo tenemos ahí!. ¿Qué nos falta? Pues tan sólo hacer un merge de la rama upstream/master a la rama master para «sincronizar» el fork con el original. Aprendegit-user1 selecciona el commit correspondiente a nuestra rama master (en la captura anterior ya está seleccionado) y hace clic sobre el icono merge en la barra de herramientas:

En la pantalla de merge, se selecciona el commit correspondiente a la rama upstream/master y se hace clic sobre OK. Cuando el merge termina, así queda el repositorio de aprendegit-user1:

¡Ya está! aprendegit-user1 ya tiene su rama sincronizada con el repositorio original. Ahora sólo queda hacer un push; como se puede ver el propio SourceTree nos avisa de que la rama master de aprendegit-user1 está dos commits por delante de la rama remota origin/master. Basta con hacer clic sobre el icono push para que aprendegit-user1 actualice su repositorio remoto.

Cuando aprendegit-user1 termina, así quedan su repositorio (fork) y el de aalbagarcia (original):

¡aalbagarcia todavía no tiene en su repositorio el trabajo de aprendegit-user1! Para eso, aprendegit-user1 hará un pull request… en la siguiente entrada.

¡Happy gitting!

La palabra fork se traduce al castellano, dentro del contexto que nos ocupa, como bifurcación. Cuando hacemos un fork de un repositorio, se hace una copia exacta en crudo (en inglés «bare») del repositorio original que podemos utilizar como un repositorio git cualquiera. Después de hacer fork tendremos dos repositorios git idénticos pero con distinta URL. Justo después de hacer el fork, estos dos repositorios tienen exactamente la misma historia, son una copia idéntica. Finalizado el proceso, tendremos dos repositorios independientes que pueden cada uno evolucionar de forma totalmente autónoma. De hecho, los cambios que se hacen el repositorio original NO se transmiten automáticamente a la copia (fork). Esto tampoco ocurre a la inversa: las modificaciones que se hagan en la copia (fork) NO se transmiten automáticamente al repositorio original.

¿Y en qué se diferencia un fork de un clon?

Cuando hacemos un clon de un repositorio, te bajas una copia del mismo a tu máquina. Empiezas a trabajar, haces modificaciones y haces un push. Cuando haces el push estás modificando el repositorio que has clonado.

Cuando haces un fork de un repositorio, se crea un nuevo repositorio en tu cuenta de Github o Bitbucket, con una URL diferente (fork). Acto seguido tienes que hacer un clon de esa copia sobre la que empiezas a trabajar de forma que cuando haces push, estás modificando TU COPIA (fork). El repositorio original sigue intacto. Lo vamos a ver en breve con un ejemplo.

¿Para qué sirve?

Tiene varios usos. El más común es el de permitir a los desarrolladores contribuir a un proyecto de forma segura.

¿Porqué decimos de forma segura? Imaginaos un super proyecto como puede ser el código fuente de Apache. ¿Cómo se trabajaba antes de existir git? con Subversion o CVS existía un servidor centralizado que tenía dos tipos de usuarios: lo que podían «escribir» en el repositorio (subir cambios al código fuente) y los que sólo podían «leer» el repositorio. Estos últimos sólo podían bajarse el código a su máquina y podían modificarlo sólo en su copia local. No podían subir ninguna modificación al servidor central.

¿Qué tenías que hacer para contribuir? Tenías que solicitar permiso de escritura y que alguien te lo diese. Una vez te lo concedían, ya podías subir tus modificaciones y, por supuesto, liarla si no sabías lo que estabas haciendo. Otra opción era enviar parches, trabajar con ramas… había varias formas pero todas bastante engorrosas.

Además, este procedimiento de dar acceso de escritura a un repositorio centralizado es un poco arriesgado. Siguiendo con el ejemplo que he puesto de Apache ¿cómo sé yo, responsable del repositorio, que esta persona que está a 10000Km de mí en la otra punta del planeta sabe lo que está haciendo? ¿puedo confiar en él?. Al final, contribuir a un proyecto se convertía en una tarea tediosa tanto para el que pretendía contribuir como para el que lo tenía que gestionar. Y no hablemos de lo divertido que era hacer un merge…

Git, al tratarse de un sistema distribuido, resuelve este tipo de problemas de una forma muy elegante a través de los forks. Digamos que Pepito es una persona quiere contribuir al proyecto. Ha encontrado un bug y sabe cómo corregirlo. Como propietario del repositorio me interesa que Pepito pueda enviarme el parche de forma rápida, que no pierda mucho tiempo. Si es así ¡Pepito estará encantado de colaborar con nosotros! ;-). Además, necesito que el proceso sea ágil, no quiero tener que invertir 5 horas de mi tiempo cada vez que tenga que hacer un merge del trabajo que Pepito me envíe. ¿Cómo resuelve git el problema?

1. Pepito hace un fork de mi repositorio, para lo que sólo necesito darle permiso de lectura.
2. Pepito trabaja en SU COPIA (fork) del repositorio. Como es suya, puede hacer lo que quiera, la puede borrar, corromper, dinamitar, reescribir la historia del proyecto… nos da lo mismo, es SU COPIA (fork).
3. Cuando Pepito termina de programar y testear el parche, me avisa de que ya lo tiene y me dice «En la rama parche_de_pepito de MI COPIA (fork), tienes el parche que corrige el Bug XXXX».
4. Yo voy a su repositorio, miro lo que ha hecho y si está bien lo incorporo (merge) a mi repositorio, que es el original.

Las ventajas de este proceso son las siguientes:

1.  Pepito trabaja con SU COPIA. En ningún momento le tengo que dar acceso al repositorio central.
2. El proceso de incorporación de los cambios de Pepito es muy sencillo. Si no hay conflictos en los ficheros puede que sea tan simple como ejecutar un par de comandos git.
3. Pepito tiene muy fácil contribuir, no le cuesta esfuerzo.
4. Yo puedo gestionar muy fácilmente las contribuciones de muchas personas ¡me cuesta muy poco trabajo!

Haciendo Fork de un repositorio en Github

Bueno, vamos a ver esto con un ejemplo práctico. La situación es la siguiente: en nuestra organización, www.aprendegit.com, tenemos un repositorio de un proyecto RubyOnRails y que usaremos a modo de ejemplo. Este repositorio se encuentra en la siguiente URL: https://github.com/aprendegit/fork. Podéis reproducir los pasos que vamos a dar a continuación con vuestra cuenta de github.

Para ayudarnos con el desarrollo de este proyecto, contamos con la ayuda de varias personas:

1. El usuario aalbagarcia (que soy yo) y que es uno de los administradores del repositorio y de la organización.
2. El usuario aprendegit-user1, que es un colaborador altruista que quiere ayudarnos con la web.
3. Vosotros: si hacéis el tutorial y seguís los pasos (tened en cuenta que habrá dos entregas más) acabaréis enviándonos vuestras «mejoras ficticias» a través de un pull request.

No dudamos de las buenas intenciones de aprendegit-user1 ni de sus capacidades y aptitudes (ni de las vuestras tampoco). Aún así, siguiendo las buenas prácticas en el uso de git, aprendegit-user1 sólo tendrá permiso de lectura en el repositorio https://github.com/aprendegit/fork.

Si no tiene permiso de escritura, el usuario aprendegit-user1 podrá clonar el repositorio (porque es público) pero no podrá hacer un push. De poco le va a servir clonarlo y trabajar sobre él si luego no va a poder hacer un push ¿qué debe hacer? Hacer un fork.

El usuario aprendegit-user1 va a github, accede con su usuario y contraseña y abre la URL del repositorio original https://github.com/aprendegit/fork: 

En la página del repositorio, aprendegit-user1 hace clic sobre el botón fork. Al hacer clic, Github va a crear un nuevo repositorio en su cuenta que es una copia del repositorio aprendegit/fork:

Cuando el proceso de forking termina (puede durar varios minutos si el repositorio que estamos bifurcando es muy grande) aprendegit-user1 acaba en la siguiente pantalla:

Este repositorio es una copia del original (https://github.com/aprendegit/fork). Si comparáis la historia de los dos repositorios veréis que es idéntica.

Este nuevo repositorio (https://github.com/aprendegit-user1/fork) es el que nuestro usuario aprendegit-user1 va a utilizar para trabajar y, cuando termine, enviarnos sus modificaciones.

aprendegit-user1 empieza a colaborar con nosotros

La primera tarea que aprendegit-user1 va a hacer como colaborador nuestro es modificar la página de inicio añadiendo nuestro logo. Para ello, clonará su fork y trabajará sobre él como si fuese un repositorio normal. Dado que el fork está en su cuenta, él es el propietario y como tal  podrá hacer push sin ningún problema. Recordad que al repositorio original (https://github.com/aprendegit/fork) este usuario no puede hacer push.

Al cabo de unos minutos, aprendegit-user1 ha clonado su repositorio (https://github.com/aprendegit-user1/fork) en su máquina, ha añadido el logo y ha hecho un push a su fork:

Si volvéis al repositorio original (https://github.com/aprendegit/fork) veréis que este sigue igual, las modificaciones que aprendegit-user1 ha subido están sólo en el fork de aprendegit-user1.

Misión cumplida: aprendegit-user1 ya está trabajando en su repositorio sin preocuparnos ninguno de los dos de que algo salga mal.

Esto es todo por hoy. En la siguiente entrada veremos qué ocurre si después de que aprendegit-user1 ha hecho un fork, nuestro administrador (aalbagarcia) sube cambios al repositorio original ¿cómo actualiza aprendegit-user1 su fork?.

¡Happy gitting!