Por qué dejé de trabajar con un colaborador que no usaba control de versiones

Antes de saber lo que era un commit, también pensaba que el control de versiones era «para empresas grandes».
Ahora no me imagino colaborar en un proyecto sin él.

No uso Git porque me encante abrir la terminal (spoiler: no me encanta).
Lo uso porque es lo que permite trabajar con orden, con confianza, y sin pisarnos el código cada dos por tres.

Este post no va de Git.
Va de una colaboración que no funcionó porque alguien no quiso aprender lo básico para trabajar bien en equipo.
Y sí, el control de versiones fue el detonante, pero lo que había detrás era otra cosa.

El problema no era Git, era no usar control de versiones

No despedí a nadie por no saber usar Git.
Lo hice porque, después de meses dándole margen, vi que no había interés en aprender lo básico para trabajar en equipo. Y eso ya no es un tema técnico, es una cuestión de compromiso.

No esperaba que dominara Git como si llevara años usándolo.
Solo pedía algo tan sencillo como:

Lo mínimo para trabajar sin romper cosas

• Crear ramas para no pisarnos
• Hacer commits claros y con sentido
• Pull y push cuando toca
• Y si hay conflictos, resolverlos (o avisar)

No era mucho.
Pero cada conversación sobre esto parecía un muro. Y eso desgasta.

Todo lo que intenté antes de cortar por lo sano

No le dije «usa Git o te vas».
Intenté ayudarle, explicarle, hacerle el camino más fácil.

Le grabé vídeos mostrándole cómo usar GitHub Desktop, cómo conectarlo con Visual Studio Code, cómo hacer los commits básicos y seguir un flujo sencillo. También le pasé documentación y me ofrecí a resolver cualquier duda que tuviera.

👉 Si quieres ver cómo gestiono un proyecto completo trabajando con diseño y control de versiones, te dejo este post donde explico mi proceso de trabajo con una diseñadora usando GitHub.

Durante meses pensé que simplemente le costaba y que con un poco de guía, lo pillaría.

Durante meses pensé que simplemente necesitaba tiempo.
Hasta que un día, revisando su perfil, vi que se había creado su cuenta de GitHub tres días antes. Después de todo ese tiempo hablando del tema, de haberle dado recursos y apoyo.

Y lo más fuerte es que no era alguien que estuviera empezando.
Él mismo decía que llevaba 15 años programando en PHP.
Pero todavía trabajaba con Dreamweaver.

Sí, Dreamweaver. En pleno 2025.
Y no porque el proyecto lo requiriera, sino porque «así lo había hecho siempre«.

No era falta de experiencia.
Era falta de adaptación, de interés y de respeto por cómo trabajamos ahora quienes sí colaboramos con otras personas.

La excusa de siempre

«Nunca me ha hecho falta.»
«Ningún cliente me lo pide.»

Esa fue su respuesta.

Y ahí entendí que el problema no era técnico, sino de actitud.
Porque si estás trabajando con otra persona en un mismo proyecto y ni siquiera te interesa aprender lo básico del flujo de trabajo… ¿cómo se supone que vamos a funcionar?

El momento en el que lo vi claro

Después de mucho aguantar, entró otra persona al equipo para ayudar en el proyecto.
Y ahí fue cuando todo explotó.

Caos en directo:

• Se pisaban archivos
• Cambios que desaparecían
• Código sobreescrito
• Archivos sin rastrear
• Dudas constantes sobre quién había tocado qué

Tenía que estar todo el rato revisando, corrigiendo y mediando.
No era sostenible. Y no era justo.

No va de Git. Va de respeto por el trabajo en equipo

Yo también fui junior.
Yo también he aprendido muchas cosas «sobre la marcha».
Y por eso tengo paciencia. Mucha. Pero lo que no tolero es la desgana.

Estas son mis líneas rojas:

• Si no quieres aprender algo básico que te están enseñando…
• Si ignoras las herramientas que hacen posible trabajar juntas…
• Si tu forma de trabajar es «como yo lo hago y punto»…

Entonces no podemos trabajar juntas.
Porque eso no es colaborar. Eso es ir cada una a su bola.

Cerrar una colaboración también es cuidarse

Dejar de contar con esa persona fue una decisión difícil, pero necesaria.

No se trata de «castigar» a nadie.
Se trata de proteger el proyecto, cuidar al resto del equipo y respetar mi trabajo también.

Desde entonces, lo tengo claro:
el control de versiones no es opcional, como tampoco lo es querer hacer bien las cosas cuando trabajas con otras personas.

Porque cuando no hay control de versiones, no hay control del trabajo, ni del equipo, ni del tiempo que inviertes.
Y yo ya no estoy para repetir errores que sí se pueden evitar.

Atribuciones

• Foto de Mohammad Rahmani en Unsplash
• Foto de Yancy Min en Unsplash