Dans ce cas, pourrait "git pull" être nocif?

Question

J'ai un collègue qui prétend qu' git pull est dangereux, et qui s'énerve à chaque fois que quelqu'un l'utilise.

L' git pull commande semble être la manière canonique de mettre à jour votre référentiel local. N'utilisez git pull créer des problèmes? Quels sont les problèmes qu'il crée? Est-il un meilleur moyen de mettre à jour un dépôt git?

Answer 1

Ma réponse, tiré de la discussion qui se pose sur HackerNews:

Je me sens tenté de simplement répondre à la question à l'aide de la Betteridge Loi de Titres de l'actualité: Pourquoi est - git pull considéré comme dangereux? Il n'est pas.

• Les non-linéarités ne sont pas intrinsèquement mauvais. Si elles représentent le réel de l'histoire, ils sont ok.
• Accidentelle de réintroduction de commits relocalisée en amont est le résultat de tort réécriture de l'histoire en amont. Vous ne pouvez pas réécrire l'histoire, quand l'histoire est répliquée sur plusieurs titres.
• Modifier le répertoire de travail est un résultat attendu; de l'utilité discutable, à savoir dans le visage du comportement de hg/monotone/darcs/other_dvcs_predating_git, mais encore une fois pas intrinsèquement mauvais.
• Faire une pause pour examiner le travail des autres est nécessaire pour une opération de fusion, et est de nouveau un comportement attendu sur git pull. Si vous ne voulez pas de fusion, vous devez utiliser git fetch. Encore une fois, c'est une idiosyncrasie de git en comparaison avec les précédents populaire dvcs, mais c'est un comportement attendu et pas intrinsèquement mauvais.
• Ce qui rend difficile de rebase contre une branche distante est bon. Ne pas réécrire l'histoire, sauf si vous devez absolument. Je ne peux pas pour la vie de me comprendre, cette recherche d'un (faux) linéaire de l'histoire
• Pas de nettoyage des branches est bon. Chaque repo sait ce qu'il veut tenir. Git n'a aucune notion de maître-esclave relations.

Answer 2

Il n'est pas considéré comme dangereux si vous utilisez Git correctement. Je vois comment il vous affecte négativement donné votre cas d'utilisation, mais vous pouvez éviter les problèmes, simplement par ne pas modifier l'histoire commune.

Answer 3

La accepté de répondre à des réclamations

Le rebase-pull opération ne peut pas être configuré de manière à préserver fusionne

mais comme de Git 1.8.5, qui est postérieure à cette réponse, vous pouvez le faire

git pull --rebase=preserve

ou

git config --global pull.rebase preserve

ou

git config branch.<name>.rebase preserve

Les docs disent

Lors de l' preserve, également transmettre --preserve-merges le long de git rebase "de sorte que, localement, commis de fusion s'engage ne sera pas écrasé par l'exécution "git pull".

Cette discussion précédente contient des informations plus détaillées et des schémas: git pull --rebase --preserve-fusionne. Cela explique aussi pourquoi l' git pull --rebase=preserve n'est pas le même que git pull --rebase --preserve-merges, ce qui ne veut pas faire la bonne chose.

Cette autre discussion précédente explique ce qu'est la préserver-fusionne variante de rebase en fait, et comment il est beaucoup plus complexe qu'une simple rebase: qu'est-Ce exactement ne git "rebase --preserve-fusionne" faire (et pourquoi?)