Est-il préférable d'utiliser git pull --rebase que git pull --ff-only

Réponse courte: utilisez git pull --rebase

Tout d'abord, votre exemple ne fonctionne pas, le client 1 aurait besoin de valider autre chose avant le pull --ff-only , mais supposons que nous l'avons fait.

Pourquoi git pull --ff-only échoue?

Cette commande demande à git de fetch le dernier état de la télécommande et d'avancer rapidement la branche si possible. Donc, si nous avons des changements différents sur la branche distante et locale, cela s'arrêtera, car c'est ce que nous lui avons dit de faire avec --ff-only

Que fera git pull --rebase ?

Il fetch également, mais après cela, il fera un git rebase origin/master . Witch prendra tous les commits sur le maître qui ne sont pas déjà sur la télécommande et les rebasera à la fin de l'origine / du maître. Bien sûr, vous devrez peut-être résoudre les conflits de fusion qui surviennent. Le seul danger que je vois est que vous devriez tester ce qui se passe si vous avez des commits de fusion dans votre branche, mais puisque vous voulez un historique linéaire, cela ne devrait pas être un problème pour vous.

Flux de travail à avance rapide uniquement

Le flux de travail que vous présentez ne doit autoriser que les tirages d'avance rapide. Cependant, pour que cela fonctionne, vous avez besoin d'une coordination parfaite entre les membres de l'équipe travaillant sur différents clients et vous ne pouvez travailler que sur un client à la fois .

Par exemple, alors que quelqu'un travaille sur le client 1, les gens ne peuvent pas créer de commits sur le client 2 et vice versa. Si les commits sont créés simultanément sur les deux clients, vous vous retrouverez avec des historiques divergents qui devront être fusionnés avec un commit ou rebasés: une fusion rapide ne sera pas possible.

Ce n'est pas vraiment pratique (comme l'expérience vous l'a appris: le message d'erreur que vous obtenez et les sorties de git branch -vv et gitk --all vous montrent tous que vous vous êtes retrouvé avec des histoires divergentes sur les 2 clients sans le vouloir et sans vous en rendre compte il). Il s'agit également d'un flux de travail non efficace car tous les clients sauf un doivent être en attente à tout moment. Un bon flux de travail de contrôle de version devrait permettre à différentes personnes de travailler simultanément, puis d'intégrer leur travail dans le projet.

Rebase

Dès que différentes personnes ont créé des commits simultanément sur différents clients, vous avez besoin de commits de fusion ou de rebases. Les validations de fusion créent des historiques non linéaires, donc si vous voulez un historique linéaire, vous devez rebaser.

Cela peut en effet être fait avec git pull --rebase .

Le rebasage est une réécriture de l'histoire et il est dangereux de le faire sur des commits qui ont déjà été poussés vers une télécommande, mais c'est sûr de le faire sur des commits non publiés.

Lorsque vous exécutez git pull --rebase , la branche actuelle est rebasée au-dessus de la branche amont fraîchement récupérée. Donc, c'est l'histoire de votre succursale locale qui est réécrite, pas celle de l'amont. Ainsi, tant que votre équipe n'utilise qu'une seule télécommande pour synchroniser le travail, vous pouvez fusionner les modifications de cette télécommande dans la vôtre avec git pull --rebase sans risquer de créer des problèmes pour les autres.

Réécrire l'historique sur un flux de travail non linéaire

Une autre alternative serait de fusionner avec git pull --ff qui fera des fusions d'avance rapide lorsque cela est possible, mais créera des commits de fusion lorsque ce n'est pas possible, puis réécrira l'historique du projet de temps en temps pour le rendre linéaire. Ces réécritures de l'histoire pourraient être coordonnées au niveau de l'équipe, bloquant toute activité du projet lorsqu'elles surviennent, pour éviter tout problème.

Une façon de le faire serait d'utiliser git reset comme cela est présenté dans la section Squashing près du bas de cette section du Pro Git Book.

Cependant, un inconvénient de cette méthode est que vous perdrez les petites étapes introduites par chaque commit. C'est aussi une approche beaucoup plus tortueuse et cela peut être dangereux si quelqu'un ne respecte pas le gel de l'activité lors de la réécriture de l'histoire (sans oublier que de tels gels ne sont pas efficaces).

Conclusion

En conclusion, utiliser git pull --rebase est probablement la meilleure solution ici.

Remarque

Vous pouvez définir ceci comme comportement par défaut pour git pull avec:

git config --global pull.rebase true

(Supprimez --global si vous ne le souhaitez que pour un projet).

Pour placer votre travail local au-dessus de la branche distante: utilisez git pull --rebase .

S'il s'agit du flux de travail prévu pour toute votre équipe: que tout le monde soit défini

git fetch                # will update all remote branches
git fetch origin branch  # if you want to update one single branch from the remote

et git pull se traduira maintenant par git pull --rebase .

L'utilisation prévue de git pull --ff-only est:

• lorsque vous n'avez pas de travail local en plus de la branche actuelle,
• et vous souhaitez mettre à jour cette branche vers son homologue distant,
• et assurez-vous de ne pas créer accidentellement un commit de fusion.

Si vous avez le travail local sur le dessus de la branche, git pull --ff-only ne fera jamais l' action:

1. soit votre version de la télécommande est déjà à jour (donc aucune mise à jour n'est nécessaire),
2. ou quelqu'un d'autre l'a modifié, et l'intégration de ces mises à jour ne sera jamais une fusion rapide (donc la mise à jour sera annulée).

Si vous souhaitez importer la branche distante pour vérifier si elle a été mise à jour: utilisez git fetch

git config pull.rebase true

Après avoir exécuté git fetch , vous pouvez comparer votre branche et origin/branch (utilisez un visualiseur git, ou git log --graph --oneline HEAD origin/branch ), vous pouvez rebaser votre travail au-dessus de l' origin/branch (en exécutant: git rebase origin/branch ), etc ...