Flujos de trabajo y Ramas Remotas

---

Ramas de Largo Recorrido

Por la sencillez de la fusion de Git, fusionar una rama a otra varias veces a lo largo del tiempo es facil de hacer. Esto te posibilita tener varias ramas siempre abiertas, usandolas en diferentes etapas del ciclo de desarrollo y realizando fusiones frecuentes entre ellas.

Muchos desarrolladores que usan Git llevan un flujo de trabajo de esta naturaleza: manteniendo en la rama master unicamente el codigo totalmente estable, y teniendo otras ramas paralelas denominadas develop o next, en las que trabajan y realizan pruebas.

---

Puede ser mas sencillo pensar en las ramas como silos de almacenamiento, donde grupos de confirmaciones van siendo promocionados hacia silos mas estables a medida que son probados y depurados.

Este sistema es util para poder ampliar a diversos grados de estabilidad. Algunos proyectos muy grandes suelen tener una rama proposed o pu (proposed updates), con todo aquello que no esta listo aun para ser integrado en develop o master. La idea es mantener siempre las ramas en diferentes niveles de estabilidad. Cuando alguna alcanza un estado estable, se fusiona con la rama inmediatamente superior.

---

Ramas Puntuales

---

Supongamos que decides que la segunda solucion al problema iss91v2 es la mejor. También muestras la rama dumbidea a tus companeros y resulta que les parece genial. Puedes entonces descartar la rama iss91 original (perdiendo las confirmaciones C5 y C6) y fusionar las otras dos. El historial quedaria similar al de la imagen.

Es importante recordar que, mientras haces todo esto, todas las ramas son completamente locales. Cuando ramificas y fusionas, todo se realiza en tu propio repositorio Git: sin ningun servidor, sin ninguna comunicacion remota.

---

---

Ramas Remotas

Las ramas remotas son referencias al estado de las ramas en tus repositorios remotos. Son ramas locales que no puedes mover. Git las mueve automaticamente cada vez que estableces comunicacion con el servidor remoto, para reflejar con precision el estado de ese repositorio.

Estas ramas actuan como marcadores, recordandote donde estaban las ramas en tus repositorios remotos la ultima vez que te conectaste a ellos. Las ramas remotas usan el formato <remoto>/<rama>. Por ejemplo, si quieres ver el estado de la rama master en el remoto origin la ultima vez que te comunicaste con el, revisas la rama origin/master.

---

---

Si haces algun trabajo en tu rama master local, y mientras tanto alguien mas envia cambios al servidor, sus historiales avanzaran de forma diferente. Ademas, mientras no tengas contacto con el servidor origin, tu puntero origin/master no se movera.

---

Sincronizar

---

Multiples remotos

Supongamos que tienes otro servidor Git interno, usado solo por uno de tus equipos de sprint. Puedes agregarlo como remoto con:

git remote add teamone git://git.team1.ourcompany.com

Luego puedes traer todo lo que ese servidor tiene y tu no, con git fetch teamone. Como este servidor contiene un subconjunto de lo que ya tiene origin, Git no descarga ningun dato, simplemente crea una rama teamone/master apuntando al commit que teamone tiene en su master.

---

---

Publicar (Push)

Cuando quieres compartir una rama con el resto del mundo, debes enviarla a un remoto sobre el que tengas permisos de escritura. Tus ramas locales no se sincronizan automaticamente con los remotos: tienes que enviar (push) explicitamente las ramas que quieras compartir. Por ejemplo, si tienes una rama serverfix en la que quieres trabajar con otros:

git push origin serverfix
Counting objects: 24, done.
...
To https://github.com/schacon/simplegit
 * [new branch]      serverfix -> serverfix

Esto es un atajo. Git expande automaticamente serverfix a refs/heads/serverfix:refs/heads/serverfix, que significa: “toma mi rama local serverfix y enviala para actualizar la rama serverfix del remoto”. Tambien puedes hacer:

git push origin serverfix:serverfix

O incluso publicarla con un nombre diferente en el remoto:

git push origin serverfix:awesomebranch

---

La proxima vez que tus colaboradores hagan git fetch origin, obtendran una referencia al estado de serverfix en el servidor, bajo el nombre origin/serverfix.

git fetch origin
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/schacon/simplegit
 * [new branch]      serverfix    -> origin/serverfix

Es importante notar que no obtienen automaticamente una copia local editable, sino solo el puntero remoto. Para integrarlo en su trabajo actual pueden fusionarlo:

git merge origin/serverfix

O si quieren su propia rama local de serverfix sobre la que trabajar:

git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'

---

Ramas de Seguimiento (Tracking Branches)

Al hacer checkout de una rama local a partir de una rama remota, se crea automaticamente lo que se denomina una rama de seguimiento (tracking branch). Las ramas de seguimiento son ramas locales que tienen una relacion directa con una rama remota. Si estas en una rama de seguimiento y ejecutas git pull, Git sabe automaticamente de que servidor obtener los datos y con que rama fusionar.

Cuando clonas un repositorio, generalmente se crea automaticamente una rama master que sigue a origin/master. Sin embargo, puedes configurar otras ramas de seguimiento con git checkout -b o con la opcion --track:

git checkout --track origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'

Para configurar una rama local con un nombre diferente al de la rama remota:

git checkout -b sf origin/serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch 'sf'

Ahora, tu rama local sf hara push y pull automaticamente hacia/desde origin/serverfix. Si ya tienes una rama local y quieres asociarla a una rama remota, o cambiar la rama que estas siguiendo, usa -u o --set-upstream-to:

git branch -u origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.

---

Para ver todas tus ramas de seguimiento configuradas, puedes usar git branch -vv:

git branch -vv
  iss53     7e424c3 [origin/iss53: ahead 2] forgot the brackets
  master    1ae2a45 [origin/master] deploying index fix
* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it
  testing   5ea463a trying something new

Esto muestra que:

• iss53 sigue a origin/iss53 y esta 2 commits por delante del remoto.
• master sigue a origin/master y esta al dia.
• serverfix sigue a teamone/server-fix-good, esta 3 commits por delante y 1 por detras.
• testing no sigue ninguna rama remota.

Estos datos provienen de la ultima vez que hiciste fetch. Si quieres valores totalmente actualizados, haz primero git fetch --all y luego git branch -vv.

---

Traer cambios (Pull)

• git fetch descarga los cambios del servidor pero no los fusiona con tu trabajo local.
• git pull es esencialmente un git fetch seguido de un git merge, aplicado automaticamente sobre la rama que tu rama local esta siguiendo.

En general, es mas explicito y menos propenso a confusiones usar git fetch y git merge por separado.

Pero personalmente prefiero usar git pull..

---

Eliminar Ramas Remotas

Si ya terminaste con una rama remota y quieres borrarla del servidor:

git push origin --delete serverfix
To https://github.com/schacon/simplegit
 - [deleted]         serverfix

Esto solo elimina el puntero en el servidor. Git conserva los datos durante un tiempo hasta que el recolector de basura los limpie, por lo que si fue eliminada accidentalmente suele ser sencillo recuperarla.

---

---

Recursos

• Pro Git - Cap. 3: Desde 3.4 a 3.5