J'ai utilisé git pull
et j'ai eu un conflit de fusion:
unmerged: _widget.html.erb
You are in the middle of a conflicted merge.
Je sais que l'autre version du fichier est bonne et que la mienne est mauvaise, alors toutes mes modifications doivent être abandonnées. Comment puis-je faire ceci?
Puisque votre pull
a échoué, alors HEAD
(et non HEAD^
) est le dernier commit "valide" sur votre branche:
git reset --hard HEAD
L’autre élément que vous souhaitez est de laisser leurs modifications prendre le pas sur vos modifications.
Les anciennes versions de git vous permettaient d'utiliser la stratégie de fusion "leur":
git pull --strategy=theirs remote_branch
Mais cela a depuis été supprimé, comme expliqué dans ce message de Junio Hamano (le responsable de Git). Comme indiqué dans le lien , vous feriez plutôt ceci:
git fetch Origin
git reset --hard Origin
Si votre version de git est> = 1.6.1, vous pouvez utiliser git reset --merge
.
De plus, comme le mentionne Michael Johnson, si votre version de git est> = 1.7.4, vous pouvez également utiliser git merge --abort
.
Comme toujours, assurez-vous de ne pas avoir de modifications non validées avant de commencer une fusion.
Depuis le page de manuel de git merge
git merge --abort
est équivalent à git reset --merge
lorsque MERGE_HEAD
est présent.
MERGE_HEAD
est présent lorsqu'une fusion est en cours.
En outre, en ce qui concerne les modifications non validées lors du démarrage d’une fusion:
Si vous avez des modifications que vous ne voulez pas valider avant de commencer une fusion, il vous suffit de git stash
les avant la fusion et de git stash pop
après avoir terminé ou annulé la fusion.
git merge --abort
Abandonnez le processus de résolution de conflit en cours et essayez de reconstituer l'état de pré-fusion.
S'il y avait des modifications de l'arbre de travail non validées présentes au démarrage de la fusion,
git merge --abort
sera dans certains cas incapable de reconstruire ces modifications. Il est donc recommandé de toujours valider ou de cacher vos modifications avant d'exécuter git merge.
git merge --abort
est équivalent àgit reset --merge
lorsqueMERGE_HEAD
est présent.
C'est tellement simple.
git merge --abort
Git lui-même vous montre la solution lorsque vous rencontrez ce type de problème et exécutez la commande git status.
git status
J'espère que cela aidera les gens.
Je pense que c'est git reset
dont vous avez besoin.
Attention, git revert
signifie quelque chose de très différent de, par exemple, svn revert
- dans Subversion, l'annulation annulera vos modifications (non validées), renvoyant le fichier à la version actuelle du référentiel, tandis que git revert
"annule" un commit.
git reset
doit faire l'équivalent de svn revert
, c'est-à-dire ignorer les modifications non souhaitées.
Dans ce cas d'utilisation particulier, vous ne voulez pas vraiment annuler la fusion, mais simplement résoudre le conflit d'une manière particulière.
Il n'est pas particulièrement nécessaire de réinitialiser et d'effectuer une fusion avec une stratégie différente non plus. Les conflits ont été correctement mis en évidence par git et l'obligation d'accepter les modifications des autres côtés ne concerne que ce fichier.
Pour un fichier non fusionné dans un conflit, git met à disposition les versions de base commune, locale et distante du fichier dans l'index. (C'est ici qu'ils sont lus pour être utilisés dans un outil de diff à 3 voies par git mergetool
.) Vous pouvez utiliser git show
pour les afficher.
# common base:
git show :1:_widget.html.erb
# 'ours'
git show :2:_widget.html.erb
# 'theirs'
git show :3:_widget.html.erb
Le moyen le plus simple de résoudre le conflit pour utiliser la version distante mot à mot est:
git show :3:_widget.html.erb >_widget.html.erb
git add _widget.html.erb
Ou, avec git> = 1.6.1:
git checkout --theirs _widget.html.erb
Comme les commentaires suggèrent que git reset --merge
est un alias pour git merge --abort
, il est intéressant de noter que git merge --abort
n’est équivalent qu’à git reset --merge
étant donné qu’un MERGE_HEAD
_ est présent. Cela peut être lu dans l'aide de git pour la commande de fusion.
git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.
Après une fusion échouée, quand il n’ya pas de MERGE_HEAD
, elle peut être annulée avec git reset --merge
mais pas nécessairement avec git merge --abort
, elles ne sont donc pas uniquement anciennes et nouvelles). pour la même chose.
Personnellement, je trouve git reset --merge
beaucoup plus puissant pour des scénarios similaires à celui décrit, et les fusions échouées en général.
Et si vous vous retrouvez avec un conflit de fusion et que vous n'avez rien à commettre mais que l'erreur de fusion est affichée après l'application de toutes les commandes mentionnées ci-dessous,
git reset --hard HEAD
git pull --strategy=theirs remote_branch
git fetch Origin
git reset --hard Origin
s'il vous plaît retirer
. git\index.lock
file [copier coller à un autre endroit en cas de récupération] puis entrez l’une des commandes ci-dessous en fonction de la version souhaitée.
git reset --hard HEAD
git reset --hard Origin
J'espère que ça t'as aidé!!!
Depuis Git 1.6.1.3 git checkout
a été en mesure de passer la commande de l’un ou l’autre des points de la fusion:
_git checkout --theirs _widget.html.erb
_
Une alternative qui préserve l’état de la copie de travail est la suivante:
git stash
git merge --abort
git stash pop
Je déconseille généralement cela, car c'est en fait une fusion avec Subversion qui jette les relations de branche dans le commit suivant.
Pour un scénario comme celui-ci, j'ai fait git fetch
et git pull
, puis j'ai réalisé que la branche en amont n'était pas une branche principale, ce qui entraînait des conflits indésirables.
git reset -merge
Ceci est revenu en arrière sans réinitialiser mes modifications locales.
J'ai trouvé ce qui suit fonctionné pour moi (rétablissez un fichier avant l'état de fusion):
git reset *currentBranchIntoWhichYouMerged* -- *fileToBeReset*