web-dev-qa-db-fra.com

git rebase Origin / develop vs git rebase develop

Supposons que la branche actuelle soit MyFeatureX. Et la branche locale develop est à jour avec Origin. Les deux déclarations ci-dessous seraient-elles équivalentes? Quelle est la syntaxe recommandée?

git rebase Origin/develop 
git rebase develop

Remarque: ce n'est pas la même question que git rebase Origin vs.git rebase Origin/master

gitgit-rebase
14
Polymerase

Votre succursale locale developpistesOrigin/develop et ils peuvent ne pas toujours avoir les mêmes commits.

$ cat ~/.git/config

[remote "Origin"]
    url = [email protected]/repo.git
    fetch = +refs/heads/*:refs/remotes/Origin/*

Cela signifie que nous avons un "distant" (un référentiel vivant ailleurs) nommé arbitrairement "Origin".

Votre branche locale develop suit la branche à partir de ce référentiel distant, et il existe une référence locale à ces données appelée Origin/develop. Pour la plupart, nous considérons que ces deux choses contiennent toujours les mêmes commits. Cependant, vous devez mettre à jour explicitement votre branche locale develop pour obtenir les dernières données d'Origin. Cela se fait généralement avec un pull:

$ git status
    on branch develop
$ git pull
    ...pulls latest changes from Origin

Cependant, un git pull fait en fait deux étapes, un fetch et un merge. La première étape qu'il fait sous le capot est de récupérer toutes les dernières validations d'Origin, ce que vous pouvez faire avec

git fetch Origin

Cela mettra à jour la branche Origin/develop, mais pas votre branche locale develop.

Les derniers commits sont cachés "en arrière-plan" dans votre répertoire local .git, que vous pouvez référencer à partir de la branche nommée "Origin/develop".

Après une extraction, pour réellement créer votre branche locale Origin, vous devez faire git merge Origin/develop. Techniquement, ce n'est pas une fusion, ce sera une "avance rapide", ce qui signifie que git est assez intelligent pour faire correspondre votre branche locale OriginOrigin/develop sans fusionner quoi que ce soit. Pour cette raison et d'autres, les fusions me font flipper.

Donc, si vous rebasez hors de develop, il y a une chance que ce soit obsolète (plus ancien) que Origin/develop.

Personnellement, je fais ce workflow avant de rebaser:

git fetch --all
git rebase Origin/branchname

Cela signifie que je peux extraire toutes les données sans avoir à trop penser à quelle branche je suis et rebaser le dernier code du référentiel distant. Plus tard, sur la branche develop, un simple git pull s'assurera que vous êtes à jour.

19
Andy Ray

Si develop pointe vers le même commit que Origin/develop alors les deux commandes sont exactement les mêmes. J'aurais tendance à utiliser Origin/develop au cas où j'aurais oublié de mettre à jour mon develop local (en supposant que cette branche sera finalement poussée vers Origin/develop).

2
Penguin Brian

Comme je l'ai écrit dans mon autre (longue) réponse à votre question précédente Pourquoi "rebase - sur ABC" est différent de "rebase ABC"? , ces deux commandes désactivent --fork-point , donc, à condition que develop et Origin/develop se résolvent dans le même hachage de validation, comme ils le font dans votre prémisse de question - les deux commandes feront la même chose.

L'omission de l'argument <upstream> Active --fork-point Par défaut, et le reflog pour la branche configurée en amont peut contenir beaucoup de données. Dans ce cas, ils peuvent agir très différemment. En ajoutant un --no-fork-point Explicite, vous pouvez empêcher git merge-base --fork-point De supprimer les commits supprimés en amont.

1
torek