Para añadir un repositorio remoto utilizamos el comando magit-remote-add, nos pedirá una URL. En nuestro caso, creamos en pasos anteriores un repositorio bare en ~/repositorio-prueba para que nos sirva de remoto. Nos preguntará también por un nombre y el más preferible para el repositorio principal suele ser origin, aunque podemos utilizar otros.

Para subir cambios a un repositorio remoto pulsamos P, o S-p, si lo preferís así... vamos lo que viene a ser una pe con mayúsculas. Nos aparecerá un diálogo como el siguiente:

Es el primer push que vamos a hacer y necesitamos fijar dónde, vamos a pulsar u, nos preguntará algo como Set upstream of master and push there y puesto que ya habíamos establecido el repositorio remoto con el nombre origin nos muestra lo siguiente:

Y al pulsar <RET>:

Como vemos, nuestro HEAD está en el mismo commit que el origin/master y, además, en los commits recientes nos marca ambos en el mismo lugar.

Quizá si hacemos cambios podemos ver la diferencia cuando dejan de estar sincronizados. Escribo un par de líneas más y repito el proceso del commit en local para ver la diferencia:

Como vemos, nuestro HEAD local está en un commit mientras que el repositorio remoto está en el anterior. Magit además nos avisa de que hay algunos commits, ─en concreto (1), dice─ que están sin subir al remoto. ¿Cómo los sincronizamos de nuevo? Pues como hicimos antes, pero más fácil: P u... si nuestro remoto es de verdad y nos conectamos a él por SSH o por cualquier otro método, nos pedirá la contraseña correspondiente y todo vuelve a estar sincronizado.

En el momento en que creamos una rama, todos los cambios que hagamos en ella no afectarán al tronco del que nace. Vamos a crear en nuestro proyecto una rama con magit, paso a paso, como hemos venido haciendo hasta ahora:

Si nos fijamos en la línea de estado, nos especifica que estamos en Git-master. A mí me gusta crear una rama y cambiarme a ella inmediatamente, por eso suelo utilizar magit-branch-and-checkout más que magit-branch-create... pero se puede crear la rama y permanecer en la anterior, hacer lo que se necesite y cambiar a la rama creada posteriormente. Cuando iniciamos el comando, después de solicitar la creación de la rama, nos preguntará en cuál otra queremos basar la nueva rama:

No tenemos mucho donde elegir, sólo una: master. Así pues, la seleccionamos y después nos preguntará por el nombre de la nueva rama. En mi caso he seleccionado uno tan descriptivo como rama-nueva. Pero recuerda que en el caso de ser un repositorio de trabajo, es recomendable utilizar nombres más descriptivos para no liarnos. Sobre todo si se van a utilizar muchas ramas.

¿Cómo afecta todo esto a nuestro repositorio? Pues lo vemos en la siguiente imagen:

Los cambios remarcables son sencillos:

1. La barra de estado nos avisa que estamos en la rama Git-nueva-rama.
2. Nuestro HEAD está en nueva-rama y también nos avisa de que no existe la rama remota origin/nueva-rama.
3. El commit actual es el mismo en el que creamos la rama. Así que ahora mismo el estado de rama-actual coincide con las ramas master y origin/master, porque es en el que hemos basado la rama nueva.

Para que todo fluya, vamos a hacer cambios en esta rama y compararemos qué ocurre con esos cambios. Por ejemplo, vamos a crear otro fichero de texto nuevo y a añadirlo al proyecto.

El proceso de stage → commit → push es idéntico al que hemos hecho para el fichero anterior. La diferencia es que la rama remota no existe y vamos a crearlo. Al hacer el push seleccionamos u

Nos dirá que la rama remota no existe y que qué rama utiliza para el push y entre las opciones aparecerá una con la opción con el nombre origin/nueva-rama

Al seleccionar dicha opción creará una nueva rama en el repositorio remoto con nuestro contenido. ¿Qué nos dice magit sobre todo esto? Pues vamos a fijarnos en la siguiente imagen.

Si nos fijamos nuestro HEAD sigue en nueva-rama, un commit más avanzado que antes. Si miramos los commits recientes veremos que atrás, ─un commit por debajo─, se queda la rama master, tanto la local como la remota.

