git pull --rebase

Question

situación de arranque (no hay cambios unpushed, > indica la rama actual):

o C [> master][origin/master] 
| 
o B 
| 
o A 
| 
... 

Después de un git fetch la estructura de registro a menudo se ve como

o E [origin/master] 
| 
o C' 
| 
o B' 
| 
o D 
| 
| o C [>master] 
| | 
| o B 
|/ 
o A 
| 
... 

Ahora git rebase origin/master master menudo produce conflictos . ¿Es git pull --rebase más inteligente y solo usa git reset para hacer que master también apunte a E si master == origin/master inicialmente?

Answer 1

git pull --rebase su parecido a lo que:

git fetch 
git rebase 

haría. Así, en su caso dejará el repositorio de esta manera:

o C [> master] 
| 
o B 
| 
o E [origin/master] 
| 
o C' 
| 
o B' 
| 
o D 
| 
o A 
| 
... 

Tenga en cuenta que las dos confirmaciones que tiene diferente de origen, donde re-creado en la parte superior de cometer E.

Answer 2

Puede tirar usando rebase en lugar de combinación - Así es como trabaja mi equipo y funciona bastante bien.

De "A few git tips you didn't know about":

Debido a que la rama se funde en git se registran con una combinación de cometer, que se supone que son significativos, por ejemplo, para indicar cuando una característica se ha fusionado con un comunicado rama. Sin embargo, durante un flujo de trabajo diario normal donde varios miembros del equipo sincronizan una sola rama a menudo, la línea de tiempo se contamina con microinterferencias innecesarias en la extracción regular de git . Rebasing garantiza que las confirmaciones siempre se vuelvan a aplicar para que el historial se mantenga lineal.

Puede configurar ciertas ramas de hacer siempre esto sin la bandera --rebase :

#make 'git pull' on master always use rebase
$ git config branch.master.rebase true

También puede configurar una opción global para establecer la última propiedad por cada nuevo rama de orugas:

# setup rebase for every tracking branch
$ git config --global branch.autosetuprebase always

Answer 3

git pull --rebase es NO lo mismo que git fetch; git rebase. Por desgracia la página git-pull hombre es más bien críptico sobre la diferencia:

--rebase 
     Rebase the current branch on top of the upstream branch 
     after fetching. If there is a remote-tracking branch 
     corresponding to the upstream branch and the upstream branch 
     was rebased since last fetched, the rebase uses that 
     information to avoid rebasing non-local changes. 

Resulta que la diferencia no implica git reset como el cartel original supuso - de hecho, se trata de la reflog (ver here si remanso encontrado ese término antes).

Para la historia completa alrededor de la magia extra en git pull --rebase, ver esta respuesta:

https://stackoverflow.com/a/11531502/179332