Comment puis-je utiliser git rebase sans avoir besoin d'un push forcé ?

Question

Dans une tentative d'atteindre le nirvana de git, je passe la journée à apprendre comment tirer parti de rebase dans les situations où je fusionne actuellement.

Lors de l'exécution de ce que je considère comme un flux git 101 (que je détaille ci-dessous), je dois push --force lorsque je repousse mes modifications vers l'origine.

Je ne suis pas le seul - je sais qu'il s'agit d'un sujet déjà abordé (voir 1 , 2 , 3 , 4 , 5 ), et je comprends les raisons techniques pourquoi une force est nécessaire. Mon problème est le suivant --- il y a beaucoup (beaucoup) d'articles de blog qui chantent les louanges de rebase et comment cela a changé leur vie (voir 1 , 2 , 3 , 4 pour n'en citer que quelques-uns), mais aucun d'entre eux ne mentionne que les push --force fait partie de leur flux. Cependant, presque toutes les réponses aux questions existantes de stackoverflow disent des choses comme "ouais, si vous allez rebaser, vous devez utiliser push --force ".

Compte tenu du nombre et de la religiosité des partisans de la rebase, Je dois croire que l'utilisation de "push --force" n'est pas une partie inhérente d'un flux de rebase, et que si quelqu'un doit souvent forcer ses pushs, il fait quelque chose de mal .

push --force es un mauvaise chose .

Voici donc mon flux. Comment pourrais-je obtenir les mêmes résultats sans force ?

Exemple simple

Deux branches :

• v1.0 - une branche "release", qui ne contient que des correctifs
• maître - tout pour la prochaine version majeure.

J'ai quelques commits de correctifs et quelques commits pour la prochaine version.

J'aimerais incorporer les correctifs dans mon master afin qu'ils ne soient pas perdus pour la prochaine version. Avant l'illumination, tout simplement :

git checkout master
git merge v1.0

Mais maintenant, j'essaie

git checkout master
git rebase v1.0

Maintenant, je suis ici :

Temps pour :

git push

Aucun résultat.

Answer 1

Le rebasage est un outil formidable, mais il fonctionne mieux lorsque vous l'utilisez pour créer des fusions rapides de branches de sujets vers master. Par exemple, vous pourriez rebaser votre branche add-new-widget sur master :

git checkout add-new-widget
git rebase -i master

avant d'effectuer une fusion rapide de la branche dans master. Par exemple :

git checkout master
git merge --ff-only add-new-widget

L'avantage est que votre historique n'aura pas beaucoup de commits de fusion complexes ou de conflits de fusion, parce que tous vos changements seront rebasés sur l'extrémité de master avant la fusion. Un avantage secondaire est que vous avez rebasé, mais vous n'avez pas besoin d'utiliser la commande git push --force parce que vous n'êtes pas en train d'écraser l'histoire sur la branche principale.

Ce n'est certainement pas le seul cas d'utilisation de rebase, ni le seul flux de travail, mais c'est l'une des utilisations les plus sensées que j'ai vues. YMMV.

Answer 2

@CodeGnome a raison. Il ne faut pas rebaser le master sur la branche v1.0 mais la branche v1.0 sur le master, cela fera toute la différence.

git checkout -b integrate_patches v1.0
git rebase master
git checkout master
git merge integrate_patches

Créez une nouvelle branche qui pointe vers la v1.0, déplacez cette nouvelle branche au-dessus de master et intégrez la nouvelle version des patches V1.0 à la branche master. Vous obtiendrez quelque chose comme :

o [master] [integrate_patches] Another patch on v1.0
o A patch on v1.0
o Another change for the next major release
o Working on the next major release
|  o [v1.0] Another path on v1.0
|  o A patch on v1.0
| /
o Time for the release

Cette façon d'utiliser rebase est recommandée par la documentation officielle de git .

Je pense que vous avez raison en ce qui concerne git push --force Le droit à l'information : vous ne devez l'utiliser que si vous avez fait une erreur et que vous avez poussé quelque chose que vous ne souhaitiez pas.

Answer 3

Il faut forcer la poussée si l'on rebase, et vous avez déjà publié vos modifications, n'est-ce pas ?

J'utilise beaucoup rebase, mais soit je publie sur quelque chose de privé où un push forcé n'a pas d'importance (ex : mon propre clone sur GitHub, dans le cadre d'une pull request), soit je rebase avant de pousser pour la première fois.

C'est le cœur du flux de travail où l'on utilise le rebasement, mais où l'on ne force pas trop le push : ne pas publier les choses avant qu'elles ne soient prêtes, ne pas rebaser après avoir poussé.

Answer 4

Je pense qu'il y a un bon cas d'utilisation pour ce modèle rebase-then-force-push qui n'est pas le résultat d'un push erroné : travailler sur une branche de fonctionnalité par soi-même à partir de plusieurs endroits (ordinateurs). Je le fais souvent, car je travaille parfois au bureau sur mon ordinateur de bureau, et parfois à la maison ou sur le site du client sur mon ordinateur portable. J'ai besoin de rebaser occasionnellement pour suivre la branche principale et/ou pour rendre les fusions plus propres, mais j'ai aussi besoin de forcer le push quand je quitte une machine pour aller travailler sur une autre (où je ne fais que tirer). Cela fonctionne à merveille, tant que je suis le seul à travailler sur la branche.

Answer 5

Voici ce que j'utilise (en supposant que le nom de votre branche soit foobar ) :

git checkout master              # switch to master
git rebase   foobar              # rebase with branch
git merge -s ours origin/master  # do a basic merge -- but this should be empty
git push origin master           # aaand this should work