¿Cuál es la mejor manera de transferir una rama de función de depuración GIT-SVN al tronco?

Question

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

Luego tengo una rama debug (principal es trunk) que agrego código de depuración como el registro, volcados de var, etc ... esto nunca debería estar en producción. Esta rama rara vez cambia.

Por último tengo una rama feature (principal es debug) donde hago toda mi codificación con los beneficios de la depuración. Hay compromisos constantes en esta rama.

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

1. confirmar todos los cambios a mi feature rama
2. Cambiar a master y git svn rebase cambios de otros desarrolladores.
3. rebase mi feature rama en la rama master (git rebase --onto master debug feature)
4. merge función a master
5. git svn dcommit cambios a otros desarrolladores
6. rebasedebug a master (git rebase master debug)
7. eliminar feature rama
8. crear una nuevo feature del debug rama.

Answer 1

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 puedes 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 tiempo? Git es una herramienta de bajo nivel, por lo que escribir guiones adicionales para ayudar con tareas repetitivas es una muy buena idea.

Answer 2

Tenemos una rama separada para cada función o corrección de errores que hacemos. Estos pueden fusionarse nuevamente al tronco cuando se hayan probado suficientemente.

Las ramas 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 rama candidata de lanzamiento en la que fusionamos todas las ramas relevantes que contienen cambios para que entren en funcionamiento. Esta nueva rama 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 ramas, pero desde que las nombramos relacionadas con nuestro sistema de seguimiento de problemas, son fáciles de seguir. Es agradable y fácil de incluir o excluir cualquier cambio en un lanzamiento.

Espero que ayude

Answer 3

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

Dado que va a eliminar la rama de características de todos modos, no es necesario que vea una fusión explícita, supongo.

Answer 4

Ok, voy a decir una herejía y todo el mundo va a votar por mí, pero vamos. Si utilizó svn directamente, su flujo de trabajo sería mucho más simple.

Con el --reintegrate feature of subversion es fácil mantener su troncal y la rama de depuración sincronizadas. Para fusionar su rama de características, fusionaría todas las modificaciones de la rama de características en el tronco. Los comandos serían algo así como:

Para fusionar el tronco de depurar:

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

fusionar la rama de la característica de que el tronco:

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 comando Combinar varias veces si cambias la rama 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 rama separada solo con funciones de depuración. Es demasiado fácil cometer un error manual y enviar código de depuración a su troncal de producción. Usaría algo más dinámico para no ejecutar el código de depuración mientras esté en producción.

Answer 5

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 lenguaje tiene algún tipo de mecanismo de compilación condicional (#IFDEF directivas de preprocesador, etc.). Si ajusta su código de depuración en estos, experimentará mucha menos fricción.

Answer 6

Si le entiendo correctamente, le gustaría tener sus funciones de depuración solo en su rama de depuración (bastante estática), pero no en su rama principal. Prueba esto:

hacer un "merge falso" de depuración en 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 manera, depuración se fusionará con maestría, pero ninguno de sus archivos en maestro habrá cambiado.

Ahora puede simplemente crear sus ramas de características sobre la depuración, y combinarlas en el maestro cuando haya terminado. Git ahora sabe que las características de depuración son despojados de 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 rama de depuración en new_feature y eliminar la rama new_feature después de esto.

Tenga en cuenta que siempre que cambie la rama de depuración, debe volver a realizar el procedimiento de fusión falsa.