In welchen Fällen könnte `git pull` schädlich sein?

Question

Ich habe einen Kollegen, der behauptet, dass git pull schädlich ist und sich ärgert, wenn es jemand benutzt.

Der Befehl git pull scheint der kanonische Weg zu sein, um Ihr lokales Repository zu aktualisieren. Verursacht die Verwendung von git pull Probleme? Welche Probleme entstehen dadurch? Gibt es einen besseren Weg, ein Git-Repository zu aktualisieren?

Answer 1

Meine Antwort, entnommen aus der Diskussion, die auf HackerNews entstanden ist:

Ich fühle mich versucht, die Frage einfach mit dem Betteridge-Gesetz der Schlagzeilen zu beantworten: Warum wird git pull als schädlich angesehen? Das ist es nicht.

• Nichtlinearitäten sind nicht grundsätzlich schlecht. Wenn sie die tatsächliche Geschichte darstellen, sind sie in Ordnung.
• Das versehentliche Wiedereinführen von Commits, die rebasen wurden, stammt aus der falschen Neuschreibung der Historie upstream. Du kannst die Historie nicht neu schreiben, wenn die Historie in mehreren Repos repliziert wird.
• Das Ändern des Arbeitsverzeichnisses ist ein erwartetes Ergebnis; von fraglichem Nutzen, insbesondere angesichts des Verhaltens von hg/monotone/darcs/anderen_vor_git_verwendeten_dvcs, aber auch hier nicht grundsätzlich schlecht.
• Es ist notwendig, die Arbeit anderer zu überprüfen, um einen Merge durchzuführen, und dies ist wieder ein erwartetes Verhalten bei einem git pull. Wenn du nicht zusammenführen möchtest, solltest du git fetch verwenden. Auch dies ist eine Eigenart von git im Vergleich zu früheren beliebten dvcs, aber es ist ein erwartetes Verhalten und nicht grundsätzlich schlecht.
• Es ist gut, es schwierig zu machen, gegen einen Remote-Zweig zu rebase. Schreibe die Geschichte nicht um, es sei denn, du musst es unbedingt. Ich kann beim besten Willen nicht verstehen, warum man sich auf eine (falsche) lineare Geschichte versteift.
• Das Nichtaufräumen von Branches ist gut. Jedes Repo weiß, was es behalten möchte. Git hat keine Vorstellung von Master-Slave-Beziehungen.

Answer 2

Es wird nicht als schädlich angesehen, wenn Sie Git ordnungsgemäß verwenden. Ich sehe, wie es sich negativ auf Sie auswirkt, basierend auf Ihrem Anwendungsfall, aber Sie können Probleme vermeiden, indem Sie einfach die gemeinsame Historie nicht ändern.

Answer 3

Die akzeptierte Antwort behauptet

Der Rebase-Pull-Vorgang kann nicht konfiguriert werden, um Merges zu erhalten.

aber ab Git 1.8.5, das nach dieser Antwort erschienen ist, können Sie

git pull --rebase=preserve

oder

git config --global pull.rebase preserve

oder

git config branch..rebase preserve

Die Dokumentation sagt

Wenn preserve, wird auch --preserve-merges an 'git rebase' übergeben, so dass lokal durchgeführte Merge-Commits nicht durch 'git pull' flattgedrückt werden.

Diese frühere Diskussion enthält ausführlichere Informationen und Diagramme: git pull --rebase --preserve-merges. Sie erklärt auch, warum git pull --rebase=preserve nicht dasselbe ist wie git pull --rebase --preserve-merges, was nicht das Richtige tut.

In dieser anderen früheren Diskussion wird erklärt, was die Variante preserve-merges des Rebase tatsächlich tut und warum sie viel komplexer ist als ein regulärer Rebase: Was tut genau git's "rebase --preserve-merges" (und warum?)

Answer 4

Wenn Sie zum alten Git-Repository git up gehen, ist das von ihnen vorgeschlagene Alias anders. https://github.com/aanand/git-up

git config --global alias.up 'pull --rebase --autostash'

Dies funktioniert perfekt für mich.