Ein Pull holt den Stand des Remote und führt ihn sofort mit deinem eigenen zusammen. Er ist damit zwei Schritte in einem: erst ein Fetch, dann ein Zusammenführen in den Zweig, auf dem du gerade stehst.
- Pull
Das Holen des Remote-Stands mit anschließendem Zusammenführen.
Beispiel: „Vor jedem Arbeitsbeginn ein Pull, dann baut die eigene Arbeit auf dem aktuellen Stand auf.“Englisch to pull heißt ziehen. Die Gegenrichtung ist der Push.
Abgrenzung zum Pull Request: Der hat mit diesem Befehl nichts zu tun. Er ist die Bitte an das Team, einen Zweig zu übernehmen, und eine Erfindung von GitHub.
Warum ein Pull Konflikte auslösen kann
Weil zusammengeführt wird. Haben zwei Leute dieselbe Zeile geändert, kann Git nicht entscheiden, welche gilt, und legt die Stelle zur Entscheidung vor. Das ist kein Fehler, sondern der vorgesehene Ablauf.
Je länger zwischen zwei Pulls liegt, desto größer wird dieser Berg. Täglich holen spart deshalb Arbeit; mit Ordnungsliebe hat es wenig zu tun.
Wann ein Pull die falsche Wahl ist
Wenn du ungesicherte Änderungen im Arbeitsverzeichnis hast. Git verweigert den Pull dann für die betroffenen Dateien, und was es nicht verweigert, mischt es in deinen Zwischenstand.
Sauberer ist, vorher zu committen oder beiseitezulegen. Dann ist klar, was dein Stand ist und was dazugekommen ist.
Was ein Pull in der Geschichte hinterlässt
In der Voreinstellung einen zusätzlichen Commit, der die beiden Stränge verbindet. Bei häufigen Pulls entsteht daraus eine Geschichte voller kleiner Verbindungsstellen, die niemand liest.
Wer das vermeiden will, lässt den Pull die eigenen Commits oben aufsetzen statt zusammenzuführen. Das ergibt eine gerade Linie und ist in Projekten verbreitet, die auf eine lesbare Geschichte achten.