Siempre ignora un cierto compromiso en la fusión en git

Estoy trabajando en mi primer proyecto usando git y me encontré con un problema.

El repository contiene una aplicación cliente / server. Tengo una twig 'maestra' y 'testing', con la intención de que el maestro sea siempre el mismo que el que se implementó.

Mi problema es que hay 3-4 lugares en la base de código donde se almacena la URL del server. Quiero cambiar esto en la twig 'testing', pero no en la twig 'principal'. El problema es, por supuesto, que cada vez que quiero fusionar de nuevo a 'maestro', git quiere poner este cambio en 'maestro'.

Puedo hacer una fusión selectiva y fusionar todas las confirmaciones pero la que está en cuestión, pero esto parece tedioso para cada combinación. ¿Cuál es la mejor manera de hacer esto?

Nunca he tenido este problema en ningún SCM, así que tal vez estoy haciendo todo mal.

Desea fusionarse en ese cambio como no realmente fusionado, pero márquelo así en la historia. De esta forma sabrá dónde get los cambios posteriores.

Hay un par de maneras de hacer esto. Uno es

git checkout master git merge -s ours --no-ff testing git checkout testing git merge -s ours --no-ff master 

o

 git checkout master git merge testing --no-commit --no-ff git checkout HEAD -- . git submodule update # this is optional and only needed if you have submodules git add -A git commit git checkout testing git merge master --no-commit --no-ff git checkout HEAD -- . git submodule update # this is optional and only needed if you have submodules git add -A git commmit 

Ahora tiene 2 twigs con configuraciones diferentes, pero esas confirmaciones están antes de la merge-base importante.

Ahora necesita hacer un script de algo como esto para hacer la combinación especial, que en realidad es una rebase debajo: esa es la única manera de ignorar lo que sucedió antes:

 git checkout master git merge --no-ff -s ours testing git checkout -b temp testing git rebase -s recursive -Xtheirs master # these are the conflicts we care about git reset --soft HEAD@{2} git add -A git submodule update git commit --amend -C HEAD@{2} git push . +HEAD:master git checkout master git branch -d temp 

Esto simplemente rebases lo que no tienes en master en las testings de twig y lo hace parecer como una fusión. Debido a que lo almacena como una fusión, puede ejecutarlo posteriormente contra otras twigs que desea publicar en el maestro. Por lo tanto, podría separar todos los commands con && s, replace la testing con un argumento, maestro con las variables del segundo argumento y alias:

 git config alias.smart-merge '...' 

para que pueda publicar cambios como ese:

 git smart-merge testing master git smart-merge feature2 master 

lo cual debería proporcionarle tanto testings como feature2 sin importar en qué punto esos 2 ya se hayan fusionado en la historia.

También considere habilitar la repetición ya que el script no espera conflictos. Entonces, si desea publicar, puede hacer una rebase regular primero, registrando resoluciones de conflictos. Ahora puede modificar el guión para aprovecharlo y no romper conflictos.

La resolución de conflictos de la base puede ser un dolor. Pero no en este caso, ya que solo usamos master para publicar. La manipulación de otras twigs todavía se realiza a través de una combinación regular o rebase.

– O –

Los scripts no triviales son borrones de limpieza. Eche un vistazo al capítulo de attributes de git en progit.org/book.

Espero que esto haya ayudado.

git cherry-pick te permite hacer eso (aunque deberás seleccionar los commits para fusionar (y asegúrate de no olvidar ninguno)

Otra forma es que puede git revert atrás la (s) confirmación (es) que cambiaron la URL, fusionarse con la maestra y luego volver a colocarla en su twig principal.

Una vez más, otra forma es hacer git commit --no-commit , luego cambiar el file, git add it before commit.

Otro método que quizás evite "olvidar" es tener este tipo de configuration (las URL y demás) en un file separado y agregar ese file al .gitignore …

No creo que ninguno de ellos sea realmente elegante, pero funcionaría …