Puede fusionar su rama ascendente a su devrama, con un controlador de fusión personalizado "keepTheirs" :
consulte " " git merge -s theirs"necesario, pero sé que no existe ".
En su caso, solo .gitattributesse requeriría uno y un keepTheirsscript como:
mv -f $3 $2
exit 0
git merge --strategy=theirs Simulación # 1
Se muestra como una combinación, con upstream como primer padre.
Jefromi menciona (en los comentarios) el merge -s ours, fusionando su trabajo en el flujo ascendente (o en una rama temporal comenzando desde el flujo ascendente), y luego adelantando su rama al resultado de esa fusión:
git checkout -b tmp origin/upstream
git merge -s ours downstream # ignoring all changes from downstream
git checkout downstream
git merge tmp # fast-forward to tmp HEAD
git branch -D tmp # deleting tmp
Esto tiene la ventaja de registrar el ancestro ascendente como el primer padre, de modo que la combinación significa "absorber esta rama de tema desactualizada" en lugar de "destruir esta rama de tema y reemplazarla por ascendente" .
(Editar 2011):
Este flujo de trabajo ha sido informado en esta publicación de blog por el OP :
¿Por qué quiero esto de nuevo?
Siempre que mi repositorio no tuviera nada que ver con la versión pública, todo estaba bien, pero como ahora me gustaría tener la capacidad de colaborar en WIP con otros miembros del equipo y colaboradores externos, quiero asegurarme de que mis ramas públicas estén confiable para que otros se bifurquen y tomen, es decir, no más rebase y reinicio en las cosas que he enviado a la copia de seguridad remota, ya que ahora está en GitHub y es público.
Entonces eso me deja con cómo debo proceder.
El 99% de las veces mi copia irá al maestro ascendente, por lo que quiero trabajar con mi maestro y empujar hacia el flujo ascendente la mayor parte del tiempo.
Pero de vez en cuando, lo que tengo dentro wipserá invalidado por lo que va río arriba y abandonaré una parte de mi wip.
En ese momento, quiero que mi maestro vuelva a sincronizarse con el flujo ascendente, pero no destruir ningún punto de compromiso en mi maestro enviado públicamente. Es decir, quiero una fusión con el flujo ascendente que termina con el conjunto de cambios que hace que mi copia sea idéntica al flujo ascendente .
Y eso es lo que git merge --strategy=theirsdebería hacer.
git merge --strategy=theirs Simulación # 2
Se muestra como una fusión, con el nuestro como primer padre.
(propuesto por jcwenger )
git checkout -b tmp upstream
git merge -s ours thebranch # ignoring all changes from downstream
git checkout downstream
git merge --squash tmp # apply changes from tmp but not as merge.
git rev-parse upstream > .git/MERGE_HEAD #record upstream 2nd merge head
git commit -m "rebaselined thebranch from upstream" # make the commit.
git branch -D tmp # deleting tmp
git merge --strategy=theirs Simulación # 3
Esta publicación de blog menciona :
git merge -s ours ref-to-be-merged
git diff --binary ref-to-be-merged | git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend
a veces quieres hacer esto, y no porque tengas "basura" en tu historial, sino quizás porque quieres cambiar la línea de base para el desarrollo en un repositorio público donde se debe evitar la reorganización .
git merge --strategy=theirs Simulación # 4
(misma publicación de blog)
Alternativamente, si desea mantener las sucursales ascendentes locales con reenvío rápido, un compromiso potencial es trabajar con el entendimiento de que para sid / inestable, la sucursal ascendente se puede restablecer / reajustar de vez en cuando (según los eventos que finalmente están fuera de su control en el lado del proyecto aguas arriba).
Esto no es un gran problema y trabajar con esa suposición significa que es fácil mantener la rama ascendente local en un estado en el que solo necesita actualizaciones rápidas.
git branch -m upstream-unstable upstream-unstable-save
git branch upstream-unstable upstream-remote/master
git merge -s ours upstream-unstable
git diff --binary ref-to-be-merged | git apply -R --index --exclude="debian/*"
git commit -F .git/COMMIT_EDITMSG --amend
git merge --strategy=theirs Simulación # 5
(propuesto por Barak A. Pearlmutter ):
git checkout MINE
git merge --no-commit -s ours HERS
git rm -rf .
git checkout HERS -- .
git checkout MINE -- debian # or whatever, as appropriate
git gui # edit commit message & click commit button
git merge --strategy=theirs Simulación # 6
(propuesto por el mismo Michael Gebetsroither ):
Michael Gebetsroither intervino, alegando que estaba "haciendo trampa";) y dio otra solución con comandos de plomería de nivel inferior:
(No sería git si no fuera posible con comandos de solo git, todo en git con diff / patch / apply no es una solución real;).
# get the contents of another branch
git read-tree -u --reset <ID>
# selectivly merge subdirectories
# e.g superseed upstream source with that from another branch
git merge -s ours --no-commit other_upstream
git read-tree --reset -u other_upstream # or use --prefix=foo/
git checkout HEAD -- debian/
git checkout HEAD -- .gitignore
git commit -m 'superseed upstream source' -a
git merge --strategy=theirs Simulación # 7
Los pasos necesarios se pueden describir como:
- Reemplace su árbol de trabajo con upstream
- Aplicar los cambios al índice
- Agregar upstream como segundo padre
- Cometer
El comando git read-treesobrescribe el índice con un árbol diferente, logrando el segundo paso , y tiene banderas para actualizar el árbol de trabajo, logrando el primer paso . Al confirmar, git usa SHA1 en .git / MERGE_HEAD como segundo padre, por lo que podemos completar esto para crear una combinación de confirmación. Por lo tanto, esto se puede lograr con:
git read-tree -u --reset upstream # update files and stage changes
git rev-parse upstream > .git/MERGE_HEAD # setup merge commit
git commit -m "Merge branch 'upstream' into mine" # commit