Comment annuler le push git d'un autre développeur sur la branche master ?

Question

Cela semble devoir arriver tout le temps, mais je ne trouve pas de réponse.

ce qui s'est passé :

Un autre développeur a git merge d une branche avec la branche maîtresse sur leur serveur local, ce qui donne lieu à conflits . Ensuite, git add les conflits, git commit ted, et git push ed les changements et conflits vers la branche master. Il a laissé tomber son micro et a quitté le bâtiment :

la question :

existe-t-il un moyen pour moi d'annuler ce dernier commit conflictuel, afin que je puisse pousser mes changements de code vers master et continuer ma journée, laissant l'autre développeur corriger le code conflictuel sur sa machine locale ? ???

---

ce que j'ai trouvé jusqu'à présent :

J'ai déjà validé mes modifications locales et j'ai transféré le "commit conflictuel" sur mon serveur local...

les deux options que je trouve sont :

option 1 :

git revert -m 1 <conflicted commit>

Cela annulera tous les changements faits par le commit en conflit. mais quand l'autre développeur fait un git pull, tous ses changements seront supprimés. n'est-ce pas ?

option 2 :

git reset --hard <my commit>;
git push --force;

Cela supprimera complètement le commit en conflit de git comme s'il n'était jamais arrivé (ce que je n'aime pas). Mais maintenant, le serveur local des autres développeurs ne sera plus synchronisé.

que feriez-vous ?

Answer 1

S'il s'agit d'un seul commit que vous voulez annuler, la manière la plus sûre de réparer est votre première option :

git revert -m 1 <conflicted commit>

En général, il est dangereux d'utiliser git reset sur tout commit qui se trouve sur le référentiel distant. Si quelqu'un a cloné le dépôt depuis que ces changements ont été poussés et a fait ses propres changements, il aura des problèmes quand il essaiera de se synchroniser avec git pull . Il y a un "commit orphelin" avec une "tête pendante". Bien que ces deux choses puissent être contournées avec le temps, il n'y a aucune raison de s'attirer ce type de problème s'il peut être résolu avec un simple git revert .

Answer 2

Il se peut que la solution la plus simple soit la meilleure, surtout si aucun autre changement n'a été effectué. Il suffit de faire un git checkout pour le commit avant son push et le re-committing de ces fichiers laissera toujours l'autre développeur avec l'historique de ce qui a été fait, tout en résolvant les problèmes que vous avez avec l'état conflictuel. Un inconvénient de cette approche, cependant, est qu'elle laisse du code en conflit/non-compilation dans votre dépôt.

Answer 3

Je pense que vous devez améliorer votre flux de travail. Il n'est pas bon et sûr de permettre à chacun de mettre à jour les branches principales du serveur. D'ailleurs, git push --force est trop dangereux, et vous ne devriez jamais l'utiliser sur une branche publique dans un travail d'équipe. Vous pouvez autoriser tout push vers une branche non principale. Une équipe de révision du code examine les changements et fusionne les commits dans les branches principales en git merge , git cherry-pick , git rebase , git apply , git am etc. Une fois qu'un commit est fait sur la branche principale, utilisez seulement git revert pour le défaire. Les développeurs pourraient utiliser git pull --rebase pour synchroniser les changements locaux avec la dernière branche principale si nécessaire. Ils peuvent également git fetch la branche principale et organisent leurs propres commits sur celle-ci.