¿Qué ocurre si cambiamos de rama? Pues vamos a verlo: magit-checkout y nos dejará seleccionar a qué rama queremos mudarnos. En nuestro caso seleccionaremos master que es una rama local y obtendremos algo como

¿Eh? El fichero nuevo que con tanta dedicación he hecho, ¡ha desaparecido! ¡Maldición! ¡Córcholis! ¡Cáspita! (Hmmm, no se me ocurren más tontás que decir, ya si eso otro día sigo con las imprecaciones ñoñas).

Pues eso, han desaparecido todos los cambios que hubiéramos hecho en la rama... NO, simplemente están en la otra rama. Si volvemos a cambiar de rama volverán a aparecer. Ahora mismo tenemos dos versiones independientes, por decirlo de algún modo, de nuestro trabajo.

Pues como suponemos que nuestro repositorio es compartido, es posible que alguien suba modificaciones al mismo. Ese hecho hará que nuestro repositorio local esté fuera de sincronía también: ¿cómo volvemos a sincronizar el repositorio local con el remoto? Pues tenemos dos opciones fetsh o pull... veamos cómo hacerlo desde magit:

1. Desde la ventana de magit, pulsamos f, si queremos hacer fetch, o F, si queremos hacer pull.

   

2. El diálogo que aparece nos permite seleccionar el repositorio, si hubiera más de uno, del que queremos bajar los cambios remotos. Pulsamos u para que baje los de origin. Y nuestro repositorio nos informa, de que efectivamente tenemos cambios sin actualizar, véase el apartado de Unpulled from... en la ventana:

   

3. Mirando los cambios que han hecho decidimos que son correctos y los importamos a nuestro repositorio con F, que como he dicho antes, lo que hace es un pull.

   

Ya tenemos nuestro repositorio local de nuevo sincronizado con el remoto. Además hemos introducido la imponderable variable del trabajo en equipo y vemos que podemos trabajar en paralelo. Aunque seguro que encontraremos ocasiones en las que nuestros cambios entren en conflicto con los cambios de otros... no nos precipitemos.

Al principio entendía rebase como superar o adelantar y el concepto se me rompía en las entendederas. Al final, me he acostumbrado a entenderlo como poner base de nuevo o cambiar la base de la rama (gracias a deesix del IRC, que supo darle el enfoque al concepto que hizo click en mi cuadriculada mente).

Como hemos visto antes, nuestra rama master ha cambiado y nuestra rama tiene cosas que no están allí y por otro lado la rama master tiene cosas que nuestra rama de trabajo local no tiene. ¿Podemos hacer que esos cambios vengan a mi rama de trabajo para tenerlos en cuenta?

Pues sí, podemos hacerlo con un rebase. Atención: para modificar el contenido de cualquier rama debemos situarnos en la rama que debe cambiar. En nuestro caso, la rama rama-nueva va a cambiar su contenido base, se va a rebasar (volver a basar) en master. Por tanto, vamos a asegurarnos que estamos en la rama adecuada: magit-checkout y seleccionamos rama-nueva. Todo debe cambiar a algo como:

Observa que la rama en la línea de estado del fichero que está abierto es, efectivamente Git-nueva-rama y además en nuestra ventana de magit el HEAD apunta a la misma rama. Pues nada, hechas las comprobaciones necesarias pulsamos r y nos aparece el menú de opciones del rebase

Seleccionamos e (elsewhere) y después la rama master y... ¡Mierda! ¡Ya han «tocao argo» y falla el rebase! ¿Pero qué ha fallado? pues pulsamos $ como nos dice el aviso de error y vamos a ver:

Bien, parte del contenido se ha añadido, pero tenemos otra parte que no en el apartado Unstaged changes del magit. Pulsamos <RET> sobre dicha cabecera y nos mostrará el conflicto:

Bien vale, ahí está el problema (ya se ve que está hecho a propósito para que falle... pero hay veces que no y el problema no lo puede resolver el programa él solo y necesita que lo resolvamos nosotros). ¿Cuál es el texto bueno? Pues en esa ventana de diff volvemos a pulsar <RET>... esto nos debe llevar al fichero que ha generado el conflicto.

Vemos que Emacs nos remarca las partes que entran en conflicto con colores, aprovechando que git nos los marca entre las etiquetas <<<<<<< y >>>>>>> y además separados por la etiqueta =======

