stackoverflow - git rebase "eliminado por nosotros" y "eliminado por ellos"

git rebase tutorial

Question

Esta pregunta ya tiene una respuesta aquí:

• ¿Quién es "nosotros" y quién es "ellos" según Git? 1 respuesta

Supongamos que estoy rebasando la rama del experimento en el maestro y hay conflictos en los archivos. Y, por supuesto, hay archivos eliminados en ambas ramas. Entonces, cuando estoy resolviendo los conflictos, en el git status veo que deleted by us y deleted by them . Es muy confuso. ¿Hay alguna forma de entender lo que significan? ¿Quién es ellos y quiénes somos nosotros ?

O bien, mientras se rebasa, ¿hay otra manera de saber qué archivo fue eliminado por qué rama? ¿Te gusta imprimir el nombre de la rama?

Answer 1

Documentación de referencia

Tenga en cuenta que una combinación de rebase funciona al reproducir cada confirmación desde la rama de trabajo en la parte superior de la rama <upstream> . Debido a esto, cuando ocurre un conflicto de combinación, el lado reportado como el nuestro es la serie hasta ahora rebasada, comenzando con <upstream> , y la suya es la rama de trabajo. En otras palabras, los lados se intercambian.

https://git-scm.com/docs/git-rebase/2.17.0 (más reciente: https://git-scm.com/docs/git-rebase )

Por lo tanto, los archivos "eliminados por nosotros" son aquellos que se eliminaron en la rama a la que está rebasando (la rama final), y los archivos "eliminados por ellos" son archivos que fueron eliminados en la rama a la que está rebasando (el que será caído).

Demostración

$ ls
a
$ git log --oneline --graph --decorate --all
* d055cdd (HEAD -> y) Write baz in a-file
| * 487dc8c (x) Write bar in a-file
|/
* 3fa0da5 (master) Write foo in a-file
$ git rebase x
First, rewinding head to replay your work on top of it...
Applying: Write baz in a-file
Using index info to reconstruct a base tree...
M a
Falling back to patching base and 3-way merge...
Auto-merging a
CONFLICT (content): Merge conflict in a
error: Failed to merge in the changes.
Patch failed at 0001 Write baz in a-file
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
$ cat a
<<<<<<< HEAD
bar
=======
baz
>>>>>>> Write baz in a-file
$ git checkout --ours a
$ cat a
bar
$ git checkout --theirs a
$ cat a
baz

AFAIK no hay ningún interruptor para mostrar los nombres específicos de las sucursales explícitamente con las herramientas oficiales. A menos que esté equivocado, esta es solo una de esas cosas que necesita aprender para superar la confusión inicial.

Para su crédito, tiene mucho sentido si lo piensas.

Análisis más pedante.

El texto de la página del manual es un poco ambiguo, ya que podría interpretarse como relevante solo cuando se utiliza la opción --merge . Esto se ve agravado por una segunda mención del comportamiento en --strategy : "Observe la reversión de los nuestros y los suyos como se indicó anteriormente para la opción -m". .

Sin embargo, creo que esto no contrasta el comportamiento de git-rebase cuando --merge se usa con cuando no lo es; más bien creo que está contrastando el comportamiento de git-rebase con git-merge. La sección de ESTRATEGIAS MERGE está claramente arrancada de la página del manual de git-merge, por lo que es un poco fácil imaginar que el autor sintió la necesidad de enfatizar el intercambio cuando se usa rebase, ya que no se menciona en esa sección. La siguiente oración, para mí, confirma esta interpretación: "[...] git rebase reproduce cada confirmación de la rama de trabajo en la parte superior de la rama usando la estrategia dada [...]" .

Aunque ahora entendemos que la estrategia de fusión no debería tener ningún impacto en los lados (solo la elección de git-merge vs git-rebase debería), debo señalar que la estrategia predeterminada implica la combinación de olge (haciendo que el comportamiento predeterminado sea completo). no ambiguo).

Answer 2

Abajo hay una copia de la respuesta de SzG en una pregunta similar:

Cuando se fusiona , us referimos a la rama en la que se está fusionando, a diferencia de them , la rama a fusionar.

Cuando rebasa , us referimos a la rama corriente arriba, y esa es la rama por la que se está moviendo. Es un poco contrario a la intuición en caso de una rebase.

La razón es que git usa el mismo motor de combinación para el rebase, y en realidad está recogiendo tus cosas en la rama de arriba. us = en, them = desde.