Git Push --force-with-lease vs Git Push --force

John Wachira 15 Februar 2024
  1. den Befehl git push --force
  2. den Befehl git push --force-with-lease
Git Push --force-with-lease vs Git Push --force

Dieser Artikel behandelt den Unterschied zwischen den Befehlen git push --force-with-lease und git push --force. Im Allgemeinen verwenden wir den Befehl git push, um unsere lokalen Änderungen in unserem Remote-Repository zu veröffentlichen.

Lassen Sie uns fortfahren und diese Befehle untersuchen.

den Befehl git push --force

Wenn wir unsere lokalen Änderungen in unserem Remote-Repository veröffentlichen, führen wir Folgendes aus:

$ git push origin

In einem Fall jedoch, in dem mehrere Entwickler unser Remote-Repository gemeinsam nutzen und ihre Änderungen im Remote-Repository veröffentlichen, kann Git einen Push ablehnen.

Um Git zu zwingen, unsere Commits zu veröffentlichen, fügen wir das --force-Flag zu unserem git push-Befehl hinzu, wie unten gezeigt.

$ git push --force origin

Der Nachteil bei der Verwendung dieses Befehls besteht darin, dass Änderungen, die von anderen Entwicklern an das Remote-Repository übertragen wurden, nicht berücksichtigt werden. Der Befehl überschreibt das Repository basierend auf dem Status Ihres lokalen Repositorys.

Dies kann gefährlich sein, da es unseren Projektzeitplan durcheinander bringen kann. Wenn Sie Änderungen an ein Remote-Repository übertragen und die von anderen Entwicklern vorgenommenen Änderungen beibehalten möchten, gehen Sie wie folgt vor.

den Befehl git push --force-with-lease

Dieser Befehl ist praktisch, wenn mehrere Entwickler ein Remote-Repository gemeinsam nutzen. Wir verwenden es beim Veröffentlichen unserer Änderungen, um zu vermeiden, dass von anderen Entwicklern vorgenommene Änderungen verworfen werden.

$ git push --force-with-lease origin

Schauen wir uns ein Beispiel an. Hier ist der aktuelle Stand unseres Remote-Repositorys.

Geschichte begehen

Wir werden einige Änderungen an der Datei README.md vornehmen und die Änderungen festschreiben, während wir uns noch auf GitHub befinden. Beachten Sie die umrissene Commit-ID 097ab8b.

So sieht es jetzt aus.

Commit-Verlaufsaktualisierung

Beachten Sie die Commit-ID ba29c53.

Wir werden nun die Datei README.md auf unserem Computer öffnen, weitere Änderungen vornehmen, die Änderungen übernehmen und einen git push versuchen.

Push-Versuch

Git hat unseren Push-Versuch abgelehnt, da der Commit-Verlauf anders ist. Wir können den Befehl git push --force ausführen, aber dadurch werden die Änderungen verworfen, die wir in GitHub vorgenommen haben.

Wir können git push --force-with-lease wie unten gezeigt ausführen.

$ git push --force-with-lease
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 314 bytes | 314.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://github.com/Wachira11ke/Delftscopetech.git
 + b7b8e6a...8ddd086 main -> main (forced update)

Der Unterschied zwischen git push --force-with-lease und git push --force ist das Ergebnis. Das Pushen von Änderungen mit lease hilft uns, das Verwerfen von Änderungen zu vermeiden, die von anderen Entwicklern gepusht wurden.

John Wachira avatar John Wachira avatar

John is a Git and PowerShell geek. He uses his expertise in the version control system to help businesses manage their source code. According to him, Shell scripting is the number one choice for automating the management of systems.

LinkedIn

Verwandter Artikel - Git Push