<<<<<<< HEAD
Esto es un texto nuevo que debería entrar en conflicto con el ya
existente.

Ahora veremos si colisiona.
=======
Este texto, es nuevo y viene a ilustrar cómo funcionan estas cosas de
las ramas.

Tampoco voy a escribir mucho más para no perder el tiempo.
>>>>>>> 1b03c62... Nuevo fichero en la rama «repositorio-prueba»

Cambiamos el texto corrigiendo lo que haga falta. Cuando quitemos esas etiquetas, el texto dejará de marcarse en colores. Para el ejemplo, lo he modificado a algo así:

Esto es un texto nuevo que debería entrar en conflicto con el ya
existente.

Ahora veremos si colisiona...

Efectivamente han colisionado y lo tenemos que arreglar a mano.

Este texto, es nuevo y viene a ilustrar cómo funcionan estas cosas de
las ramas.

Tampoco voy a escribir mucho más para no perder el tiempo.

Bien, ya hemos corregido el error ¿y ahora qué? Pues vamos, lo primero a guardar los cambios y después vamos a la etiqueta Unstaged changes que mencionamos antes y pulsamos s (stage en inglés) para indicarle a git que ya hemos resuelto los cambios y lo tenemos todo listo para continuar nuestro accidentado rebase. ¿Os acordáis de qué tecla lanzaba el rebase? ¿Sí? efectivamente, pulsamos la misma tecla r y nos aparece el siguiente menú:

Efectivamente, entre las opciones debemos elegir continuar el rebase pulsando de nuevo la tecla r y nos pedirá hacer un commit con el contenido que hemos tenido que arreglar a mano.

Podemos dejar el mensaje tal cual, pero a mí me gusta avisar que he tenido que resolver los conflictos a mano, también para avisar a quien haya hecho los cambios, que algunas cosas que encuentre en su código o fichero, no coincidirán con lo que escribió.

Resueltos todos los conflictos que encontremos podemos seguir con nuestras modificaciones, hacer nuestros commits, y todo el trabajo como hasta ahora. Pero llega un momento que nuestro trabajo va a necesitar estar en master... ¿cómo hacemos para llevar nuestra rama a otra? (en este caso a master). Pues para eso se inventó el merge que es el proceso por el que los contenidos se mezclan. Igual que antes con el rebase, vamos a situarnos en la rama que recibe los cambios, en nuestro caso master... y también tienes que estar preparado para que aparezcan conflictos (pero como ya sabes que es relativamente sencillo sobreponerse a ellos, pues adelante sin miedo).

Por pasos:

1. Nos situamos en la rama que recibe los cambios: magit-checkout y seleccionamos master.

2. En la ventana de magit, pulsamos m (merge en inglés).

   

3. En este caso utilizo la combinación -n, para añadir el equivalente de línea de comandos --no-ff y después m para realizar el merge.
4. Nos pregunta qué rama queremos «mergear» y en nuestro caso seleccionamos rama-nueva.

Si todo ha ido bien, como es de esperar en el ejemplo, porque los conflictos venían resueltos de antes y nadie más (es decir, yo haciendo de mi alter ego el enano cabrón que me jode los commits) pues hemos acabado el merge.

Si se presentaran conflictos, pues tendríamos que hacer como antes: arreglar el texto a mano, ir guardando, hacer más commits... lo que necesitemos para dejar todo listo y suave.

Una forma de tener de un vistazo el repositorio con su historial de commits es el comando magit-log que como su nombre indica, igual que todos los comandos que venimos viendo es el equivalente de git log. ¿Qué ventajas tiene la interface de Emacs? Vamos a ver cómo está nuestro repositorio pulsando l (log en inglés), en la ventana de magit. Nos aparecerá el menú para abrir la pantalla de log:

Aprovechando este menú, remarco las opciones que están activadas. Si pulsamos un - se supone que queremos introducir alguna opción, limitando la búsqueda u otros parámetros. En nuestro caso, vamos a pulsar b para que nos muestre todas las ramas y nos aparecerá una lista con los commits que hemos ido haciendo. Nuestra lista es muy simple, pero cuando empiezan a aparecer ramas, la cosa se complicará más.

Pulsando <RET> en cualquiera de la línea nos mostrará los detalles del commit: