Cómo enfrentarte a un conflicto de terminal y no morir infartada

“Las opiniones, hechos e interpretaciones expresadas en esta publicación, que no han sido sometida a revisión editorial o de otro tipo, son de exclusiva responsabilidad de sus autoras y pueden no coincidir con las de Adalab.”

Si has llegado hasta aquí es que ya estás programando y estás haciendo un proyecto con tu equipo ¡Enhorabuena!

Ya de primeras abrir la terminal es como lanzarte al vacío, ese lugar inhóspito y oscuro con letras de colores y que no ves qué se ejecuta. ¡Menudo invento del averno! Pero bueno, al final es como el deporte y con el tiempo acabas cogiéndole el gustito.

Cuando ya parece que empiezas a escribir comandos en terminal y se ejecutan cosas, estás alucinando, es todo tan bonito como un domingo soleado pero…entonces aparece esa maldita palabra: CONFLICTO.

Y entonces esto es lo que suele pasar:

1. Entras en pánico

Es algo que nos pasa a todas en cuanto vemos la palabra CONFLICTO en la pantalla. Seguramente veamos esto y no leamos más, solo podemos pensar: ¿Qué está pasando? ¡Va a explotar!

2. Te paras a leer

Después de esto respiras tres veces y lees lo que te pone en la terminal. ¡Anda! Parece que hay más información de la que parece. Y entonces ves cuáles son los archivos que te están dando el conflicto.

3. Hablas con tu equipo

Parece que por ser programadora te vas a meter en tu ordenador y no va a haber más mundo pero, todo lo contrario, la comunicación es de lo más importante para que un proyecto salga adelante. Así que descubres cuál de tus compañeras ha tocado los archivos con los que tienes conflicto y os ponéis juntas a arreglarlo.

4. Tocáis el código

Abres el proyecto en el editor de código (en este caso Code) y buscáis los conflictos. Para saber cuáles son los archivos, en la rama de archivos al lado de cada uno de ellos que haya que modificar sale una C en color.

Para verlos se puede hacer de varias formas, a mí, personalmente, me gusta abrirlo y directamente ver a qué altura está el conflicto. Esto se ve en la parte de la derecha, donde está el scroll, aparecerá un color verde (el código que está subido) y uno azul (el código que queremos subir). Hay que elegir si queremos uno, otro o los dos para conservarlos en la rama master del proyecto.

5. Subes los cambios y el mundo es un lugar mejor

Ya está todo arreglado así que vuelves a hacer add, commit y push y… ¡Todo funciona! Los pajarillos cantan y el sol brilla más.

Realmente esto nos va a pasar a menudo pero tenemos algunos tips importantes que si recordamos pueden sernos útiles:

• Git pull como beber agua, cuantas más veces mejor. No hay que volverse loca pero, como de momento son gratis, yo suelo hacerlo antes de empezar a trabajar y antes de subir cualquier cambio o hacer merge. Cuantos menos dramas, más feliz :)
• Trabajar en ramas. Al principio parece que no estás al día de todo y trabajas aparte pero es de lo más útil, sobre todo, para no interferir en el trabajo de las demás. Y por supuesto, repartirnos el trabajo antes de empezar, si trabajamos sobre el mismo archivo el conflicto está asegurado.
• Git status es amigo. En la mayoría de las ocasiones ni siquiera nos acordamos de que existe pero realmente resulta muy útil antes de hacer un push. Si llevamos días trabajando en la misma rama posiblemente no nos acordemos de los archivos que hemos modificado y cuáles no, pues status nos lo chiva. ¡Así de majo es!

Espero que estos pequeños tips os ayuden en vuestro día a día a no tenerles miedo y a combatirlos con valor y, sobre todo, a saber que todos hemos tenido ese pequeño gran drama con nuestros amigos los conflictos. Como dicen, mal de muchos…