Comment forcer "git pull" à écraser les fichiers locaux?

Comment forcer "git pull" à écraser les fichiers locaux?

Comment forcer un écrasement de fichiers locaux sur un git pull ?

Le scénario est le suivant:

  • Un membre de l'équipe modifie les modèles d'un site Web sur lequel nous travaillons
  • Ils ajoutent des images au répertoire images (mais oublient de les ajouter sous contrôle de code source)
  • Ils m'envoient les images par e-mail, plus tard,
  • J'ajoute les images sous le contrôle de code source et les pousse vers GitHub avec d'autres modifications
  • Ils ne peuvent pas extraire les mises à jour de GitHub car Git ne veut pas écraser leurs fichiers.

Voici l'erreur que j'obtiens:

erreur: le fichier d'arborescence de travail non suivi 'public / images / icon.gif' serait écrasé par la fusion

Comment forcer Git à les écraser? La personne est un concepteur - généralement, je résous tous les conflits à la main, donc le serveur a la version la plus récente dont il a juste besoin pour mettre à jour sur son ordinateur.

Montrez la meilleure réponse

toute personne lisant ceci qui pense qu'elle pourrait perdre des fichiers, j'ai été dans cette position et j'ai trouvé que le tampon de Sublime Text m'a sauvé - si je travaille sur quelque chose, supprimez accidentellement tout en essayant de résoudre un problème similaire à celui-ci ou en utilisant une réponse à cette question et que les fichiers ont été ouverts dans Sublime (ce qui est fort probable), alors les fichiers seront toujours là est Sublime, soit juste là, soit dans l'historique des annulations

git reset --hard origin/branch_to_overwrite

en gros, n'effectuez une extraction de develop qu'après la vérification initiale -b. faites votre travail, puis repoussez.

Réponse courte: supprimez et recréez la branche. 1. Supprimer la branche: git branch <branch> -D 2. Réinitialiser sur un commit avant le conflit: git reset <commit> --hard 3. Recréer la branche: git branch <branch> 4. Régler le suivi sur le serveur: git --set-upstream-to=origin/<branch> <branch> 5. Pull: git pull`

Pour changer tous les CRLF en terminaisons LF, (start clean) git config core.autocrlf false; git ls-files -z | xargs -0 rm; git checkout .

Vous recherchez peut-être cette question à la place: stackoverflow.com/q/1628088/1148030 "Réinitialiser la branche du référentiel local pour être tout comme le référentiel distant HEAD "Par exemple, si la télécommande a été poussée de force et que vous voulez la retirer et supprimer l'incarnation précédente de la branche que vous avez. (Certaines autres questions désignent cette question comme leur double, mais je pense qu'elles devraient pointer vers cette autre question.)

Supprimez manuellement tous les fichiers et dossiers du référentiel local. Ensuite, exécutez git checkout <branch> && git add -A . && git reset --hard origin/<branch> && git pull . Voir stackoverflow.com/a/65239330 .

Il y a certainement une réponse à cela parce que je l'ai fait par accident. Maintenant, plusieurs semaines de travail ont disparu :(

Il semble que le meilleur moyen soit de faire d'abord:

git clean
 

Pour supprimer tous les fichiers non suivis, puis continuer avec le git pull habituel ...

J'ai essayé d'utiliser "git clean" pour résoudre le même problème, mais cela ne l'a pas résolu. git status indique "Votre branche et 'origin / master' ont divergé, # et ont respectivement 2 et 9 commit (s) différents." et git pull dit quelque chose de similaire à ce que vous avez ci-dessus.

n'aurait-il pas besoin de passer à la branche master puis de faire git clean pour que cela fonctionne? Ensuite, il peut revenir à la branche de développement à partir de laquelle il travaillait.

@slacy: Ensuite, vous devez fusionner les deux branches.

git clean est un instrument assez émoussé, et pourrait jeter beaucoup de choses que vous voudrez peut-être conserver. Mieux vaut supprimer ou renommer les fichiers dont git se plaint jusqu'à ce que l'extraction réussisse.

Je ne pense pas que cela fonctionne en général. N'y a-t-il pas un moyen de faire essentiellement une télécommande git clone via un pull git forcé?

@mathick: git fetch origin && git reset --hard origin/master

J'avais besoin d'ajouter un -x à ce git clean pour qu'il fonctionne pour moi, pour une raison quelconque (-d ne supprimait pas un .ideas répertoire pour une raison quelconque), mais cela a résolu mon problème, certainement.

éviter un arrêt cardiaque soudain: utilisez d'abord git clean -n

git clean est-il la meilleure réponse ici? On dirait que la suppression de fichiers n'est pas nécessairement ce que veut l'OP. Ils ont demandé «un écrasement des fichiers locaux» et non une suppression.

git clean en lui-même ne semble pas aider, la solution de @Arrowmaster est plus proche, mais une meilleure de Lloyd Moore est dans la réponse suivante.

Ne faites jamais rien de 'git' (ou même ayez un dossier .git) sauf dans une copie de votre dossier de travail réel, et évitez tout stress cardiaque. Ne donnez pas à git et à sa syntaxe / méthodes obtuses l'occasion de vous ruiner en premier lieu.

Essayez ceci:

git reset --hard HEAD
git pull
 

Il doit faire ce que vous voulez.

J'ai fait cela et certains fichiers locaux qui n'étaient plus dans le dépôt ont été laissés sur le disque.

Je ne pense pas que ce soit correct. le ci-dessus effectuera une fusion, pas un écrasement qui a été demandé dans la question: "Comment forcer git à les écraser?" Je n'ai pas la réponse, je la cherche actuellement .. pour le moment je passe à la branche avec le code que je veux garder "git checkout BranchWithCodeToKeep", puis fais "git branch -D BranchToOverwrite" et enfin enfin "git checkout -b BranchToOverwrite". vous aurez maintenant le code exact de BranchWithCodeToKeep sur la branche BranchToOverwrite sans avoir à effectuer une fusion.

au lieu de fusionner en utilisant 'git pull', essayez git fetch --all suivi de 'git reset --hard origin / master'

La suggestion de Lloyd Moore est correcte, mais sachez qu'elle peut supprimer les commits locaux non poussés de votre branche.

oui, la solution @lloydmoore a fonctionné pour moi. Cela pourrait être une réponse plutôt qu'un simple commentaire.

Cela réinitialisera les modifications actuelles au dernier commit de branche tiré. Ensuite, git pull fusionne les modifications de la dernière branche. Cela a fait exactement ce que je voulais qu'il fasse. Merci!

Cela va-t-il gâcher la télécommande?

Bonne réponse, mais veuillez ajouter plus de détails, je veux dire que certaines personnes peuvent ne rien savoir de la réinitialisation et perdre leurs fichiers ...

@Travis R pourriez-vous s'il vous plaît expliquer le but de git rest --hard HEAD?

git reset --hard HEAD ne réinitialise pas vraiment tout dans certains cas

C'est surtout ce à quoi je pense quand je pense à forcer l'attraction. Surtout après avoir essayé certains paramètres

Vous trouverez peut-être cette commande utile pour supprimer les modifications locales:

git checkout <your-branch> -f
 

Et ensuite faire un nettoyage (supprime les fichiers non suivis de l'arborescence de travail):

git clean -f
 

Si vous souhaitez supprimer des répertoires non suivis en plus des fichiers non suivis:

git clean -fd
 

Je pense que la description du scénario montre clairement qu'il ne veut pas vraiment jeter le contenu. Ce qu'il veut, c'est plutôt arrêter git de reculer lors de l'écrasement des fichiers. Voir ma suggestion.

Bien que cette réponse ne corresponde pas exactement à la description, elle m'a quand même évité la frustration de jouer avec les retours chariot (événement avec autocrlf false). Lorsque git reset --hard HEAD ne vous laisse pas avec "aucun" fichier modifié, ces indicateurs "-f" sont très utiles. Merci beaucoup.

Vous pouvez ignorer ce fichier avec un fichier dans le dossier de base de votre projet:

.gitignore

public/images/*
 

Ensuite, récupérez les modifications, puis supprimez cette ligne de votre fichier gitignore.

Je viens de résoudre ce problème moi-même en:

 git checkout -b tmp # "tmp" or pick a better name for your local changes branch
git add -A
git commit -m 'tmp'
git pull
git checkout master # Or whatever branch you were on originally
git pull
git diff tmp
  

où la dernière commande donne une liste de vos modifications locales. Continuez à modifier la branche "tmp" jusqu'à ce qu'elle soit acceptable, puis fusionnez à nouveau sur master avec:

git checkout master && git merge tmp
 

Pour la prochaine fois, vous pourrez probablement gérer cela de manière plus propre en recherchant "git stash branch" bien que stash soit susceptible de vous causer des problèmes lors des premiers essais, alors faites une première expérience sur un projet non critique. .

J'ai eu le même problème. Personne ne m'a donné cette solution, mais cela a fonctionné pour moi.

Je l'ai résolu par:

  1. Supprimez tous les fichiers. Ne laissez que le répertoire .git .
  2. git reset --hard HEAD
  3. git pull
  4. git push

Maintenant, ça marche.

Pareil ici. Parfois, seule la solution très difficile fonctionne, il arrive souvent que seuls la réinitialisation et le nettoyage ne suffisent pas d'une manière ou d'une autre ...

J'ai eu un problème similaire. Je devais faire ceci:

git reset --hard HEAD
git clean -f
git pull
 

utilisez git clean avec prudence

AVERTISSEMENT: git clean supprime tous vos fichiers / répertoires non suivis et ne peut pas être annulé.


Parfois, simplement clean -f n'aide pas. Si vous avez des RÉPERTOIRES non suivis, l'option -d est également nécessaire:

# WARNING: this can't be undone!

git reset --hard HEAD
git clean -f -d
git pull
 

AVERTISSEMENT: git clean supprime tous vos fichiers / répertoires non suivis et ne peut pas être annulé.

Pensez à utiliser d'abord l'indicateur -n (--dry-run ). Cela vous montrera ce qui sera supprimé sans rien supprimer:

git clean -n -f -d
 

Exemple de sortie:

Would remove untracked-file-1.txt
Would remove untracked-file-2.txt
Would remove untracked/folder
...
 

Vous pouvez donner à git clean un argument de chemin pour être plus spécifique et éviter de supprimer les fichiers non suivis qui ne sont pas en conflit.

Je pense que la description du scénario montre clairement qu'il ne veut pas vraiment jeter le contenu. Ce qu'il veut, c'est plutôt arrêter git de reculer lors de l'écrasement des fichiers. @Lauri, cela n'aurait pas dû vous arriver. Malheureusement, les gens semblent avoir mal interprété l'essence de la description du scénario - voir ma suggestion.

ENFIN . git clean -f -d est pratique lorsque make clean ne parvient pas à tout nettoyer.

Si vous souhaitez synchroniser tout le répertoire avec le référentiel distant, c'est la voie à suivre.

@crizCraig sauf s'ils sont ajoutés dans .gitignore

@BleedingFingers Puis ajoutez -x . Mais les fichiers existants qui sont couverts par .gitignore ne devraient pas être un problème: en supposant que les autres contributeurs à ce dépôt utilisent le même fichier .gitignore , un pull ne recevra pas de commits qui ajoutent fichiers en conflit.

@earthmeLon, pour cela, vous voudrez peut-être git clean -dfx . Le -x ignore .gitignore. En règle générale, vos produits de construction seront au format .gitignore.

Il peut être bon d'exécuter d'abord git clean -nfd , ce qui ne montre que ce qui serait supprimé avant que cela ne soit réellement fait, c'est-à-dire avant de rencontrer des problèmes. :-)

La seule chose qui a fonctionné pour moi était:

git reset --hard HEAD~5
 

Cela vous ramènera cinq commits, puis avec

git pull
 

J'ai trouvé cela en recherchant comment annuler une fusion Git .

C'est ce qui a finalement fonctionné pour moi, car j'avais poussé de force ma branche vers le dépôt d'origine et continuais à avoir des conflits de fusion en essayant de la transférer vers mon dépôt distant.

Salut, en fait c'est une astuce pour un work around mais vraiment efficace. Étant donné que certains conflits peuvent se produire juste en quelques validations, la restauration de 5 validations garantira qu'il n'y aura pas de conflit avec le code distant.

J'ai eu le même problème et pour une raison quelconque, même un git clean -f -d ne le ferait pas. Voici pourquoi: pour une raison quelconque, si votre fichier est ignoré par Git (via une entrée .gitignore, je suppose), cela dérange toujours de l'écraser avec un pull plus tard, mais un clean ne le supprimera pas, sauf si vous ajoutez -x .

J'ai une situation étrange où ni git clean ni git reset ne fonctionnent. Je dois supprimer le fichier en conflit de git index en utilisant le script suivant sur chaque fichier non suivi:

git rm [file]
 

Ensuite, je suis capable de tirer très bien.

Je pense qu'il y a deux causes possibles de conflit, qui doivent être résolues séparément, et pour autant que je sache, aucune des réponses ci-dessus ne traite des deux:

  • Les fichiers locaux non suivis doivent être supprimés, soit manuellement (plus sûr), soit comme suggéré dans d'autres réponses, par git clean -f -d

  • Les commits locaux qui ne sont pas sur la branche distante doivent également être supprimés. OMI, le moyen le plus simple d'y parvenir est de: git reset --hard origin/master (remplacez 'master' par la branche sur laquelle vous travaillez et lancez d'abord un git fetch origin )

Avatar RNA
Réponse acceptée

⚠ Important: si vous avez des modifications locales, elles seront perdues. Avec ou sans l'option --hard , tous les commits locaux qui n'ont pas été poussés seront perdus. [*]

Si vous avez des fichiers qui ne sont pas suivis par Git (par exemple, le contenu utilisateur téléchargé), ces fichiers ne seront pas affectés.

Commencez par lancer une extraction pour mettre à jour toutes les références origin/<branch> vers les dernières:

git fetch --all
 

Sauvegardez votre branche actuelle:

git checkout -b backup-master
 

Ensuite, vous avez deux options:

git reset --hard origin/master
 

OU Si vous êtes sur une autre branche:

git reset --hard origin/<branch_name>
 

Explication:

git fetch télécharge la dernière à distance sans essayer de fusionner ou de rebaser quoi que ce soit.

Ensuite, le git reset réinitialise la branche principale à ce que vous venez de récupérer. L'option --hard modifie tous les fichiers de votre arbre de travail pour qu'ils correspondent aux fichiers de origin/master

Maintenir les commits locaux actuels

[*] : Il convient de noter qu'il est possible de maintenir les commits locaux actuels en créant une branche à partir de master avant de réinitialiser:

git checkout master
git branch new-branch-to-save-current-commits
git fetch --all
git reset --hard origin/master
 

Après cela, tous les anciens commits seront conservés dans new-branch-to-save-current-commits .

Modifications non validées

Cependant, les modifications non validées (même par étapes) seront perdues. Assurez-vous de cacher et de valider tout ce dont vous avez besoin. Pour cela, vous pouvez exécuter ce qui suit:

git stash
 

Et puis pour réappliquer ces modifications non validées:

git stash pop
 

Attention! Si vous avez des commits locaux non poussés, cela les supprimera de votre branche! Cette solution conserve les fichiers non suivis non dans le référentiel intacts, mais écrase tout le reste.

Avatar Red

C'est une question populaire, alors j'aimerais clarifier le commentaire principal ici. Je viens d'exécuter des commandes comme décrit dans cette réponse et cela n'a pas supprimé TOUS les fichiers locaux. Seuls les fichiers suivis à distance ont été écrasés et tous les fichiers locaux qui se trouvaient ici n'ont pas été modifiés.

J'ai perdu tous les commits locaux qui n'étaient pas dans l'arborescence origin/master après un rebase. Il est très possible de se tirer une balle dans le pied, ici.

Vous pouvez également le faire pour une branche de suivi si vous avez la même branche à l'origine et localement, changez simplement git reset --hard origin / master en git reset --hard origin / (branch)

au cas où vous tirez d'un dépôt dont le nom de la branche distante est différent de "master", utilisez git reset --hard origin/branch-name

Cela devrait être la réponse acceptée. Fonctionne bien pour moi. Je suppose que l'hypothèse ici est que vous n'avez pas de commits locaux, ce qui dans mon cas est bon car le "local" ne possède qu'une clé de déploiement.

Avatar mcv

Cela ne va-t-il pas également rejeter mes engagements locaux? Je souhaite conserver mes validations et n'écraser que les modifications non suivies / non validées.

J'utilise juste "git fetch" pour obtenir la branche amont, puis je le réinitialise lorsque j'ai besoin de réparer un tas de fichiers. Vous pouvez obtenir la branche amont avec "git branch -vv"

@mcv Pour conserver vos commits locaux, vous voulez git reset --hard HEAD que vous pourrez ensuite suivre par git merge origin/master .

Compte tenu du nombre de votes positifs pour cette question et réponse, je pense que git devrait incorporer une commande comme git pull -f

Les commits qui n'étaient pas poussés avant la réinitialisation matérielle peuvent être récupérés en utilisant git reflog , qui répertorie tous les commits, même ceux sans base. Tant que vous n’avez pas nettoyé votre copie locale à l’aide de git gc , tout est perdu

Est-ce que cela supprimera les fichiers que j'ai .gitignore'd?

@FelipeSchenone Il y a en fait git pull -f , mais il ne fait pas ce que nous voulons tous qu'il fasse.

Pour être correct, les modifications non validées sont perdues mais les anciennes validations sont en suspens, en attente de récupération de place. Vous pouvez toujours les voir dans git reflog et déplacer votre HEAD avec git reset --hard HEAD@{1} .

Vous voulez souligner ici qu'il supprimera également toutes les modifications apportées dans toute autre branche qui ne sont pas suivies à distance. J'ai perdu le mien, j'espère que les autres seront prudents.

Sauvegardez le dossier avec vos fichiers locaux, y compris le dossier .git. Maintenant, vous ne pouvez rien «perdre» si ce correctif ne fonctionne pas pour vous; vous pouvez faire une autre copie et essayer autre chose. N'opérez pas à partir d'un seul dossier et faites confiance à git comme s'il s'agissait d'un outil de sauvegarde fiable à 100%. Une faute de frappe, en particulier dans les succursales, peut être un cauchemar. Je suggère une sauvegarde de l'ancienne école dans les dossiers tar.gz, puis exécutez git à partir de la dernière copie.

@Red Oui, si vous voulez supprimer tout ce qui n'est pas suivi, même ignoré, utilisez git clean -dxf après avoir réinitialisé hard.

Je l'ai fait et mes modifications locales n'ont PAS été supprimées - ce qui est regrettable car j'espérais qu'elles le seraient! Est-ce que quelqu'un sait comment faire cela, mais oblige également git à ignorer les changements de paramètres régionaux qui n'existent pas dans la branche distante? Je veux essentiellement une correspondance EXACTE, 1 à 1 avec la succursale distante.

Fait peu connu - vous pouvez en fait sauvegarder tout votre dépôt git avec du bon vieux tar -czf myrepodir.tar.gz myrepodir/. . Si votre dépôt est complètement gâché en raison de la bizarrerie de git, supprimez-le et restaurez-le à partir du fichier tar.gz pour RÉELLEMENT revenir là où vous étiez avant d'essayer cette expérience malheureuse. Assurez-vous simplement d'avoir le . après myrepodir/ ou votre .git et les autres fichiers cachés ne seront pas enregistrés!

cette technique peut-elle fonctionner pour des fichiers individuels? par exemple -- index.php helpers.js ect. à la place de --all ?

n'a pas fonctionné pour moi. essayé cette solution, essayé git clean -dfx . essayé git pull -f . ont toujours le même message d'erreur.

Notez que vous pouvez abréger le nom de la branche par @{u} , ce qui est beaucoup plus court.

@GershomMaes git clean -dfx après une réinitialisation matérielle, comme mentionné ci-dessus par IceGlow ?

n'est-il pas plus simple de rm -rf / folder et de refaire le clonage git, si vous voulez annuler toutes vos modifications locales?

Lorsque vous utilisez git clean -dffx , assurez-vous de l'exécuter depuis le répertoire de premier niveau du projet git . C'est une bonne idée d'exécuter git clean -ndffx d'abord pour lister les fichiers avant qu'ils ne soient supprimés, car l'option -x supprime les fichiers qui sont .gitignored et non affichés par git status

Avatar Sz.

@JonB: "n'est-il pas plus simple de rm -rf / dossier et de refaire un clonage git ...?" Un (même pas trop) gros repo + faible bande passante m'a amené ici. J'adorerais simplement cloner à nouveau, mais c'était déjà assez douloureux la première fois, donc je fais partie de ceux qui recherchent une solution plus rapide.

a fonctionné pour moi lorsque la branche source contenait des mises à jour telles que les noms de fichiers de «général» à «général». Sous Windows, le cas n'a pas d'importance, donc cette approche m'a débloqué.

Mercurial a hg update mais il n'y a pas d'équivalent dans git ...

Ce serait plus cohérent si vous pouviez faire git pull --force et cela écraserait simplement votre branche locale. Vu que vous pouvez faire le contraire, écraser la télécommande par git push --force

J'ai perdu tous mes commits locaux avec vos suggestions de commandes.

Notez que la branche master est maintenant appelée branche principale par défaut, alors faites attention aux copieurs, car ces commandes risquent de ne plus fonctionner.

Pardon. Trop compliqué. Il suffit de supprimer et de cloner à nouveau à la place ...

Si vous exécutez git checkout -b backup-master, vous devez revenir à votre branche (master dans l'exemple) avant d'exécuter git reset. Sinon, vous pouvez utiliser git branch backup-master à la place pour créer la branche de sauvegarde tout en restant maître.

Attention, cela supprimera définitivement vos fichiers si vous avez des entrées de répertoire / * dans votre fichier gitignore.

Certaines réponses semblent terribles. Terrible dans le sens de ce qui est arrivé à @Lauri en suivant la suggestion de David Avsajanishvili.

Plutôt (git> v1.7.6):

git stash --include-untracked
git pull
 

Plus tard, vous pourrez nettoyer l'historique de la réserve.

Manuellement, un par un:

$ git stash list
stash@{0}: WIP on <branch>: ...
stash@{1}: WIP on <branch>: ...

$ git stash drop stash@{0}
$ git stash drop stash@{1}
 

Brutalement, tout à la fois:

$ git stash clear
 

Bien sûr, si vous voulez revenir à ce que vous avez caché:

$ git stash list
...
$ git stash apply stash@{5}
 

Ne partez-vous pas du principe qu’un commit n’a jamais été effectué? Dans mon cas, j'ai effectué plusieurs commits dans ma branche locale, mais je voulais tout "réinitialiser" tout dans la branche distante

Non je ne pense pas. Le stockage ne fait que déplacer les fichiers non validés. Ce qui précède déplace également (cache) les fichiers que git ne suit pas. Cela empêche les fichiers qui ont été ajoutés à la télécommande, qui n'ont pas encore été extraits sur votre machine - mais que vous avez créés (!) - d'être extraits. Le tout sans détruire le travail non engagé. J'espère que cela a du sens?

Si vous n'avez pas 1.7.6, vous pouvez imiter --include-untracked simplement en git add -ing temporairement votre dépôt entier, puis en le cachant immédiatement.

Je suis d'accord avec Hedgehog. Si vous suivez les réponses les plus courantes ici, vous constaterez très probablement que vous avez tué par inadvertance beaucoup de choses que vous ne vouliez pas vraiment perdre.

J'avais d'autres fichiers non suivis - en plus de celui que la fusion / extraction voulait écraser, donc cette solution fonctionnait le mieux. git stash apply a ramené tous mes fichiers non suivis à l'exception (à juste titre) de ceux que la fusion avait déjà créés: «existe déjà, pas de retrait». A parfaitement fonctionné.

Cela peut être le moyen le plus simple de supprimer un dépôt involontairement, tout comme ce qui est arrivé à @Lauri, mais pire parce que vous pensez que vous protégez les fichiers de la suppression. Si vous avez une règle .gitignore qui contient un caractère générique, dites-leur au revoir. Explication.

C'est la réponse la plus claire et devrait être la réponse acceptée. Pour enregistrer un peu de saisie, vous pouvez utiliser la forme abrégée: git stash -u .

Le lien sur git stash --include-untracked détruisant les dossiers qui sont gitignored est mort - trouvons un remplacement. En attendant, le commentaire @Waif sur comment cette réponse peut détruire les dossiers gitignore'd devrait être voté pour et de préférence converti en une nouvelle réponse. Le problème GitLab que vous avez lié a des détails. J'utilise beaucoup git stash et j'ai été très surpris d'entendre qu'il pouvait détruire des fichiers.

Comme Hedgehog, je pense que les réponses sont terribles. Mais bien que la réponse de Hedgehog puisse être meilleure, je ne pense pas qu'elle soit aussi élégante qu'elle pourrait l'être. La façon dont j'ai trouvé pour faire cela est d'utiliser fetch et merge avec une stratégie définie. Ce qui devrait faire en sorte que vos modifications locales soient conservées tant qu'elles ne font pas partie des fichiers avec lesquels vous essayez de forcer un écrasement.

Commencez par valider vos modifications

 git add *
 git commit -a -m "local file server commit message"
 

Récupérez ensuite les modifications et écrasez-les en cas de conflit

 git fetch origin master
 git merge -s recursive -X theirs origin/master
 

-X est un nom d'option et theirs est la valeur de cette option. Vous choisissez d'utiliser les modifications their (l'autre option est les modifications ours ) en cas de conflit.

C'est la meilleure réponse que j'ai vue jusqu'à présent. Je ne l'ai pas essayé, mais contrairement à d'autres réponses, cela ne tente pas de détruire tous vos fichiers non suivis, ce qui est très dangereux pour des raisons évidentes.

Idem - cela a fonctionné pour moi lors d'une très grande fusion (pull request GitHub) où je voulais simplement tout accepter en plus de ce que j'avais. Bonne réponse! Dans mon cas, les deux dernières commandes étaient: 1) get fetch other-repo ; 2) git merge -s recursive -X theirs other-repo/master

Cela écrasera tous les conflits avec les fichiers du référentiel et non avec vos fichiers locaux, n'est-ce pas?

Meilleure réponse. La réponse la plus élevée acceptée m'a laissé dans mon cas sur la tête détachée. Je suis revenu à la branche principale locale et j'ai exécuté git merge -X theirs origin/master

J'ai essayé ceci - puis ajoutez / validez mes nouveaux fichiers modifiés, mais j'ai tout de même dit que ma branche était derrière la télécommande lorsque j'ai essayé de pousser. Beaucoup de temps perdu car "git pull" ne demande pas "Overwrite local? Y / n / all".

Accrochez-vous ... n'a pas git add * et git commit -a <more-options-here> ont le même effet? Pourquoi auriez-vous besoin des deux?

@ MarcelStör vous n'avez pas besoin des deux mais ils ne font pas non plus la même chose. git commit -a n'a cet effet que sur les fichiers déjà suivis; git add * ajoutera des fichiers qui ne sont pas suivis. Donc, si vous faites git commit -a cela n'attrapera pas de nouveaux fichiers, vous devrez peut-être faire un git add après, mais si vous faites git add * vous ne besoin de -a sur le commit.

Le problème avec cette (excellente) réponse, c'est qu'elle ajoute tous les fichiers locaux, ce qui peut parfois ne pas être ce que vous voulez. Vous pouvez simplement ajouter les fichiers spécifiques qui ont été omis. Mais la meilleure chose à ce sujet est que cela lui permet de faire ce qu'il aurait dû faire - les ajouter localement. Vous n'aurez probablement pas besoin de la stratégie -X leur, car ils ont la même image. En fait, je suggérerais de le laisser de côté au début, juste pour savoir s'il y a des anomalies, et de l'ajouter s'il y en a, après avoir examiné que «leur» est toujours le bon choix. Mais alors, je suis paranoïaque.

Je voulais juste que git flippant écrase tout et se taise à ce sujet. après tout, je l'utilise juste entre mon ordinateur de travail et certains systèmes Raspberry Pi. Souhaitant une option de réécriture forcée, au moins pour le chef de projet

après avoir essayé cette commande, j'obtiens toujours la même erreur "les fichiers d'arbre de travail non suivis seraient écrasés par fusion" et une liste longue mais incomplète des fichiers que je ne peux pas simplement forcer à écraser.

hmmm ... essayez peut-être git add . d'abord

Tout d'abord, essayez la méthode standard:

git reset HEAD --hard # To remove all not committed changes!
git clean -fd         # To remove all untracked (non-git) files and folders!
 

Avertissement : les commandes ci-dessus peuvent entraîner une perte de données / fichiers uniquement si vous ne les avez pas validées! Si vous n'êtes pas sûr, effectuez d'abord la sauvegarde de l'ensemble de votre dossier de dépôt.

Puis tirez à nouveau.

Si ci-dessus ne vous aide pas et que vous ne vous souciez pas de vos fichiers / répertoires non suivis (faites d'abord la sauvegarde au cas où), essayez les étapes simples suivantes:

cd your_git_repo  # where 'your_git_repo' is your git repository folder
rm -rfv *         # WARNING: only run inside your git repository!
git pull          # pull the sources again
 

Cela SUPPRIMERA tous les fichiers git (excempt .git/ dir, où vous avez tous les commits) et le tirera à nouveau.


Pourquoi git reset HEAD --hard pourrait échouer dans certains cas?

  1. Règles personnalisées dans .gitattributes file

    Avoir la règle eol=lf dans .gitattributes pourrait amener git à modifier certaines modifications de fichiers en convertissant les fins de ligne CRLF en LF dans certains fichiers texte.

    Si tel est le cas, vous devez valider ces modifications CRLF / LF (en les examinant dans git status ), ou essayez: git config core.autcrlf false pour les ignorer temporairement.

  2. Incompabilité du système de fichiers

    Lorsque vous utilisez un système de fichiers qui ne prend pas en charge les attributs d'autorisation. Dans l'exemple, vous avez deux référentiels, un sur Linux / Mac (ext3 / hfs+ ) et un autre sur un système de fichiers basé sur FAT32 / NTFS.

    Comme vous le remarquez, il existe deux types différents de systèmes de fichiers, donc celui qui ne prend pas en charge les autorisations Unix ne peut fondamentalement pas réinitialiser les autorisations de fichiers sur un système qui ne prend pas en charge ce type d'autorisations, donc peu importe comment --hard vous essayez, git détecte toujours quelques "changements".

Le problème avec toutes ces solutions est qu'elles sont soit trop complexes, soit, un problème encore plus grave, est qu'elles suppriment tous les fichiers non suivis du serveur Web, ce que nous ne voulons pas car il y a toujours des fichiers de configuration nécessaires qui sont sur le serveur et non dans le référentiel Git.

Voici la solution la plus propre que nous utilisons:

 # Fetch the newest code
git fetch

# Delete all files which are being added, so there
# are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    rm -f -- "$file"
done

# Checkout all files which were locally modified
for file in `git diff --name-status | awk '/^[CDMRTUX]/ {print $2}'`
do
    git checkout -- "$file"
done

# Finally pull all the changes
# (you could merge as well e.g. 'merge origin/master')
git pull
  
  • La première commande récupère les données les plus récentes.

  • La deuxième commande vérifie s'il y a des fichiers qui sont ajoutés au référentiel et supprime ces fichiers non suivis du référentiel local, ce qui provoquerait des conflits.

  • La troisième commande extrait tous les fichiers qui ont été modifiés localement.

  • Enfin, nous faisons un pull pour mettre à jour vers la dernière version, mais cette fois sans aucun conflit, car les fichiers non suivis qui sont dans le dépôt n'existent plus et tous les fichiers modifiés localement sont déjà les mêmes que dans le référentiel.

Utiliser "git merge origin / master" comme dernière ligne (comme vous le dites dans votre note) au lieu de "git pull" sera plus rapide car vous avez déjà retiré toutes les modifications du repo git.

Ouais bien sûr, git merge origin/master sera plus rapide et probablement encore plus sûr. Puisque si quelqu'un a poussé de nouvelles modifications lors de la suppression des fichiers de ce script (ce qui est peu probable, mais possible), l'extraction entière pourrait échouer. La seule raison pour laquelle j'ai mis pull là-dedans est que quelqu'un ne travaille peut-être pas sur la branche principale, mais une autre branche et je voulais que le script soit universel.

Si vous avez créé localement des fichiers tels que des fichiers d'options, placez-les dans .gitignore .

Au lieu de fusionner avec git pull , essayez ceci:

git fetch --all

suivi de:

git reset --hard origin/master .

Réinitialisez l'index et la tête sur origin/master , mais ne réinitialisez pas l'arborescence de travail:

git reset origin/master
 

J'ai personnellement trouvé cela très utile. Il conserve ensuite votre arbre de travail afin que vous puissiez le réenregistrer. Pour mon problème, j'ai eu les mêmes fichiers supprimés comme étant ajoutés, donc il était bloqué. Bizarre, je sais.

Sur la base de mes propres expériences similaires, la solution proposée par Strahinja Kustudic ci-dessus est de loin la meilleure. Comme d’autres l’ont souligné, le simple fait d’effectuer une réinitialisation matérielle supprimera tous les fichiers non suivis qui pourraient inclure de nombreux éléments que vous ne souhaitez pas supprimer, tels que les fichiers de configuration. Ce qui est plus sûr, c'est de ne supprimer que les fichiers qui sont sur le point d'être ajoutés, et d'ailleurs, vous voudrez probablement également retirer tous les fichiers modifiés localement qui sont sur le point d'être mis à jour.

Cela à l'esprit, j'ai mis à jour le script de Kustudic pour faire exactement cela. J'ai également corrigé une faute de frappe (un 'manquant dans l'original).

 #/bin/sh

# Fetch the newest code
git fetch

# Delete all files which are being added,
# so there are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    echo "Deleting untracked file $file..."
    rm -vf "$file"
done

# Checkout all files which have been locally modified
for file in `git diff HEAD..origin/master --name-status | awk '/^M/ {print $2}'`
do
    echo "Checking out modified file $file..."
    git checkout $file
done

# Finally merge all the changes (you could use merge here as well)
git pull
  

Utiliser "git merge origin / master" comme dernière ligne (comme vous le dites dans votre note) au lieu de "git pull" sera plus rapide car vous avez déjà retiré toutes les modifications du repo git.

L'extraction des fichiers modifiés est nécessaire, donc cela fonctionne 100% des fois. J'ai mis à jour mon script avec cela il y a longtemps, mais j'ai également oublié de mettre à jour ici. Je l'utilise également un peu différemment de vous. Je récupère des fichiers qui ont n'importe quel type de modification, pas seulement M, donc cela fonctionne tout le temps.

Au lieu de faire:

git fetch --all
git reset --hard origin/master
 

Je vous conseille de faire ce qui suit:

git fetch origin master
git reset --hard origin/master
 

Pas besoin de récupérer toutes les télécommandes et branches si vous voulez réinitialiser la branche d'origine / principale, n'est-ce pas?

Votre réponse est exactement ce dont vous aviez besoin pour votre représentant. Je dois demander, est-ce que cela supprime également tous les fichiers non suivis?

Ouais, la plupart de mes représentants viennent d'ici :) Cela supprimera également tous les fichiers non suivis. Quelque chose que j'avais oublié et auquel je me suis douloureusement rappelé il y a à peine 2 jours ...

Voir les commentaires sur cette autre réponse: stackoverflow.com/a/8888015/2151700

Cela n'a pas supprimé mes fichiers non suivis; qui est en fait ce à quoi je m'attendais. Y a-t-il une raison pour laquelle cela pourrait pour certaines personnes et pas pour d'autres?

Les fichiers non suivis ne sont pas affectés par git reset. Si vous souhaitez qu'ils soient également supprimés, commencez par git add . , avant git reset --hard

C'est exactement ce dont j'avais besoin: quelque chose qui écrase les fichiers non suivis qui existent dans la télécommande et laisse tout le reste intact.

Il semble que la plupart des réponses ici se concentrent sur la branche master ; cependant, il y a des moments où je travaille sur la même branche de fonctionnalité à deux endroits différents et je veux qu'un rebase dans l'un soit reflété dans l'autre sans trop sauter à travers les cerceaux.

Basé sur une combinaison de réponse de l'ARN et de réponse de torek à une question similaire , j'ai trouvé celle-ci qui fonctionne à merveille:

git fetch
git reset --hard @{u}
 

Exécutez ceci à partir d'une branche et cela ne réinitialisera que votre branche locale à la version amont.

Cela peut également être mis dans un alias git (git forcepull ):

git config alias.forcepull "!git fetch ; git reset --hard @{u}"

Ou, dans votre fichier .gitconfig :

[alias]
  forcepull = "!git fetch ; git reset --hard @{u}"
 

Amusez-vous bien!

Cette réponse est également intéressante car elle fonctionne quelle que soit la branche sur laquelle vous vous trouvez!

Ces quatre commandes fonctionnent pour moi.

git reset --hard HEAD
git checkout origin/master
git branch -D master
git checkout -b master
 

Pour vérifier / extraire après avoir exécuté ces commandes

git pull origin master
 

J'ai beaucoup essayé mais j'ai finalement réussi avec ces commandes.

"git branch -D master" supprime la branche. alors soyez prudent avec cela. Je préfère utiliser "git checkout origin / master -b " qui crée une nouvelle branche avec un nouveau nom et vous avez besoin de 3,4 lignes. Il est également recommandé d'utiliser également "git clean -f".

Malgré la question d'origine, les réponses les plus fréquentes peuvent poser des problèmes aux personnes qui ont un problème similaire, mais qui ne veulent pas perdre leurs fichiers locaux. Par exemple, voir les commentaires d'Al-Punk et crizCraig.

La version suivante valide vos modifications locales dans une branche temporaire (tmp ), extrait la branche d'origine (que je suppose est master ) et fusionne les mises à jour. Vous pouvez le faire avec stash , mais j'ai trouvé qu'il est généralement plus facile d'utiliser simplement l'approche de branche / fusion.

git checkout -b tmp
git add *; git commit -am "my temporary files"
git checkout master

git fetch origin master
git merge -s recursive -X theirs origin master
 

où nous supposons que l ' autre dépôt est origin master .

Un moyen plus simple serait de:

git checkout --theirs /path/to/file.extension
git pull origin master
 

Cela remplacera votre fichier local par le fichier sur git

J'ai résumé d'autres réponses. Vous pouvez exécuter git pull sans erreur:

git fetch --all
git reset --hard origin/master
git reset --hard HEAD
git clean -f -d
git pull
 

Avertissement : ce script est très puissant, vous pourriez donc perdre vos modifications.

Cela écrasera les fichiers modifiés (fichiers précédemment archivés) et supprimera les fichiers non suivis (fichiers qui n'ont jamais été archivés). Exactement ce que je cherchais, merci!

Je soupçonne que la troisième ligne git reset --hard HEAD peut être redondante; ma page de manuel locale (2.6.3) indique que reset dans la deuxième ligne git reset --hard origin/master "est par défaut HEAD dans toutes les formes."

@arichards Je pense que votre suspect a raison, mais si la deuxième ligne ne fonctionne pas (pour une raison quelconque), la troisième ligne fonctionne bien pour réinitialiser. Cette solution n'a pas besoin d'être optimisée. Je viens de résumer d'autres réponses. C'est tout. Merci pour votre commentaire. :)

Merci pour le résumé. Ces étapes sont en effet puissantes :)

Exigences:

  1. Suivez les modifications locales afin que personne ici ne les perde jamais.
  2. Faites correspondre le référentiel local au référentiel d'origine distant.

Solution:

  1. Cacher les modifications locales.
  2. Récupérer avec un nettoyage des fichiers et des répertoires en ignorant .gitignore et hard reset à l ' origine .

    git stash --include-untracked
    git fetch --all
    git clean -fdx
    git reset --hard origin/master
    

Je connais une méthode beaucoup plus simple et moins douloureuse:

$ git branch -m [branch_to_force_pull] tmp
$ git fetch
$ git checkout [branch_to_force_pull]
$ git branch -D tmp
 

C'est tout!

J'ai essayé de faire comme suggéré dans cette réponse. AUCUN FICHIER n'a été extrait du référentiel distant. En fait, ce n'est pas très surprenant quand on y pense - après tout, il n'y a aucune référence à origin/<branch_to_force_pull> .

J'ai utilisé cette commande pour me débarrasser des fichiers locaux m'empêchant de faire un pull / merge. Mais fais attention! Exécutez d'abord git merge … pour voir s'il n'y a que les fichiers que vous voulez vraiment supprimer.

git merge origin/master 2>&1 >/dev/null | grep ^[[:space:]] | sed s/^[[:space:]]//g | xargs -L1 rm
 
  • git merge répertorie entre autres tous ces fichiers. Ils sont précédés d'un espace blanc.
  • 2>&1 >/dev/null redirige la sortie d'erreur vers la sortie standard afin qu'elle soit captée par grep .
  • grep ^[[:space:]] filtre uniquement les lignes avec des noms de fichiers.
  • sed s/^[[:space:]]//g rogne l'espace blanc depuis le début.
  • xargs -L1 rm appelle rm sur chacun de ces fichiers, en les supprimant.

Manipulez avec précaution: quels que soient les résultats de git merge , le rm sera appelé pour chaque ligne commençant par un espace blanc.

Faites simplement

git fetch origin branchname
git checkout -f origin/branchname // This will overwrite ONLY new included files
git checkout branchname
git merge origin/branchname
 

Vous évitez ainsi tous les effets secondaires indésirables, comme la suppression de fichiers ou de répertoires que vous vouliez conserver, etc.

Joli. En utilisant d'abord checkout -f dans la branche à partir de laquelle je voulais fusionner, cela a éliminé tous les fichiers problématiques non suivis. Ensuite, je pourrais vérifier à nouveau ma destination, et enfin fusionner sans problème.

Bonus:

En parlant de pull / fetch / merge dans les réponses précédentes, je voudrais partager une astuce intéressante et productive,

<₹git pull --rebase

Cette commande ci-dessus est la commande la plus utile de ma vie Git qui a permis de gagner beaucoup de temps.

Avant de pousser votre nouvelle validation sur le serveur, essayez cette commande et elle synchronisera automatiquement les dernières modifications du serveur (avec une extraction + fusion) et placera votre validation en haut du journal Git. Il n'est pas nécessaire de s'inquiéter de l'extraction / fusion manuelle.

Pour en savoir plus, consultez Que fait "git pull --rebase"? .

En bref: git pull -r .

Dans mon cas, avant de faire ça, je devais 1) git add -A , 2) git commit -m 3) et enfin git pull rebase . Merci.

J'ai lu toutes les réponses mais je cherchais une seule commande pour le faire. Voici ce que j'ai fait. Ajout d'un alias git à .gitconfig

[alias]
      fp = "!f(){ git fetch ${1} ${2} && git reset --hard ${1}/${2};};f"
 

Exécutez votre commande en tant que

git fp origin master
 

équivalent à

git fetch origin master
git reset --hard origin/master
 

J'essayais d'utiliser la branche Material2 sur Angular2-Webpack-Starter et je me suis bien amusé. C'était la seule façon dont je pouvais télécharger et utiliser cette branche.

git clone --depth 1 https://github.com/angularclass/angular2-webpack-starter.git

cd angular2-webpack-starter/

git checkout -b material2
 

Ouvrez le dossier du projet et supprimez tous les fichiers et dossiers non cachés. Laissez tous les cachés.

git add .

git commit -m "pokemon go"

git reset --hard

git pull origin material2
 

(Lorsque l'éditeur apparaît, appuyez sur ': wq', puis appuyez sur Entrée )

Vous êtes maintenant prêt.

Voici la meilleure pratique pour annuler les modifications:

  • git commit Validez vos modifications par étapes afin qu'elles soient enregistrées dans le reflog (voir ci-dessous)
  • git fetch Récupérer les dernières modifications en amont
  • git reset --hard origin/master Réinitialisation matérielle de la branche principale d'origine

Le reflog enregistre les branches et autres références mises à jour dans le référentiel local . Ou simplement, le reflog est l ' historique de vos modifications .

C'est donc toujours une bonne pratique de s'engager. Les validations sont ajoutées au reflog, ce qui garantit que vous aurez toujours un moyen de récupérer le code supprimé.

N'utilisez pas git reset --hard . Cela effacera leurs modifications qui pourraient bien être totalement indésirables. Au lieu de cela:

git pull
git reset origin/master
git checkout <file1> <file2> ...
 

Vous pouvez bien sûr utiliser git fetch au lieu de git pull car il ne va clairement pas fusionner, mais si vous tirez habituellement, il est logique de continuer à tirer ici.

Donc, ce qui se passe ici, c'est que git pull met à jour votre référence d'origine / principale ; git reset met à jour votre référence de branche locale pour qu'elle soit la même que l'origine / maître sans mettre à jour les fichiers, de sorte que votre état d'extraction reste inchangé; puis git checkout rétablit les fichiers dans l'état de votre index de branche local si nécessaire. Dans les cas où exactement le même fichier a été ajouté en direct et en amont, l'index correspond déjà au fichier après la réinitialisation, donc dans le cas courant, vous n'avez pas du tout besoin de faire git checkout .

Si la branche amont contient également des commits que vous souhaitez appliquer automatiquement, vous pouvez suivre une subtile variation du processus:

git pull
git merge <commit before problem commit>
git reset <problem commit>
git checkout <file1> <file2> ...
git pull
 

Sous Windows, exécutez cette seule commande:

git fetch --all & git reset --hard origin/master
 

Pourquoi serait-il différent de, par exemple, Linux? Quelle implémentation / package particulier de git utilisez-vous? Et / ou quel environnement (par exemple MinGW)?

Je ne suis pas sûr, seulement sûr que cela fonctionne dans Windows. Sous Linux, quel est le séparateur pour concaténer deux commandes en une seule ligne? (pas le tuyau, somply concaténer sans passer l'outoput)

si vous souhaitez réinitialiser la branche de suivi à distance de manière générique, utilisez:

git fetch
git reset --keep origin/$(git rev-parse --abbrev-ref HEAD)
 

si vous souhaitez également réinitialiser vos modifications locales:

git fetch
git reset --hard origin/$(git rev-parse --abbrev-ref HEAD)
 

Si vous vous trouvez fréquemment en train de l'utiliser, ajoutez un raccourci bash alias gplf='git fetch && echo "HEAD was at $(git rev-parse --short HEAD)" && git reset --hard origin/$(git rev-parse --abbrev-ref HEAD)'

Brillant. Merci! Les gens ne considèrent pas les scripts automatisés lorsqu'ils répondent. C'est très élégant lorsque vous ne pouvez tout simplement pas transmettre le nom de la branche.

1: réinitialiser à un commit précédent

git reset --hard HEAD
 

2: Supprimer les fichiers non suivis

git clean -f
 

3: Tirez les commits

git pull
 

Sources:

git fetch --all && git reset --hard origin/master && git pull

git fetch --all
 

alors si vous êtes sur la branche master

git reset --hard origin/master
 

autre

git reset --hard origin/master<branch_name>
 

Le dernier extrait de code doit être origin/<branch_name> et non origin/master<branch_name> .

vous pouvez essayer git pull --force ou peut-être cacher vos commits en utilisant git stash puis en exécutant git pull

Cela ne marche pas. fatal: refusing to merge unrelated histories

Automatic merge failed; fix conflicts and then commit the result.

Non: error: The following untracked working tree files would be overwritten by merge: - je me fiche de ces fichiers. S'il n'y en avait que deux ou trois, je les supprimerais simplement. Mais il y en a tellement.

J'ai fait ceci pour que ça marche:

Sur l'ordinateur où j'ai créé la nouvelle branche:

git push --all
 

Sur l'ordinateur sur lequel je voulais afficher la nouvelle branche:

git fetch --all
 

Comme j'ai souvent besoin d'un moyen rapide de réinitialiser la branche actuelle sur Windows via l'invite de commande, voici un moyen rapide:

for /f "tokens=1* delims= " %a in ('git branch^|findstr /b "*"') do @git reset --hard origin/%b
 

Une fois que vous avez fait git pull, vous obtiendrez la liste des fichiers qui ne correspondent pas. Si le nombre de fichiers n'est pas très important, vous pouvez extraire ces fichiers, cette action écrasera ces fichiers.

git checkout -

Je le fais généralement si, pour une vérification rapide, je modifie les fichiers locaux sur le serveur (aucune raison recommandée et probablement derrière vous avoir ce problème: D), je récupère les fichiers modifiés après avoir trouvé la solution.

Malgré le fait que cette question a déjà de nombreuses réponses, la question initiale est de résoudre cette question

erreur: le fichier d'arborescence de travail non suivi 'public / images / icon.gif' serait écrasé par la fusion

Comme les fichiers binaires ne peuvent pas être fusionnés, une réponse simple est

git checkout public/images/icon.gif
 

Avec cela, le fichier récupérera l'état précédent qu'il avait dans cette branche.

Je fais généralement git stash si je ne veux pas perdre mes modifications ou quelque chose comme git checkout . si je ne me soucie pas des fichiers modifiés localement. IMO beaucoup plus simple que reset --hard , clean ... et tout cela plus adapté pour quitter la branche comme à distance, y compris les commits, les fichiers non suivis, plutôt que de simplement résoudre un modifié localement fichier.

Je pense que vous pouvez également forcer par git push -f / git push --force

La question est de tirer, pas de pousser.

J'ai essayé la plupart de ce que j'ai pu trouver ici, aucun n'a fonctionné dans mon cas.

Ce qui a fonctionné, c'est git merge -X theirs

Étape 1 . (facultatif)
À partir de la racine de votre référentiel local, enregistrez une sauvegarde et vider le dossier actuel :

mkdir -p ../<branch>-bkp && mv --backup=t * ../<branch>-bkp
 

Étape 2 . Téléchargez tous les fichiers et dossiers de la branche depuis le référentiel distant:

git checkout <branch> && git add -A . && git reset --hard origin/<branch> && git pull
 

où vous devez remplacer <branch> par le nom de la branche vous voulez écraser.

  • Vous pouvez préférer manuellement sauvegarder et supprimer les fichiers actuels et dossiers au lieu de l ' étape 1 .
    En fait, je recommande de le faire avec un gestionnaire de fichiers dans l'interface graphique de votre système d'exploitation.
  • Si vous ignorez l ' étape 1 , méfiez-vous: vous perdrez tout le travail dans le local référentiel!
  • <₹Important: si vous omettez git pull à l ' étape 2 ,
    vous risquez de ne pas obtenir la dernière version du référentiel distant !
    Selon la deuxième référence ci-dessous, git reset --hard
    réinitialise la zone de préparation et le répertoire de travail pour qu'ils correspondent le plus commit récent .
    Mon expérience contredit cette affirmation!
  • Si vous exécutez git reset --hard origin/<branch_to_overwrite> sans supprimer au préalable tous les fichiers et dossiers de votre référentiel local, méfiez-vous que tous les fichiers inutiles qui traînent encore peuvent se faufiler dans la télécommande dépôt à un git push plus tard, même si ce n’était pas votre intention.
    L 'git add -A . supplémentaire à l' étape 2 empêche que cela se produise si vous choisissez d'omettre l ' étape 1 .

Références:
https://gitforwindows.org/
https://www.atlassian.com/git/tutorials/undoing- changements / git-reset
https://www.atlassian.com/git/tutorials/rewriting- historique / git-reflog

Vous pouvez essayer:

$ git fetch --all
$ git reset --hard origin/master 
$ git pull
 

Cela a très bien fonctionné pour moi!

git fetch --all
git reset --hard origin/master