Tengo una serie de parches comprometidos localmente en mi repo de git-svn que todavía no he comprometido con nuestro repositorio svn. Un "git svn dcommit" normal enviará todos estos parches a svn. Me gustaría comprometer solo algunos de mis parches (correcciones de errores simples), pero no otros (cambios importantes no probados). ¿Cómo puedo hacer esto con git svn?¿Cómo comprometer solo parches seleccionados con git svn?
Esto es lo que terminé haciendo. El punto de partida es la rama "principal" sincronizada con svn, con todos mis parches locales en la parte superior.
Cree una nueva rama (wip = Work In Progress).
git branch wip
Esto hace una copia de la rama actual, incluidos todos los parches que aún no están comprometidos con svn. La rama actual permanecerá como "maestra" y no se cambiará.
Retire los parches locales no deseados de "maestro" con un rebase:
git rebase -i HEAD~10
Ahora la rama "master" tiene parches puede comprometerse con seguridad:
git svn dcommit
El "trabajo en curso" la sucursal ahora tiene los cambios principales que aún no están listos para compartir. En realidad, quiero que se queden allí y aquí es donde detendría. Es posible hacer el svn dcommit desde la rama "wip" una vez que todo está finalizado. Pero por el bien completess', y para responder a la pregunta original, hay un paso final:
Tire los cambios no confirmados de nuevo a la rama 'master' usando git cherry-pick y finalmente eliminar la rama inútil con git branch -d wip.
Con git, en realidad no se supone que opere en conjuntos de cambios individuales. El mejor enfoque que conozco es crear sucursales locales para cualquier trabajo no trivial. De esta forma, tus principales cambios no probados terminarán en diferentes ramas de tu repositorio de git, y podrás diferenciarlos bastante fácilmente.
Si este es el problema que tiene en este momento, probablemente pueda crear crear una nueva rama desde el último punto que actualizó desde svn y luego usar git-cherry-pick para transferir sus correcciones de errores a esta nueva rama, desde la cual puede comprometerse con svn.
Desde una perspectiva más a largo plazo de vista lo mejor es tener su propia rama "master" hecha de tronco de la subversión, y luego o bien:
git diff ..my_branch | patch -p1, lo que eliminará el historial que git-svn no puede manejar. Este enfoque es más complicado para la fusión final, pero le permite fusionar cosas entre sucursales (y posiblemente otras personas) en git.He estado siguiendo el procedimiento aquí:
http://fredericiana.com/2009/12/31/partial-svn-dcommit-with-git/
Si estás cómodo cambio de base, funciona bastante bien.
El último paso aquí es "git pull. Wip" que simplemente saca todos los cambios de la rama wip, para satisfacer la pregunta original, se necesitaría el uso de git-cherry-pick. –
Mark, gracias por señalar eso; He editado la publicación para usar cherry-pick en su lugar. El uso de "git pull. Wip" seguido de "git svn rebase" generalmente resolverá automáticamente los conflictos, pero es mejor usar cherry-pick. –