Problemas desarrollo Sprint 2

Una rama por fix

Ramas de corrección de bugs que acumulan muchas correcciones en mucho tiempo son un problema, para unir (conflictos) y para entender qué se ha modificado en la rama.

Lo mejor es hacer una nueva rama para cada fix (o alguno más, pero pocos), que no dure abierta más de un día. Se corrige, se hace Pull Request, se integra. Rápido.

Editar archivos comunes

Si dos personas editan paralelamente un mismo archivo se producen conflictos. Son algo natural, y normalmente si se tienen las ramas organizadas e integradas constantemente no es problema.

Pero en archivos html el problema se vuelve grave. Un nuevo div al principio de la jerarquía provoca que todo el contenido de dentro cambie (tabulación), y el conflicto que provoca con cambios en ese contenido desde otra rama es... para morirse.

Cuando se modifiquen plantillas hay que procurar organizarse dentro de lo posible para que no se toque la misma a la vez, y que no se mantengan mucho tiempo abiertas ramas con cambios en plantillas, que se incorporen pronto a develop.

Cuidado con el formato

Un cambio de formato en el código puede registrar muchos cambios "fantasma" en el repositorio (ej: cambio de tabulación por espacio, espacio de separación entre parámetros, saltos de línea en líneas largas, etc). Muchos de estos cambios los hace el IDE automáticamente (pulsando cmd+alt+L re-formatea el código completo en Mac).

El problema es que cambios de este tipo donde no son estrictamente necesarios provoca:

1. Muchos cambios innecesarios, de forma que cuando se revisa el commit en GitHub o SourceTree es difícil ver lo que realmente se ha cambiado del código.
2. Conflictos estúpidos y chungos. Si se cambia el formato en un trozo del código, y se cambia algo de ese trozo en otra rama, al unirlas se va a detectar un gran tocho como conflictivo, y por el motivo anterior va a ser muy complicado saber con qué partes quedarse de cada rama. Ej: d6316633

La solución:

• Usar el diff de SourceTree. Antes de hacer commit, mirar archivo a archivo en el Working Tree qué cambios se han registrado, descartar los que no son necesarios y stagear los buenos. Desde SourceTree puede hacerse por "trozo" (hunk) o por líneas individuales.
• Estar atento, especialmente en los html, de no cambiar por accidente el formato de partes innecesarias. Y cuando sea necesario, x ej, añadir elementos a la jerarquía y metan muchas tabulaciones, asegurarse de que nadie más está modificando ese archivo en otra rama. Si es así, consultar y ponerse de acuerdo.
• Cuando se quiera arreglar el formato de algún código, para dejarlo conforme al formato automático de PyCharm o las buenas prácticas de Python / HTML, debe hacerse en un commit separado específico para eso. Siempre y cuando no haya nadie más tocando ese código. Asegurándose antes, se puede incluso actualizar directamente en develop.

## Commits atómicos y explicativos La misma historia de siempre. Hay que procurar hacer los commits lo más atómicos posible. Un commit no significa que tenga que estar el código estable, sólo que se ha hecho "algo concreto".

A la hora de revisar e integrar cambios, me es mucho más fácil si cada commit registra cambios sobre cosas concretas, y si en el mensaje de commit se explica bien qué se ha hecho. En muchas integraciones y resoluciones de conflictos lo he echado muy en falta.