heads - git-svn download
Usando git-svn: Pull, Merge o Rebase? (2)
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 de svn desde el cual he clonado el tronco y las ramas (etiquetas que ignoré porque no trabajamos en ellas). Usando git, creé sucursales locales para cada una de las sucursales con las que necesito trabajar actualmente:
$ 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 retirarme por unos días. Volví a verlo ayer. Quería integrar cualquier cambio que se hubiera hecho en el maletero para que estuviera trabajando con lo último y lo mejor. Lo que hice fue una actualización completa de todas las sucursales primero, a través de git svn rebase (nadie más había trabajado en la rama feature1). Con todo actualizado desde mi repositorio de svn, traté de cambiar de base.
Con feature1 como mi rama activa, hice un "troncal gase rebase" pensando que estaría tirando de los cambios del tronco a la rama feature1. Resulta que estaba muy, muy mal. Después de fusionar todos los conflictos, hice un git svn dcommit y encontré que mis cambios se habían aplicado al tronco.
Mi primera pregunta es simplemente ¿dónde estaba el error principal en mi proceso de pensamiento? El segundo es que, después de mucho leer y buscar en Google, veo a personas que defienden los tirones, las fusiones y las rebases. Dado que quiero fusionar los cambios aplicados en una sucursal local a otra local, ¿qué debería haber hecho? ¿Cuál es la mejor práctica para este escenario?
Gracias por tu ayuda.
Debe usar git svn clone -s para clonar el árbol svn completo, incluidas todas las ramas. A partir de ese momento, utilice git svn rebase y git svn dcommit en master para tratar con svn, y podrá crear sucursales de git normales para su uso privado.
El problema con el que se encontró es que la sintaxis de la línea de comandos para el reajuste no coincide con sus expectativas (muy razonables, OMI).
$ git checkout feature1
$ git rebase trunk
Esta secuencia agrega las confirmaciones de característica 1 no compartidas en la CABEZA de troncal, y usted esperaba que colocaría las nuevas confirmaciones de troncal en la CABEZA de característica1. La sintaxis realmente tiene sentido cuando se sabe cómo se implementa el modelo de datos de Git (que es sin duda la razón por la que es). Pero para mí es lo opuesto a lo que espero, funcionalmente. Es mejor aprenderlo como una construcción arbitraria y no tratar de tener expectativas.
Tienes razón al entender cómo interactuar con el repositorio SVN usando git-svn. Así que ignora lo que encontraste en Google sobre empujar y jalar y fusionar: hay mucha discusión casi correcta por parte de personas que actúan como si empujar y jalar y fusionar fueran lo mismo en git y svn. Casi lo correcto sigue siendo incorrecto.