Git Things

Revisión de código y flujo de trabajo

• Algunos equipos adoptan estilos de “ship/show/ask” en los que el autor elige cuánta revisión se necesita, lo que permite fusiones rápidas para cambios pequeños y de bajo riesgo.
• Otros sostienen que la elección del revisor debería depender más de quién entiende el código afectado, no solo de la confianza del autor.
• Una propuesta de “fusionar optimistamente” a main y revisar después recibe críticas: quienes la cuestionan dicen que degrada la fiabilidad de main, elimina la presión social para revisar y priva a los juniors de aprender mediante comentarios antes de la fusión.
• La documentación y las pruebas suelen atascar los PR; entre las sugerencias están tratar la documentación como algo de primera clase (un PR no es aceptable sin ella), escribir la documentación primero para aclarar la intención, o que los revisores redacten la documentación inicial para sacar a la luz las lagunas.

Mensajes de commit e historial

• Hay un fuerte desacuerdo sobre mensajes del estilo “minor”/“fix”: algunos creen que son aceptables para cambios diminutos; otros insisten en que cada commit debe expresar intención, especialmente para depurar con blame/bisect.
• Muchos quieren al menos contexto de alto nivel en el asunto (“qué”), a veces con un ID de ticket; otros argumentan que lo mínimo debería ser “por qué”, ya que el diff ya muestra el “qué.”
• La guía de 50 caracteres para el asunto se debate: algunos la ven como arcaica y derivada de terminales antiguas; otros defienden asuntos cortos para poder escanearlos mejor en herramientas como log y blame. Las herramientas que hacen cumplir 50 caracteres se consideran irritantes.
• Reagrupar versus preservar commits granulares: algunos prefieren reagrupar para limpiar el historial; otros sostienen que se puede simular una “vista agrupada” con --first-parent y que reagrupar destruye historial útil.

Pruebas, pruebas fallidas y bisect

• El consejo de commitear primero una prueba que falla y luego la corrección es elogiado como TDD de baja fricción y útil para la revisión.
• Los críticos señalan que puede romper git bisect y las expectativas de CI si las pruebas fallidas llegan a main.
• Una sugerencia relacionada de ajustar aserciones para fijar el comportamiento incorrecto actual (con TODO) es ampliamente criticada; varios sostienen que las pruebas nunca deben imponer un comportamiento incorrecto y que en su lugar deberían marcarse como expected-fail o eliminarse.

Renombres y seguimiento del historial

• Algunos ven la detección de renombres basada en contenido de Git como un fallo; quieren metadatos explícitos de movimiento (git mv registrado de forma robusta).
• Otros defienden el modelo actual, señalando que permite seguir el historial a través de divisiones/fusiones de archivos y movimientos de grano fino, aunque de forma imperfecta; opciones como git blame -C pueden ayudar.
• Las propuestas para añadir metadatos explícitos de movimiento generan preocupaciones sobre complejidad, compatibilidad de herramientas y conflictos de fusión.

Longitud de línea y convenciones de herramientas

• Los límites de línea/asunto (80–120 para código, ~50–72 para asuntos de commit) se discuten como una mezcla de artefacto histórico y legibilidad práctica: diffs lado a lado, portátiles pequeños, ojos cansados.
• Algunos abogan por límites más relajados o por no imponer límites duros y dejar que las herramientas envuelvan el texto; otros subrayan que las líneas más cortas son más fáciles de leer y que un límite suave también revela expresiones demasiado complejas.

Ramificación: merge vs rebase

• Merge y rebase se consideran herramientas distintas: rebase para ramas de características compartidas y reescrituras del historial; merge para integrar trabajo y preservar commits originales.
• Algunos prefieren los merge commits como lugares explícitos donde vive la resolución de conflictos; otros hacen rebase para evitar merge commits “llenos de dragones” y mantener main lineal para CI/bisect.