Git Push --force-with-lease contre Git Push --force

John Wachira 15 février 2024
  1. la commande git push --force
  2. la commande git push --force-with-lease
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.

historique de validation

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.

mise à jour de l’historique des commits

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.

Tentative de poussée

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.

Auteur: John Wachira
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

Article connexe - Git Push