¿Cuál es la mejor manera de transferir una twig de característica de debugging GIT-SVN a trunk?

Tengo una configuration de troncales donde va mi código de producción.

Luego, tengo una twig de debug (parent es trunk ) a la que agrego código de debugging, como logging, var dumps, etc … esto nunca debería estar en producción. Esta twig rara vez cambia.

Por último, tengo una twig de feature (parent es la debug ) donde hago toda mi encoding con los beneficios de la debugging. Hay compromisos constantes en esta twig.

Solo quiero saber si hay una forma más fácil de mover mi código de feature al trunk . Esto es lo que hago actualmente:

  1. Confirmar todos los cambios en mi twig de feature
  2. Cambia a master y git svn rebase changes from other devs.
  3. rebase mi twig de feature en la twig master ( git rebase --onto master debug feature )
  4. merge característica para master
  5. git svn dcommit cambia a otros desarrolladores
  6. rebase debug a master ( git rebase master debug )
  7. eliminar la twig de feature
  8. crear una nueva feature desde la twig de debug .

Yo diría que su flujo de trabajo es bastante óptimo. Considero que seleccionar cereza es una exageración (pero depende del número de confirmaciones).

Lo que podrías hacer es aplastar todos los commits en uno y cherry-pick / rebase solo este.

Y, por cierto, ¿por qué no escribes un script simple si es algo que haces todo el time? Git es una herramienta de bajo nivel, por lo que escribir guiones adicionales para ayudar con tareas repetitivas es una muy buena idea.

Ok, diré una herejía y todos me votarán, pero vámonos. Si utilizó svn directamente, su flujo de trabajo sería mucho más simple.

Con la function –reintegrate de subversión , es fácil mantener su troncal y la twig de debugging sincronizadas. Para fusionar su twig de características, fusionaría todas las modificaciones de la twig de características en el tronco. Los commands serían algo así como:

Para combinar el tronco para depurar:

 cd debug_branch_workcopy svn merge --reintegrate http://server/project/trunk . svn commit 

Para fusionar la twig de características a troncal:

 svn log --stop-on-copy http://server/project/branches/feature123 #see the last revision listed cd trunk_workcopy svn merge -r{revision_above}:HEAD http://server/project/branches/feature123 . svn commit 

Puede ejecutar el último command de fusión varias veces si cambia la twig después de la fusión. Subversion recordará las revisiones ya fusionadas y no intentará hacerlas dos veces. Si estás en Windows, el TortoiseSVN gratuito te dará una interfaz de combinación agradable.

Por cierto, trataría de no tener una twig separada solo con funciones de debugging. Es demasiado fácil cometer un error manual y enviar código de debugging a su troncal de producción. Usaría algo más dynamic para no ejecutar el código de debugging mientras esté en producción.

Si lo entiendo correctamente, le gustaría tener sus características de debugging solo en su twig de debugging (bastante estática), pero no en su twig principal. Prueba esto:

Hacer una "combinación falsa" de debugging en el maestro

 git checkout master git merge --no-commit debug git checkout master . # undo all changes, get the files from master again git add . # stage all files git commit 

De esta forma, la debugging se combinará en el maestro, pero ninguno de sus files en el maestro habrá cambiado.

Ahora puede simplemente crear sus twigs de características sobre la debugging y fusionarlas en maestra cuando haya terminado. Git ahora sabe que las funciones de debugging se eliminan del maestro:

 git checkout debug git checkout -b new_feature # create a new feature branch # hack, hack, hack git commit git checkout master # All works fine... git merge new_feature # ...so merge into master. Debug code will be stripped here 

Puede avanzar rápidamente la twig de debugging en new_feature y eliminar la twig new_feature después de esto.

Tenga en count que siempre que cambie la twig de debugging, debe volver a realizar el procedimiento de fusión falsa.

Tenemos una sucursal por cada function o corrección de errores que hacemos. Estos pueden fusionarse nuevamente al tronco cuando se hayan probado suficientemente.

Las twigs se pueden actualizar si se vuelven un poco viejas.

Tendemos a liberar cambios menores directamente en el tronco, pero para cambios más importantes los reunimos en una twig candidata de lanzamiento en la que fusionamos todas las twigs relevantes que contienen cambios para que entren en funcionamiento. Esta nueva twig se puede implementar y probar para ver si la combinación de cambios rompe cualquier cosa, antes de que finalmente se fusione de nuevo al tronco y entre en producción.

Este método crea muchas twigs, pero dado que nombramos esto relacionado con nuestro sistema de seguimiento de problemas, es fácil seguirlo. Es agradable y fácil de include o excluir cualquier cambio en un lanzamiento.

Espero que ayude

Creo que lo que estás buscando es git-cherry-pick. Esto le permite aplicar commits desde la function en master sin realizar la danza de rebase que describe.

Como vas a eliminar la twig de características de todos modos, no es necesario que veas una fusión explícita, supongo.

Su flujo de trabajo es complicado porque lo que está tratando de hacer es complicado. Ningún VCS que conozco te permite mantener fácilmente algunos cambios que nunca deberían fusionarse. Dice mucho sobre el poder de git que su flujo de trabajo no es más difícil de lo que es.

Supongo que su idioma tiene algún tipo de mecanismo de compilation condicional (directivas de preprocesador #IFDEF , etc.). Si ajusta su código de debugging en estos, experimentará mucha less fricción.