Git - est-ce tiré ou rebasé quand on travaille sur des branches avec d'autres personnes

Question

Donc, si j'utilise des branches qui sont des branches distantes (suivies) et que je veux obtenir le dernier en date, je ne sais toujours pas si je devrais faire git pull ou git rebase . Je pensais avoir lu que faire git rebase lorsque vous travaillez sur une branche avec d'autres utilisateurs peut les foirer lorsqu'ils tirent ou rebassent. Est-ce vrai? Devrions-nous tous utiliser git pull ?

Answer 1

Git pull est une combinaison de 2 commandes

• git fetch (synchronise votre dépôt local avec le dernier contenu de la télécommande)
• git fusionner (fusionne les modifications de la branche distante, le cas échéant, dans votre branche de suivi locale)

git rebase n'est qu'un équivalent approximatif de git merge. Il ne va rien chercher à distance. En fait, il ne fait pas non plus une fusion appropriée, il relit les commits de la branche sur laquelle vous vous trouvez après les nouveaux commits d'une seconde branche.

Son but est principalement de vous laisser une histoire plus propre. Beaucoup de gens fusionnent avant que l'histoire passée de Gitk ne devienne terriblement spaghetti.

La meilleure explication graphique se trouve dans les deux premiers graphiques ici . Mais laissez-moi vous expliquer ici avec un exemple.

J'ai 2 branches: master et mybranch. Quand je suis debout sur ma branche, je peux courir

git rebase master

et tout ce qui est nouveau dans master sera inséré avant les derniers commits dans mybranch. C’est parfait, parce que si je fusionne ou rebase maintenant les éléments de mybranch en maître, mes nouveaux commits sont ajoutés linéairement juste après les commits les plus récents.

Le problème auquel vous faites référence se produit si je me rebase dans le "mauvais". direction. Si je viens juste d’obtenir le dernier maître (avec les nouvelles modifications) et que je reproche à ce maître (avant de synchroniser ma branche):

git rebase mybranch

Maintenant, ce que je viens de faire, c’est que j’ai inséré mes nouvelles modifications quelque part dans le passé de Master. La ligne principale des commits a changé. Et en raison de la manière dont git fonctionne avec les identifiants de commit, tous les commits (du maître) qui venaient d'être rejoués sur mes nouvelles modifications ont de nouveaux identifiants.

Eh bien, c'est un peu difficile à expliquer simplement avec des mots ... J'espère que cela a un sens: -)

Quoi qu'il en soit, mon propre flux de travail est le suivant:

• "Git Pull" nouvelles modifications de la télécommande
• passer à mybranch
• 'git rebase master' pour apporter les nouvelles modifications du maître dans mon historique de commit
• repasser en maître
• 'git merge mybranch', qui effectue une avance rapide uniquement lorsque tout le contenu du maître est également dans mybranch (afin d’éviter le problème de réorganisation des validations sur une branche publique)
• 'git push'

Un dernier mot. Je recommande fortement d’utiliser Rebase lorsque les différences sont triviales (par exemple, des personnes travaillant sur différents fichiers ou au moins différentes lignes). J’ai essayé d’expliquer juste là-haut, mais j’ai une histoire beaucoup plus épurée.

Dès qu'il peut y avoir des conflits importants (par exemple, un collègue a renommé quelque chose dans un groupe de fichiers), je vous recommande fortement de fusionner. Dans ce cas, vous serez invité à résoudre le conflit, puis à valider la résolution. Du côté des avantages, une fusion est beaucoup plus facile à résoudre en cas de conflit. L’inconvénient est que votre histoire peut devenir difficile à suivre si beaucoup de gens fusionnent tout le temps: -)

Bonne chance!

Answer 2

Git rebase est une réécriture de l'historique. Vous ne devriez jamais le faire sur des succursales qui sont "publiques". (c'est-à-dire des branches que vous partagez avec d'autres). Si quelqu'un clone votre branche et que vous la rebasonnez - alors ils ne peuvent plus extraire / fusionner les modifications de votre branche - ils devront jeter l'ancienne et re-tirer.

Cet article sur le logiciel de packaging avec git est une lecture très utile. . Il s’agit plus de la gestion des distributions de logiciels, mais elle est assez technique et explique comment les branches peuvent être utilisées / gérées / partagées. Ils parlent de quand rebaser et quand tirer et quelles sont les conséquences de chacun.

En bref, ils ont tous les deux leur place, mais vous devez vraiment creuser la différence.

Answer 3

git pull effectue une fusion si vous avez des commits qui ne sont pas dans la branche distante. git rebase réécrit les validations existantes, vous devez être relatif à la pointe de la branche distante. Ils sont similaires en ce sens qu’ils peuvent tous les deux causer des conflits, mais je pense que l’utilisation de git rebase , si vous le pouvez, permet une collaboration plus fluide. Pendant l'opération de rebase, vous pouvez affiner vos commits pour qu'ils aient l'air d'avoir été appliqués à la dernière révision de la branche distante. Une fusion est peut-être plus appropriée pour des cycles de développement plus longs sur une branche qui a plus d’histoire.

Comme la plupart des choses dans git, de nombreuses fonctionnalités se chevauchent pour s'adapter à différents styles de travail.

Answer 4

Découvrez les excellentes diffusions Gitcasts sur Branchement et fusion ainsi que rebasement .

Answer 5

Si vous souhaitez extraire la source sans affecter les branches distantes et sans modifier la copie locale, utilisez de préférence git pull.

Je pense que si vous avez apporté des modifications à une branche active, utilisez git rebase pour modifier la base de cette branche en dernier maître distant. Vous conserverez toutes les modifications de votre branche. Toutefois, cette branche sera désormais branchée. à partir de l'emplacement principal, plutôt que de l'endroit où il était précédemment ramifié.