Discussion :

[Henry22]

Bonjour,

J'ai lu un article sur git push --force:
https://evilmartians.com/chronicles/...o-deal-with-it

J'aimerais comprendre le problème de l'article pour le reproduire de mon côté.
En effet, je ne comprends pas trop à quoi sert git push --force et quel problème ça peut conduire.

Pouvez vous m'expliquer s'il vous plaît?

Je te remercie par avance,

[Marco46]

Je ne connais pas deis.com mais heroku oui, c'est un PaaS qui permet de déployer ses apps dans diverses stacks.

Le vecteur de déploiement est une branche d'un dépôt Git. On ne déploie pas son code mais le livrable via Git.

IMHO il faut ignorer cet article il est plutôt mauvais car il n'explique pas assez le contexte et peut être une grande source de confusion pour les débutants. Applique comme règle de ne jamais forcer un push.

Tu peux forcer le push (mais c'est mal) lorsqu'il y a une désynchronisation entre ta version locale d'une branche et sa version distante. Cela ne doit jamais arriver. Forcer un push c'est écraser l'historique de la branche distante avec le tiens. C'est mal, ça veut dire écraser le taf des autres.

Pour reproduire le problème c'est faisable en 5 minutes en local.

Tu te mets dans un nouveau répertoire et tu te crées un bare repo (par ex : mkdir depot-remote && git init --bare).

Puis tu clones ce dépôt 2 fois (cd .. && git clone depot-remote/ depot1/ && git clone depot-remote/ depot2/).

Donc tu te retrouves avec ton dépôt distant dans le répertoire depot-remote/ qui est origin pour depot1/ et depot2/.

En d'autres termes, depot-remote/ c'est l'équivalent du dépôt sur GitLab ou GitHub, depot1/ c'est le clone du remote sur la machine d'un premier développeur, et depot2/ le clone du remote sur la machine d'un deuxième développeur.

Dans depot1/ tu crées le commit initial puis tu push. Dans depot2/ tu pull le commit initial.

Ensuite dans depot1/ tu fais une modif que tu push et dans depot2/ tu fais aussi une modif et tu essaies de push sans avoir rebase ni merge la master de origin.

Tu vas te faire reject. Là tu peux forcer le push via git push --force origin master. Ensuite tu vas dans depot-remote/ et tu fais un git log. Tu pourras constater que tu as écrasé les commits de depot1/ avec ceux de depot2/. Donc le dev depot1/ à de quoi être furax, tu lui as supprimé son taf !

C'est cette situation que décrit l'article, elle résulte de mauvaises pratiques.

Les branches master, develop, etc ... Sont des branches d'intégration des développements. Elles sont les cibles des merge request (GitLab) / pull request (GitHub). En protégeant ces branches (comme indiqué dans l'article) tu ne pourras jamais faire un push, qu'il soit force ou pas. Tu passes par une MR/PR via une branche de travail, et tu ne commit jamais directement sur les branches d'intégration.

[Henry22]

Je te remercie pour ton explication.