Les fichiers d'arbre de travail non suivis suivants seraient remplacés par la fusion, mais je m'en fiche

Sur ma branche j'avais quelques fichiers en .gitignore

Sur une branche différente, ces fichiers ne le sont pas.

Je veux fusionner les différentes branches dans la mienne, et je me fiche que ces fichiers ne soient plus ignorés ou non.

Malheureusement, je reçois ceci:

Les fichiers d'arborescence de travail non suivis suivants seraient remplacés par la fusion

Comment modifier ma commande pull pour écraser ces fichiers, sans que je doive trouver, déplacer ou supprimer moi-même ces fichiers?

Le problème est que vous ne suivez pas les fichiers localement mais que des fichiers identiques sont suivis à distance, afin de "tirer" votre système serait obligé d'écraser les fichiers locaux qui ne sont pas contrôlés par la version.

Essayez de courir

git add * 
git stash
git pull

Cela suivra tous les fichiers, supprimera toutes les modifications locales apportées à ces fichiers, puis récupérera les fichiers du serveur.

Vous pouvez essayer de supprimer les fichiers non suivis du local

Git 2.11 et versions plus récentes:

git clean  -d  -f .

Versions plus anciennes de Git:

git clean  -d  -f ""

Où -dpeut être remplacé par ce qui suit:

• -x les fichiers ignorés sont également supprimés ainsi que les fichiers inconnus de Git.

• -d supprimer les répertoires non suivis en plus des fichiers non suivis.

• -f est nécessaire pour le forcer à s'exécuter.

Voici également le lien qui peut être utile.

Les seules commandes qui ont fonctionné pour moi étaient:

git fetch --all
git reset --hard origin/{{your branch name}}

Un remplacement pour git mergecela écrasera les fichiers non suivis

Les commentaires ci-dessous utilisent «FOI» pour les «fichiers d'intérêt», les fichiers

• existent dans la branche des donateurs,
• n'existent pas dans la branche destinataire,
• et bloquent la fusion car ils sont présents et non suivis dans votre répertoire de travail.

git checkout -f donor-branch   # replace FOI with tracked `donor` versions
git checkout receiving-branch  # FOI are not in `receiving`, so they disapppear
git merge donor-branch  # now the merge works

Un remplacement pour git pullcela écrasera les fichiers non suivis

pull = fetch + merge, nous git fetchsuivons donc l' git checkout -f, git checkout, git mergeastuce ci-dessus.

git fetch origin  # fetch remote commits
git checkout -f origin/mybranch  # replace FOI with tracked upstream versions
git checkout mybranch  # FOI are not in mybranch, so they disapppear
git merge origin/mybranch  # Now the merge works. fetch + merge completes the pull.

Explication détaillée

git merge -fn'existe pas, mais existe git checkout -f.

Nous utiliserons git checkout -f+git checkout pour supprimer les fichiers d'intérêt (voir ci-dessus), puis votre fusion pourra se dérouler normalement.

Étape 1. Cette étape remplace de force FOI non suivi par des versions suivies de la branche donneur (il vérifie également la branche donneur et met à jour le reste du répertoire de travail).

git checkout -f donor-branch

Étape 2. Cette étape supprime le FOI car ils sont suivis dans notre branche actuelle (donneur) et absents dans le receiving-branchcommutateur vers lequel nous basculons.

git checkout receiving-branch

Étape 3. Maintenant que la FOI est absente, la fusion dans la branche des donateurs n'écrasera aucun fichier non suivi, nous n'obtiendrons donc aucune erreur.

git merge donor-branch

Supprimez tous les fichiers non suivis:

git clean  -d  -fx .

S'il s'agit d'une opération ponctuelle, vous pouvez simplement supprimer tous les fichiers non suivis du répertoire de travail avant d'effectuer l'extraction. Lire Comment supprimer des fichiers locaux (non suivis) de l'arborescence de travail Git actuelle?pour savoir comment supprimer tous les fichiers non suivis.

Assurez-vous de ne pas supprimer accidentellement le fichier non suivi dont vous avez encore besoin;)

Vous pouvez essayer cette commande

git clean -df

Mise à jour - une meilleure version

