Aunque Git es un sistema de control de versiones simple y fácil (y más a diferencia de otros que he conocido) también es cierto que incluso las cosas más simples pueden llegar a crear situaciones complicadas. Y Git no es la excepción.

La literatura y difusión de Git nos señala la existencia de operaciones básicas (de uso frecuente), las avanzadas (menos frecuentes en su uso) y las de emergencia (en las que se combinan las de los grupos anteriores y algunas otras menos frecuentes aún). Dentro de las primeras, está el tema de la consolidación de cambios, cuando hacermos merges o pull/push requests, que frecuentemente lleva a muchas complicaciones. Entre más gente esté participando en el desarollo de componentes comunes es mucho más probable la aparición de conflictos. Aquí es cuando se nota el trabjo del líder del projecto o la coordinación del equipo de trabajo, que se materializará en la estrategía a seguir en la unificación de cambios (e.g. si será con un merge o un rebase, por ejemplo). Realmente es increible lo complicado que esto puede tornarse y así requerir tiempo de solución cuando los conflictos aparecen.

Si bien la resolución de estos conflicto llegan a recarer en la memoria del desarrollador, quien al revisar el señalamiento de los cambios comunes va interpretando su utilidad y recordando su sucesión, hay momentos en los que debe recurrir a herramientas que le ayuden a determinar la forma en que éstos sucedieron. Git provee una muy buena herramienta al respecto, que es su propia bitácora de cambios, pero al ser una característica poco usada, resulta desconocida. Remontar la curva de aprendizaje requerida en un momento de presión y urgencia es poco probable que ocurra. El uso de la herramienta en sí no es demasiado difícil, principalmente la dificultad radica en la interpretación de lo que ésta entrega.