git merge vs rebase usando git svn

Question

Estoy muy confundido, he leído varias publicaciones, blogs y artículos y no sé a dónde ir. Estoy usando un repositorio de servidor svn que selecciono con git svn y trabajo. Actualmente soy la única persona que desarrolla esto (es decir, no hay cambios en la cadena ascendente).

Así que tengo una rama de tema de git local vacation, que necesito fusionar de nuevo en master para realizar, pero no quiero aplastar todas las confirmaciones en una gran.

Intenté hacer un git rebase -i master y borró el 90% de mis cambios.

Qué hago un

git checkout master 
git rebase vacation 
git svn docmmit 

O un

git checkout vacation 
git rebase master 
git checkout master 
git merge vacation --ff-only 
git svn docmmit? 

Tengo miedo de que b/c lo que ocurrió cuando he intentado antes por favor alguien puede explicar brevemente lo que debería hacer y ¿Por qué tengo que hacerlo de esa manera?

Answer 1

así que creo que lo descubrí.

git checkout vacation 
git rebase master 
[ masters's chages put behind this branches, replay every commit ] 
git checkout master 
git merge --ff-only vacation 
git svn dcommit 
[ each change goes into svn as seperate commit ] 

No tuve cambios en la cadena ascendente, pero esto era exactamente lo que quería.

Answer 2

Debe fusionar o seleccionar con precisión el maestro, no la rebase.

En cuanto a por qué, es una cuestión de ordenar. Rebase implica que quiere alterar el historial para hacer que su rama de tema aparezca antes que el maestro en el historial. Si fusionas o seleccionas los commits, agregará tus commits encima de master.

Así que un ciclo completo sería algo así como

git checkout -b vacation 
[make changes] 
git commit -a -m "Commit message" 
git checkout master 
git merge vacation 
git svn dcommit 

Para explicar rebase con más detalle un ejemplo de mi configuración personal: Además de dominar También mantengo una obra rama local que utilizo como base para mi configuración local de nuestro proyecto. Tiene cosas como archivos de propiedades personalizadas que no quiero comprometer. Tengo que tener esto en sincronía con la rama principal por lo que este a partir del maestro:

git svn rebase 
git checkout work 
git rebase master 

Ahora Git reconstruye la historia de la rama de trabajo la colocación de toda la configuración local, se compromete a la cabeza de la pila. Literalmente crea de nuevo la rama BASEd en la rama principal. Si tuviera que emitir

git merge master 

en lugar de cambio de base, entonces el resultado a la vista lamen sería la misma, pero la historia sería muy diferente. Las dos historias se resolverían, lo que posiblemente daría lugar a confusiones de fusión, en lugar de una basada en la parte superior de la otra.