Usando git-svn: Pull, Merge or Rebase?

Question

He estado luchando contra la curva de aprendizaje de git/git-svn y anoche, como parte de esa curva de aprendizaje, hice algo muy, muy malo. Desde entonces lo he corregido, pero espero entender el error a mi manera.

Tengo un repositorio svn del que he clonado el tronco y las ramas (etiquetas que ignoré porque no trabajamos en ellas). El uso de git, creé ramas locales para cada una de las ramas que actualmente necesidad de trabajar con:

$ git checkout -b trunk svn/trunk 
$ git checkout -b feature1 svn/branches/development/feature1 
$ git checkout -b maint svn/branches/maintenance/previous-version 

hice feature1 mi rama activa e hice algunos cambios antes de dejarnos llevar por unos días. Volví a la pantalla ayer y quería integrar todos los cambios que se habían realizado en el maletero para poder trabajar con lo último y lo mejor. Lo que hice fue una actualización completa de todas las marcas primero, a través de git svn rebase (nadie más había trabajado en la rama feature1). Con todo actualizado desde mi repositorio svn, traté de volver a establecer la base.

Con feature1 como mi rama activa, hice un "git rebase trunk" pensando que estaría realizando cambios desde el tronco en la rama feature1. Resulta que estaba muy, muy mal. Después de fusionar todos los conflictos, hice git svn dcommit y encontré que mis cambios se habían aplicado al tronco.

Mi primera pregunta es simplemente ¿dónde estaba el error central en mi proceso de pensamiento? El segundo es que, después de leer mucho y buscar en Google, veo gente que defiende tirones, fusiones y rebases. Dado el hecho de que quiero fusionar los cambios aplicados en una rama local a otra rama local, ¿qué debería haber hecho? ¿Cuál es la mejor práctica para este escenario?

Gracias por su ayuda.

Answer 1

El problema con el que se encontró es que la sintaxis de línea de comando para rebase no coincide con sus expectativas (muy razonable, IMO).

$ git checkout feature1 
$ git rebase trunk 

Esta secuencia se suma el feature1 no compartido se compromete en la cabeza del tronco, y que se esperaba que iba a colocar el nuevo tronco se compromete a la cabeza de feature1. La sintaxis en realidad tiene sentido cuando sabes cómo se implementa el modelo de datos de Git (que sin duda es la razón por la cual es así). Pero para mí es lo contrario de lo que espero, funcionalmente. Lo mejor es aprenderlo como una construcción arbitraria y no tratar de tener expectativas.

Tienes razón en que entiendes cómo interactuar con el repositorio SVN usando git-svn. Así que ignora lo que encontraste en Google sobre empujar y tirar y fusionar: hay mucha discusión casi correcta por parte de personas que actúan como si empujar y tirar y fusionar son lo mismo en git y svn. Casi a la derecha todavía está mal.

Answer 2

Debe usar git svn clone -s para clonar el árbol svn completo, incluidas todas las ramas. A partir de entonces, use git svn rebasey git svn dcommit en master para manejar svn, y puede crear git branches para su uso privado.