El lanzamiento de los pull requests apilados en GitHub ha reavivado un debate clásico entre desarrolladores: ¿conviene reescribir el historial de Git para mantenerlo limpio o se debe aceptar tal como surge del trabajo cotidiano? Existen dos perfiles opuestos. Los 'commit-often' hacen commits frecuentes sin demasiada planificación y defienden que un historial detallado refleja fielmente cómo ocurrió el desarrollo. Los 'rebase' reescriben y reorganizan los commits para construir un historial cuidado que preserve la intención detrás de cada cambio.
La nueva función de GitHub agrada sobre todo a los primeros, porque encaja con su forma de trabajar: pequeñas modificaciones encadenadas sobre las que se construyen pull requests adicionales. Steve Klabnik, ingeniero conocido en la comunidad de Rust, calificó la novedad como uno de los cambios más importantes de GitHub en años. En cambio, los 'rebase' se muestran escépticos ante la utilidad de apilar solicitudes.
El mismo choque se reproduce al fusionar cambios en la rama principal. Los defensores del rebase prefieren los merge commits para no perder el trabajo de reorganización; quienes commiten a menudo prefieren el squash, ya que produce un main más legible. Quien escribe, partidario del rebase, reconoce que mantener un historial ordenado exige disciplina difícil de sostener en equipos grandes. Aplicando la teoría de las ventanas rotas, concluye que la opción más resiliente es aceptar el historial desordenado cuando no se tiene autoridad sobre el repositorio.