Cómo rastrear pequeños cambios en una gran base de código mantenida externamente

Al trabajar con algunos proyectos de código abierto (en mi caso, Joomla y Moodle), a menudo tuve que profundizar en el código central para hacer algunas modificaciones, pero el problema es hacer un seguimiento de estos cambios para saber qué files actualizar en el server de producción, así como los files a los que debe prestar especial atención cuando actualice a una nueva versión para que mis cambios no se sobrescriban.

La respuesta obvia es cargar toda la base de código en el control de versiones, y luego puede comparar fácilmente la revisión 0 (el código de versión intacto) con la versión actual o copy de trabajo para encontrar los files modificados, pero parece un poco exagerado cuando Solo está cambiando uno o dos files y el proyecto tiene más de 5000 files (como Moodle).

En un extremo del espectro hay un repository de control de versiones, y el otro está usando el bloc de notas para seguir manualmente los cambios … ¿hay algo intermedio?

No estoy seguro de por qué eres resistente al control de versiones; ¡su situación es exactamente lo que el control de versión está diseñado para manejar!

De hecho, el caso de varios pequeños cambios locales en una gran base de código impulsada externamente hace que sea aún más importante usar un control de fuente adecuado. El uso de un sistema de control de fuente que tenga un motor inteligente de fusión y diferenciación asegura que los cambios simples se combinen fácilmente cuando se realiza la actualización desde la etapa ascendente, y que los cambios complejos tienen la posibilidad de ser rastreados.

Dada la amplia disponibilidad de sistemas de control de fuente de alta calidad y de costo cero, realmente no hay razón para no usarlos.

En definitiva, parece que lo que has hecho es que has bifurcado el código. ¿Esa era realmente tu intención? Obtenga sus cambios fusionados en la fuente original, y luego no tiene que continuar haciendo esos cambios para futuras actualizaciones.

Si los cambios son inapropiados para cualquier otro consumidor del proyecto, entonces quizás podría introducir cambios que permitan que sus personalizaciones se carguen más tarde. Es decir, incluso si sus cambios específicos no son para todos, pero las secciones de código que modifica podrían ser secciones que otros quisieran personalizar también para sus instalaciones. Agregue una function al progtwig que cargará las personalizaciones desde un file separado. Entonces, el código ya no necesita cambiar y puede actualizar su file de configuration sin tener que rastrear sus cambios en relación con el código externo.