C'est ce que vous voulez faire :

1. Ajoutez tous les fichiers, individuellement ou dans un dossier, que vous souhaitez retirer du repo mais conserver localement dans .gitignore .
2. Exécuter git rm --cached put/here/your/file.ext pour chaque fichier ou git rm --cached folder/\* s'ils se trouvent dans un dossier. (C'est /\* parce qu'il faut échapper au *)
3. commit vos modifications.
4. Appuyer sur la télécommande.

Après avoir fait cela, vous pourrez effectivement "ignorer les fichiers suivis sans les supprimer". en les supprimant du repo et en les gardant tous intacts dans votre système. Ensuite, lorsque votre équipe retirera les modifications, elle retirera le fichier .gitignore et leurs fichiers de configuration individuels ne seront pas écrasés par ceux de la base de données parce que vous les avez ignorés et supprimés. De plus, parce que maintenant le nouveau .gitignore ignore ces fichiers, tout le monde aura sa propre version de ces fichiers qui n'apparaîtra pas dans les "uncommitted changes".

Il semble qu'une solution facile ait été trouvée aquí . Ajouter le fichier / répertoire à .gitignore n'est pas suffisant, mais git vous permet d'ignorer manuellement les modifications apportées à un fichier / répertoire :

git update-index --assume-unchanged <file>

Et si vous voulez recommencer à suivre les modifications, vous pouvez annuler la commande précédente en utilisant :

git update-index --no-assume-unchanged <file>

Contexte : J'ai eu besoin de cela pour ajouter un fichier de configuration avec les données de l'utilisateur dans le repo. L'utilisateur peut extraire le fichier et l'éditer pour son système, mais le fichier doit ensuite être ignoré par git et ne jamais être commité.

1. Supprimer ces fichiers du dépôt git. Ajoutez-les dans .gitignore. Demander à tous les membres de mon équipe d'ajouter ces fichiers à leur projet local avec leurs propres paramètres.

Si je comprends bien votre question, et si les fichiers en question contiennent des éléments tels que les identifiants d'authentification et les paramètres de configuration spécifiques au site ou au développeur, alors c'est la bonne solution.

• S'il y a tous Si votre dépôt git est accessible à des entités extérieures ou non fiables, vos données d'authentification ne doivent pas y figurer, car elles seront divulguées à toute personne clonant le projet. Même si les informations d'identification ont été supprimées ultérieurement, elles seront toujours disponibles dans l'historique.

• Les paramètres spécifiques aux sites/développeurs ne posent pas les mêmes problèmes de sécurité que les informations d'authentification, mais ils continueront à poser des problèmes si plusieurs sites ou développeurs sont concernés car, même si vous avez mis en place une politique interdisant la validation/la modification de ces fichiers, ce n'est qu'une question de temps avant qu'ils ne soient modifiés. quelqu'un commits et entraîne la modification des paramètres de tous les autres (ou la génération de conflits parasites) la prochaine fois qu'ils tirent. J'ai une expérience personnelle de ce problème, et c'est une nuisance majeure et permanente à gérer. Dans notre cas, certaines des différences concernaient les paramètres de développement par rapport aux paramètres de production, ainsi que les paramètres spécifiques au site, et cela a eu des effets négatifs répétés sur nos systèmes de production.

Une solution de contournement que j'ai vu plusieurs projets utiliser consiste à faire une copie aseptisée de foo.cfg nommée foo.cfg.default , piste foo.cfg.default dans git, gitignore foo.cfg et s'en remettre à l'utilisateur pour copier foo.cfg.default a foo.cfg après le clonage et le personnaliser (en ajoutant des informations d'authentification, des paramètres personnalisés, etc.) Dans votre cas, les fichiers de configuration étant ceux d'un plugin tiers, cela pourrait fonctionner, car ils sont probablement assez stables. C'est moins efficace dans les scénarios où foo.cfg.default changera fréquemment, puisqu'il incombe alors à l'utilisateur de remarquer les changements et de les fusionner manuellement dans la base de données locale. foo.cfg .

Tl;dr

• Techniquement, votre exigence est contradictoire.

