Comment forcer l'écrasement des 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 source)
• Ils m'envoient les images par courrier, plus tard,
• J'ajoute les images sous le contrôle de la source et je les pousse vers GitHub avec d'autres changements
• Ils ne peuvent pas extraire les mises à jour de GitHub car Git ne veut pas écraser leurs fichiers.

Voici l'erreur que je reçois:

erreur: le fichier d'arbre 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 ils ont juste besoin de mettre à jour sur leur ordinateur.

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

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

Je pense que c'est la bonne façon:

git fetch --all

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 version à distance sans essayer de fusionner ou de rebaser quoi que ce soit.

Ensuite, le git resetréinitialise la branche principale à ce que vous venez de récupérer. L' --hardoption modifie tous les fichiers de votre arborescence de travail pour correspondre aux fichiersorigin/master

Maintenir les engagements locaux actuels

^[*] : Il convient de noter qu'il est possible de conserver les validations locales actuelles en créant une branche masteravant 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 new-branch-to-save-current-commits.

Modifications non validées

Les modifications non validées (même par étapes) seront perdues. Assurez-vous de ranger 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

Essaye ça:

git reset --hard HEAD
git pull

Il devrait faire ce que vous voulez.

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

Parfois, clean -fça n'aide pas. Si vous avez des ANNUAIRES non suivis, l'option -d a également besoin:

# WARNING: this can't be undone!

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

ATTENTION: git cleansupprime tous vos fichiers / répertoires non suivis et ne peut pas être annulé.

Pensez à utiliser le drapeau -n( --dry-run) en premier. Cela vous montrera ce qui sera supprimé sans supprimer quoi que ce soit:

git clean -n -f -d

Exemple de sortie:

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

Comme Hérisson, 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é cela est d'utiliser "fetch" et "merge" avec une stratégie définie. Ce qui devrait faire en sorte que vos modifications locales soient préservées tant qu'elles ne font pas partie des fichiers avec lesquels vous essayez de forcer l'écrasement.

Commencez par valider vos modifications

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

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

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

"-X" est un nom d'option et "leur" est la valeur de cette option. Vous choisissez d'utiliser "leurs" modifications, au lieu de "vos" modifications en cas de conflit.

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 les branches si vous allez réinitialiser la branche d'origine / principale, n'est-ce pas?

Il semble que la meilleure façon est de faire d'abord:

git clean

Pour supprimer tous les fichiers non suivis, puis continuer avec la procédure habituelle git pull...

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 pouvez nettoyer l'historique de la cachette.

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}

Vous pourriez trouver cette commande utile pour supprimer les modifications locales:

git checkout <your-branch> -f

Et puis faites 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

Au lieu de fusionner avec git pull, essayez ceci:

git fetch --all

suivi par:

git reset --hard origin/master.

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 .

Le problème avec toutes ces solutions est qu'elles sont toutes trop complexes ou, encore plus grave, 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 qui pourraient provoquer des conflits.

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

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

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!

^{Attention : les commandes ci-dessus peuvent entraîner la 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 référentiel.}

Tirez-le ensuite à nouveau.

Si ci-dessus ne vous aide pas et que vous ne vous souciez pas de vos fichiers / répertoires non suivis (effectuez 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 --hardpourrait échouer dans certains cas?

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

   Ayant eol=lf règle dans .gitattributes pourrait amener git à modifier certaines modifications de fichier 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 essayer: git config core.autcrlf falsede 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. Par 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 de systèmes de fichiers différents, donc celui qui ne prend pas en charge les autorisations Unix ne peut 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 --hardvous essayez, git toujours détecter certains "changements".

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 en:

1. Supprimez tous les fichiers. Laissez juste le .gitrépertoire.
2. git reset --hard HEAD
3. git pull
4. git push

Maintenant ça marche.

Prime:

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 nouveau commit sur le serveur, essayez cette commande et elle synchronisera automatiquement les dernières modifications du serveur (avec un fetch + merge) et placera votre commit en haut dans le journal Git. Il n'y a aucun besoin de s'inquiéter de l'extraction / fusion manuelle.

Trouvez les détails dans Que fait "git pull --rebase"? .

J'avais un problème similaire. Je devais faire ça:

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

J'ai résumé d'autres réponses. Vous pouvez exécuter git pullsans erreurs:

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 pouvez donc perdre vos modifications.

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é, une simple réinitialisation matérielle supprimera tout les fichiers non suivis qui pourraient inclure de nombreuses choses que vous ne souhaitez pas supprimer, telles 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 retirer tous les fichiers modifiés localement qui sont sur le point d'être mis à jour.

Dans cet esprit, j'ai mis à jour le script de Kustudic pour faire exactement cela. J'ai également corrigé une faute de frappe (une manquante '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

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, manuellement (plus sûr) ou comme suggéré dans d'autres réponses, par git clean -f -d

• Les validations locales qui ne sont pas sur la branche distante doivent également être supprimées. IMO la façon la plus simple d'y parvenir est de: git reset --hard origin/master(remplacer 'master' par la branche sur laquelle vous travaillez, et exécutez une git fetch originpremière)

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

Il semble que la plupart des réponses se concentrent ici sur master branche; 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 beaucoup de sauts dans les cerceaux.

Sur la base d'une combinaison de la réponse de l' ARN et la réponse de torek à une question similaire , je suis venu avec ce qui fonctionne à merveille:

git fetch
git reset --hard @{u}

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

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

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

Ou, dans votre .gitconfigdossier:

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

Prendre plaisir!

J'ai eu le même problème et pour une raison quelconque, même un git clean -f -dne 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 d'écraser cela avec une traction ultérieure , mais un nettoyage ne le supprimera pas, sauf si vous l'ajoutez -x.

Je connais une méthode beaucoup plus facile 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 ça!

Je viens de résoudre cela 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 pouvez probablement gérer cela d'une 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 essayez d'abord sur un projet non critique ...

J'ai une situation étrange que ni l'un git cleanni l' autre ne git resetfonctionne. Je dois supprimer le fichier en conflit git indexà l'aide du script suivant sur chaque fichier non suivi:

git rm [file]

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

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

Malgré la question d'origine, les meilleures réponses peuvent causer des problèmes aux personnes qui ont un problème similaire, mais 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 (ce que je suppose 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 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 référentiel est origin master.

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 / tirer après avoir exécuté ces commandes

git pull origin master

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

Fais juste

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 souhaitez conserver, etc.

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

git reset origin/master

Exigences:

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

Solution:

1. Cachez les changements locaux.

2. Récupérez avec un nettoyage des fichiers et des répertoires en ignorant .gitignore et réinitialisation matérielle à l' origine .

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