Git Push --force-with-lease contre Git Push --force
Cet article discutera de la différence entre les commandes git push --force-with-lease
et git push --force
. Généralement, nous utilisons la commande git push
pour publier nos modifications locales dans notre référentiel distant.
Allons de l’avant et examinons ces commandes.
la commande git push --force
Lors de la publication de nos modifications locales dans notre référentiel distant, nous exécutons :
$ git push origin
Cependant, dans le cas où plusieurs développeurs partagent notre référentiel distant et publient leurs modifications sur le référentiel distant, Git peut rejeter un push.
Pour forcer Git à publier nos commits, nous ajoutons le drapeau --force
à notre commande git push
, comme indiqué ci-dessous.
$ git push --force origin
L’inconvénient de l’utilisation de cette commande est qu’elle ne prend pas en compte les modifications apportées par d’autres développeurs au référentiel distant. La commande remplacera le référentiel en fonction de l’état de votre référentiel local.
Cela peut être dangereux car cela peut perturber le calendrier de notre projet. Si vous souhaitez envoyer des modifications à un référentiel distant et conserver les modifications apportées par d’autres développeurs, voici comment procéder.
la commande git push --force-with-lease
Cette commande est pratique lorsque plusieurs développeurs partagent un référentiel distant. Nous l’utilisons lors de la publication de nos modifications pour éviter d’ignorer les modifications poussées par d’autres développeurs.
$ git push --force-with-lease origin
Prenons un exemple. Voici l’état actuel de notre référentiel distant.
Nous apporterons quelques modifications au fichier README.md
et validerons les modifications tout en restant sur GitHub. Notez l’identifiant de validation 097ab8b
.
Voici à quoi ça ressemble maintenant.
Notez l’identifiant de validation ba29c53
.
Nous allons maintenant ouvrir le fichier README.md
sur notre ordinateur, effectuer quelques modifications supplémentaires, valider les modifications et tenter un git push
.
Git a rejeté notre tentative de push car l’historique de validation est différent. Nous pouvons exécuter la commande git push --force
, mais cela annulera les modifications que nous avions apportées dans GitHub.
Nous pouvons faire git push --force-with-lease
comme indiqué ci-dessous.
$ 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)
La différence entre git push --force-with-lease
et git push --force
est le résultat. Pousser les changements avec lease
nous aide à éviter d’ignorer les changements poussés par d’autres développeurs.
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