Ein Push überträgt die Commits aus deinem lokalen Repository zum Remote, also zu dem Stand, auf den sich alle geeinigt haben. Vorher weiß niemand außer dir von deiner Arbeit; danach können alle sie holen.
- Push
Das Übertragen eigener Commits zum gemeinsamen Stand.
Beispiel: „Nach dem Push läuft die Build-Pipeline los und veröffentlicht die Änderung.“Englisch to push heißt schieben. Die Gegenrichtung ist Fetch beziehungsweise Pull.
Abgrenzung zum Commit: Der Commit hält fest, der Push verteilt. Wer committet und nicht pusht, hat seine Arbeit gesichert, aber mit niemandem geteilt.
Warum ein Push abgelehnt wird
Weil in der Zwischenzeit jemand anderes gepusht hat. Git nimmt deine Commits nur an, wenn sie lückenlos an den vorhandenen Stand anschließen; andernfalls würde die Arbeit der anderen verschwinden.
Der Ausweg ist immer derselbe: erst holen, dann zusammenführen, dann erneut pushen. Ein Pull erledigt die ersten beiden Schritte in einem.
Was ein Force Push anrichtet
Er setzt den Stand auf dem Remote auf deinen, ohne zu prüfen, ob er daran anschließt. Commits anderer, die darauf aufbauten, sind danach aus dem Zweig verschwunden, und wer sie noch lokal hat, bekommt beim nächsten Holen ein unverständliches Durcheinander.
In einem Zweig, an dem nur du arbeitest, ist er harmlos und manchmal sinnvoll. Auf einem gemeinsamen Zweig ist er der schnellste Weg, einen Arbeitstag im Team zu kosten.
Was nach dem Push geschieht
Bei einem eingerichteten Projekt mehr, als man vermutet. Der Push löst die Build-Pipeline aus, die baut, prüft und je nach Zweig auch veröffentlicht.
Deshalb ist der Push in vielen Projekten der Punkt, an dem eine Änderung aufhört, privat zu sein. Was danach schiefgeht, sehen alle.