2010-05-07 15 views
13

Tengo un repositorio donde 'master' va en una cierta dirección, y una segunda 'foo' de rama va a ser divergente por un par de confirmaciones, luego sigue todos los cambios posteriores a 'master' después de eso. Esto es todo por elección, por supuesto.Subversion tiene --record-only for merges, ¿cómo hago lo mismo en Git?

En Subversion puede hacer una fusión de solo registro para marcar cosas como "se ha producido la fusión" aunque no se hayan confirmado cambios. es decir, esto cambia los números de seguimiento de fusión en propiedades asociadas a directorios en la rama de destino.

he tenido un juego con ..

git combinación maestra --no-commit

.. como algo que puede ser capaz de jugar con antes de que yo la entrego, pero está haciendo una gran confusión en la rama de destino por parte del cambio en cuestión (cambio de nombre seguido de eliminación).

Debe haber una manera más fácil ..?

  • Paul

Respuesta

12

Es esto lo que está buscando?

git merge --strategy=ours master 

nuestro

esto resuelve cualquier número de cabezas, pero el árbol resultante de la fusión es siempre el de la cabeza rama actual, haciendo caso omiso de manera efectiva todos los cambios con respecto a todas las demás ramas. Está destinado a ser utilizado para reemplazar el historial de desarrollo anterior de las ramas laterales.

Esto parece ser lo que estás pidiendo: crea una confirmación de fusión que en realidad no introduce ningún cambio.

¿Pero de verdad quieres hacer esto? ¿Hay alguna razón por la que no puedas simplemente dividir las ramas (sin que se produzca una fusión) y luego fusionarte más tarde?

+2

P.S. Juro que esta es la tercera vez que menciono '--trategia = nuestra' en la última semana. Me pregunto por qué todos de repente necesitan descartar la historia ... – Cascabel

+0

Estoy cambiando un archivo de configuración de base de datos en la rama, justo después del punto de bifurcación, y no deseo fusionar esto de nuevo a maestro. Sin embargo, correcciones de errores posteriores en la rama, quiero fusionar de nuevo a maestro. Esto permitirá que, sin seleccionar de manera inteligente, el arreglo se comprometa individualmente. –

+0

Mientras hacía lo anterior, se me ocurrió que esta información de base de datos realmente pertenece a las variables de entorno, como en la aplicación Twelve-Factor. –

0

Paul, git maneja el cambio de nombre seguido de eliminar con (relativo a svn) la facilidad. Se rastrea el contenido, no el nombre de archivo. En svn esto sería doloroso, ¿qué problemas estás experimentando con git mientras haces esto?

0

jefromi lo clavó. Aquí está lo real: http://github.com/jbehave/jbehave-core/blob/master/examples/trader/src/main/java/org/jbehave/examples/trader/TraderStory.java (juegue con las ramas del interruptor y mire la línea 65).

Esto no se trata tanto de 'tirar la historia', sino más de usar Git para hacer malabares con los cambios divergentes desde una única base. Para hacer que la gente adopte JBehave (IMO) necesitamos hacer ejemplos realmente fáciles de seguir. Antes de este ejemplo 'Trader', JBehave vainilla + una variante de Guice + una variante SpringFramework + una variante de PicoContainer, todo en el mismo directorio de origen. Ahora, cuatro ramas pueden ilustrar la mayoría de las representaciones canónicas del ejemplo de 'Comerciante'.

+0

Lo siento pero el enlace está roto –

Cuestiones relacionadas