• D'un point de vue plus philosophique, il semble qu'il s'agisse d'un conflit entre la philosophie de l'open source et celle de l'entreprise.

• Quoi qu'il en soit, je vais vous proposer quelques idées qui me viennent à l'esprit

Techniquement

git suit ou ignore un fichier.

• Le suivi est facile. Il suffit de ne rien faire à part utiliser git ! Et n'importe quel fichier est suivi.
• L'ignorer est presque aussi facile - il suffit de s'assurer qu'il correspond à quelque chose dans votre fichier gitignore.
• Mais vous ne pouvez pas faire les deux !
• Principale mise en garde : faire passer un fichier de suivi à ignoré n'est pas chose aisée - il suffit d'ajouter le motif approprié à gitignore pour y parvenir une fois le fichier suivi. Le modèle

Meilleures pratiques

Ne démarrez pas un projet git sans avoir créé un fichier

• gitignore
  Également en rapport
• gitattributes

Ainsi, la première (et quelque peu irréaliste)

Suggestion 1

• Démarrer un nouveau projet git
• Créer les fichiers gitignore et gitattribute appropriés
• Déboguer si nécessaire avec git-check-ignore
• Copier, ajouter, commit vos fichiers normaux
• Copie, ajout, statut des fichiers qui ne doivent pas être suivis. Le statut doit être propre

Mais comme je l'ai dit, ce n'est pas tout à fait ce que vous souhaitez, car vous voulez une sorte de fichiers partagés mais non suivis. Vous devez donc

Supprimer les fichiers suivis

• Embout propre (solution simple mais probablement inadéquate)
• branche du filtre
• filtre-branche
• Mieux alternative à la branche filtre

Vous voulez en fait un git

Crochet post-Clone

Il s'agit d'une tentative aquí

Mais est-ce qu'un mauvaise idée comme expliqué aquí

Ce qui m'amène à la

Différence philosophique

• Une entreprise-employeur souhaite à juste titre contrôler le fonctionnement de ses employés-programmeurs. Ce qui implique différents types de contrôle des machines
• Un logiciel open source aléatoire sur github qui prend le contrôle de la machine d'une autre personne aléatoire est contraire à l'éthique et illégal.

Par conséquent, si vous étiez un gros joueur de fortune-500, l'option naturelle serait de forker git lui-même et d'ajouter une fonctionnalité de crochet post-clone dans votre fork.

Une solution plus raisonnable et à peine plus gênante

Solution 2

• Écrire votre propre script post-clone mais appelable manuellement.
• qui répond à l'exigence de copier en cas d'absence et de laisser en l'état en cas de présence
• Et ajoutez une étape (manuelle) à votre équipe : (1) clone (2) call script
• Et n'oubliez pas le gitignore !!!

Si cette solution vous semble logique, vous préférerez peut-être

Solution 3

Inverser le script-inside-git a git-inside-script

Par exemple, demandez à votre équipe de ne télécharger/copier et exécuter qu'un script qui

• Courses git clone
• Vérifie l'existence et la pertinence de ces autres fichiers
• Les crée/télécharge si nécessaire (peut-être à partir d'une source indépendante de votre repo principal)

Il n'y a pas de solution simple à ce problème. Mais vous pouvez essayer les solutions suivantes :

A) Mettre foo.cfg en .gitignore et pousser. Demandez à chacun de garder une copie de sauvegarde de foo.cfg en dehors de leur dépôt local. Laissez-les pousser et copier ce fichier supprimé foo.cfg en place.

B) Renommer foo.cfg a foo.default.cfg mettre foo.cfg dans gitignore, pousser et demander à chaque membre de votre équipe de tirer, puis renommer localement foo.default.cfg a foo.cfg . Ensuite, vous devez supprimer foo.default.cfg Il faut pousser, et tout le monde doit tirer à nouveau.

C) Mettre foo.cfg en .gitignore et pousser. Demandez à tout le monde de tirer. Maintenant, pour tout le monde, le foo.cfg est supprimée. Ils peuvent le restaurer en git checkout HEAD^ foo.cfg . Le fichier est toujours en cours de traitement, il faut donc appeler git reset HEAD . Cela fonctionne maintenant.