j'ai utilisé git pull et a 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 donc tous mes changements devraient être abandonnés. Comment puis-je faire ceci?
Depuis votre pull a échoué alors HEAD (ne pas HEAD^) est le dernier commit "valide" sur votre branche:
git reset --hard HEAD
L'autre pièce que vous voulez est de laisser leurs changements prendre le pas sur vos changements.
Les anciennes versions de git vous ont permis d'utiliser la stratégie de fusion "theirs":
git pull --strategy=theirs remote_branch
Mais cela a depuis été retiré, comme expliqué dans ce message de Junio Hamano (le mainteneur Git). Comme indiqué dans le lien, au lieu de cela, vous feriez ceci:
git fetch origin
git reset --hard origin
Si votre version git est> = 1.6.1, vous pouvez utiliser git reset --merge.
Aussi, comme le mentionne Michael Johnson, si votre version git est> = 1.7.4, vous pouvez également utiliser git merge --abort.
Comme toujours, assurez-vous que vous n'avez pas de modifications non validées avant de commencer une fusion.
git merge --abort est équivalent à git reset --merge quand MERGE_HEAD est présent.
MERGE_HEAD est présent lorsqu'une fusion est en cours.
En outre, concernant 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, git stash eux avant la fusion et git stash pop après avoir fini la fusion ou l'avoir abandonnée.
git merge --abort
Abandonner le processus actuel de résolution des conflits et essayer de reconstruire l'état de pré-fusion.
S'il y avait des modifications non validées de worktree lors de la fusion commencé,
git merge --abortsera dans certains cas incapable de reconstruire ces changements. Il est donc recommandé de toujours valider ou stocker vos modifications avant d'exécuter git merge.
git merge --abortest équivalent àgit reset --mergequandMERGE_HEADest présent.
Dans ce cas d'utilisation particulier, vous ne voulez pas vraiment annuler la fusion, résolvez simplement le conflit d'une manière particulière.
Il n'y a pas non plus besoin de réinitialiser et d'effectuer une fusion avec une stratégie différente. Les conflits ont été correctement mis en évidence par git et l'exigence d'accepter les changements des autres côtés est seulement pour ce fichier.
Pour un fichier non fusionné dans un conflit, git met à disposition la base commune, les versions locales et distantes du fichier dans l'index. (C'est ici qu'ils sont lus pour une utilisation dans un outil de comparaison à trois git mergetool.) Vous pouvez utiliser git show pour les voir.
# 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 verbatim 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
je pense que c'est git reset vous avez besoin.
Méfiez-vous que git revert signifie quelque chose de très différent de, disons, svn revert - dans Subversion, la restauration 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 devrait faire l'équivalent de svn revert, c'est-à-dire, défaussez vos changements non désirés.
Puisque les commentaires suggèrent que git reset --merge est un alias pour git merge --abort, il vaut la peine de noter que git merge --abort est seulement équivalent à git reset --mergeétant donné qu'un MERGE_HEAD est présent. Cela peut être lu dans la commande git help for merge.
git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.
Après une fusion échouée, quand il n'y a pas MERGE_HEAD, la fusion échouée peut être annulée avec git reset --merge mais pas nécessairement avec git merge --abort, donc ils ne sont pas seulement ancienne et nouvelle syntaxe pour la même chose.
Personnellement je trouve git reset --merge beaucoup plus puissant pour les scénarios similaires à celui décrit, et les fusions échouées en général.
Depuis Git 1.6.1.3 git checkout a été en mesure de vérifier de chaque côté d'une fusion:
git checkout --theirs _widget.html.erb