Cet outil ( https://github.com/mklepaczewski/git-clean-before-merge ) permettra:

• supprimer les fichiers non suivis identiques à leurs git pulléquivalents,
• annuler les modifications apportées aux fichiers modifiés dont la version modifiée est identique à leurs git pulléquivalents,
• signaler les fichiers modifiés / non suivis qui diffèrent de leurs git pull version,
• l'outil a l' --pretendoption qui ne modifiera aucun fichier.

Ancienne version

En quoi cette réponse diffère-t-elle des autres réponses?

La méthode présentée ici supprime uniquement les fichiers qui seraient écrasés par la fusion. Si vous avez d'autres fichiers non suivis (éventuellement ignorés) dans le répertoire, cette méthode ne les supprimera pas.

La solution

Cet extrait extraira tous les fichiers non suivis qui seraient écrasés par git pullet les supprimera.

git pull 2>&1|grep -E '^\s'|cut -f2-|xargs -I {} rm -rf "{}"

puis faites simplement:

git pull

Ce n'est pas une commande git porcelain alors vérifiez toujours ce qu'il ferait avec:

git pull 2>&1|grep -E '^\s'|cut -f2-|xargs -I {} echo "{}"

Explication - parce que l'une des doublures fait peur:

Voici une ventilation de ce qu'il fait:

1. git pull 2>&1- capturez la git pullsortie et redirigez le tout vers stdout afin que nous puissions facilement le capturer avecgrep .
2. grep -E '^\s - l'intention est de capturer la liste des fichiers non suivis qui seraient écrasés par git pull . Les noms de fichiers ont un tas de caractères blancs devant eux, nous les utilisons donc pour les obtenir.
3. cut -f2- - supprimer les espaces blancs au début de chaque ligne capturée en 2.
4. xargs -I {} rm -rf "{}"- nous xargspour parcourir tous les fichiers, enregistrer leur nom dans "{}" et appeler rmchacun d'eux. Nous utilisons -rfpour forcer la suppression et la suppression des répertoires non suivis.

Ce serait formidable de remplacer les étapes 1 à 3 par la commande porcelaine, mais je ne connais aucun équivalent.

Si vous envisagez d'utiliser le -fdrapeau, vous pouvez d'abord l'exécuter comme un essai à sec. Juste que vous savez d'avance quel genre de situation intéressante vous vous retrouverez ensuite ;-P

-n 
--dry-run 
    Don’t actually remove anything, just show what would be done.

En plus de la réponse acceptée, vous pouvez bien sûr supprimer les fichiers s'ils ne sont plus nécessaires en spécifiant le fichier:

git clean -f '/path/to/file/'

N'oubliez pas de l'exécuter avec l'indicateur -n d'abord si vous souhaitez voir quels fichiers git clean supprimera. Notez que ces fichiers seront supprimés. Dans mon cas, je m'en fichais de toute façon, c'était donc une meilleure solution pour moi.

Une façon de le faire consiste à cacher vos modifications locales et à tirer du référentiel distant. De cette façon, vous ne perdrez pas vos fichiers locaux car les fichiers iront à la cachette.

git add -A
git stash
git pull

Vous pouvez vérifier vos fichiers cachés locaux en utilisant cette commande - git stash list

Pour ceux qui ne le savent pas, git ignore les différences de nom en majuscules / minuscules dans les fichiers et les dossiers. Cela se révèle être un cauchemar lorsque vous les renommez exactement au même nom avec un cas différent.

J'ai rencontré ce problème lorsque j'ai renommé un dossier de "Petstore" en "petstore" (en majuscules en minuscules). J'avais modifié mon fichier .git / config pour arrêter d'ignorer la casse, apporté des modifications, écrasé mes validations et caché mes modifications pour passer à une autre branche. Je ne pouvais pas appliquer mes modifications cachées à cette autre branche.

Le correctif que j'ai trouvé qui fonctionnait était de modifier temporairement mon fichier .git / config pour ignorer temporairement la casse à nouveau. Cela a git stash applyréussi. Ensuite, j'ai changé ignoreCase pour false. J'ai ensuite tout ajouté à l'exception des nouveaux fichiers dans le dossier petstore qui, étrangement, ont prétendu avoir été supprimés, pour une raison quelconque. J'ai commis mes modifications, puis j'ai courugit reset --hard HEAD pour me débarrasser de ces nouveaux fichiers non suivis. Mon commit est apparu exactement comme prévu: les fichiers du dossier ont été renommés.

J'espère que cela vous aidera à éviter mon même cauchemar.

Ni nettoyer / réinitialiser / checkout / rebase dur n'a fonctionné pour moi.

J'ai donc juste supprimé les fichiers dont git se plaignait *

rm /path/to/files/that/git/complained/about

* J'ai vérifié si ces fichiers peuvent être supprimés en vérifiant un nouveau dépôt dans un dossier séparé (les fichiers n'étaient pas là)

Dans mon cas, quand j'ai eu ce problème. J'avais un fichier local que j'avais renommé sur la télécommande.

En essayant de git pullGit m'a dit que le nouveau nom de fichier n'était pas suivi - qu'il était sur la télécommande bien qu'il n'existait pas encore en local.

Parce qu'il n'y avait pas d'exemple localement, je ne pouvais pas le faire git pullavant de le faire git rmsur l' ancien nom de fichier (ce qui n'était pas évident au début à cause de mon idée stupide de le renommer).

Si vous avez les fichiers écrits sous .gitignore, supprimez les fichiers et réexécutez git pull. Cela m'a aidé.

Le problème est lorsque nous avons des modifications entrantes qui fusionneront un fichier non suivi, se plaint git. Ces commandes m'ont aidé:

git clean -dxf
git pull origin master