origin - git remote-v

Los resultados de extracción de Git en mensajes "Merge branch" extraños en el registro de commit

Question

Estoy trabajando con otro desarrollador en un proyecto, y estamos usando Github como nuestro repositorio remoto. Estoy en una Mac usando git 1.7.7.3, está en Windows usando git 1.7.6.

Esto es lo que está sucediendo

1. Uno de nosotros (llamémosle desarrollador A, pero no importa cuál) envía un conjunto de confirmaciones a GitHub.
2. El otro (desarrollador B) realiza algunas confirmaciones locales.
3. B hace un git pull .
4. B hace un git push .
5. Al mirar el registro de historial de confirmaciones, veo la rama Merge ''master'' de github.com:foo/bar

El registro de confirmación se llena con los mensajes "Fusionar rama" a lo largo del tiempo, y también muestra que el desarrollador B está cometiendo cambios que el desarrollador A realizó. La única forma que hemos encontrado para evitar este problema ha sido hacer un git pull --rebase en el paso 3, pero no sé qué efectos secundarios introducirán. Esta es la primera vez que trabajo en un repositorio git de varios desarrolladores, ¿es esto un comportamiento normal? ¿Alguna idea sobre cómo resolver este problema?

Answer 1

El compromiso que estás viendo está perfectamente bien. Una pull ejecuta efectivamente git fetch y luego git merge por lo que generalmente ocurre una fusión cuando ejecutas git pull .

La alternativa para utilizar el rebase en lugar de fusionarse es posible, pero por lo general debes evitarlo. Rebasing le permite mantener un historial lineal, pero también elimina cualquier información sobre la bifurcación que originalmente ocurrió. También causará que se reescriba el historial de la rama actual, recreando todas las confirmaciones que no están contenidas en la rama de destino (en su caso, el control remoto). Como las confirmaciones recreadas son compromisos diferentes , esto puede causar mucha confusión cuando se desarrollan junto con otros, especialmente cuando la gente ya revisó partes de esas confirmaciones antes de que se vuelvan a escribir (por ejemplo, con ramas de características). Por lo tanto, como regla general, nunca debe volver a escribir ningún compromiso que ya haya sido enviado.

Los commits que ves están ahí para combinar dos (o más) ramas. Está perfectamente bien tener una confirmación que no haga más que fusionar múltiples ramas. De hecho, deja muy claro cuando tienes una combinación de fusión que combina ramas cuando se mira la historia. En comparación con el rebasado, la fusión también le permite ver efectivamente la historia original tal como fue desarrollada, incluidas las ramas reales que coexistieron.

Entonces, para resumir: Sí, tener compromisos de fusión está perfectamente bien y no deberías preocuparte por ellos.

Answer 2

En realidad, hay una respuesta mucho más simple a esto. Solo haz que el desarrollador B lo jale ANTES de hacer su compromiso. Esto evitará esas confusiones de fusión, ya que son causadas por el historial que ha creado en su repositorio local a partir de su confirmación local que intenta fusionarse con el historial de las confirmaciones en el repositorio remoto. Si aparece un mensaje que dice algo así como "se sobrescribirán los cambios" al hacer un tirón, significa que ambos tocaron el mismo archivo, por lo que:

git stash
git pull
git stash pop

entonces puedes resolver cualquier conflicto de fusión si hay alguno.

Answer 3

Esta respuesta ha sido revisada, ya que mi comprensión, diagramas y conclusiones fueron incorrectos.

git pull provoca uniones de fusión porque git se está fusionando. Esto se puede cambiar estableciendo sus ramas para usar rebase en lugar de fusionar. Usar rebase en lugar de fusionar en un pull proporciona un historial más lineal al repositorio compartido. Por otro lado, los commit de fusión muestran los esfuerzos de desarrollo paralelo en la rama.

Por ejemplo, dos personas trabajan en la misma rama. La rama comienza como:

...->C1

La primera persona termina su trabajo y empuja a la sucursal:

...->C1->C2

La segunda persona termina su trabajo y quiere presionar, pero no puede porque necesitan actualizar. El repositorio local para la segunda persona se ve así:

...->C1->C3

Si la extracción está configurada para fusionarse, se verá el segundo repositorio de personas.

...->C1->C3->M1
      /      /
       ->C2->

Donde M1 es un compromiso de fusión. Este nuevo historial de sucursal se enviará al repositorio. Si, en cambio, la extracción se establece en rebase, el repositorio local se vería así:

...->C1->C2->C3

No hay compromiso de fusión. La historia se ha hecho más lineal.

Ambas opciones reflejan la historia de la sucursal. git le permite elegir qué historial prefiere.

De hecho, hay lugares donde la rebase puede causar un problema con las sucursales remotas. Este no es uno de esos casos. Preferimos utilizar rebase, ya que simplifica un historial de sucursales ya complicado, así como también muestra una versión del historial relacionado con el repositorio compartido.

Puede establecer branch.autosetuprebase = always para que git establezca automáticamente sus ramas remotas como rebase en lugar de maestro.

git config --global branch.autosetuprebase always

Esta configuración hace que git cree automáticamente una configuración para cada rama remota:

branch.<branchname>.rebase=true

Puede configurarlo usted mismo para sus sucursales remotas que ya están configuradas.

git config branch.<branchname>.rebase true

Me gustaría agradecer a @LaurensHolst por cuestionar y seguir mis declaraciones anteriores. Sin duda, he aprendido más sobre cómo funciona git con los commits de pull y merge.

Para obtener más información acerca de las ProGit-Book fusión, puede leer Contribuir a un proyecto en ProGit-Book . La sección de Equipo pequeño privado muestra las asignaciones de fusión.

Answer 4

Hacer un git pull insertará los mensajes "Merge branch", eso es exactamente lo que hace. Al hacer un git pull, ha fusionado la rama remota en su sucursal local.

Cuando haces un git pull y hay conflictos, el registro de git mostrará las actualizaciones de los archivos en conflicto como procedentes del usuario que resolvió los conflictos. Supongo que esto se debe a que la persona que arregla el conflicto vuelve a confirmar el archivo.

Por lo que sé, así es como funciona git, y no hay forma de evitarlo.

Rebasing soplará el historial de git, por lo que no podrá ver cuándo se produjeron las fusiones.

Answer 5

Tu puedes hacer:

git pull --rebase

Sin embargo, esto siempre pondrá sus cambios encima de sus colaboradores ''. Pero no recibirá ningún mensaje de fusión contaminante.