... les données qui se trouvent dans le dossier .git sont généralement ignorées par git.
Ce n'est pas seulement typique c'est nécessaire pour le modèle de sécurité de Git.
(Dans le passé, Git avait quelques bugs dans lesquels vous pouviez créer des fichiers nommés .GIT/whatever et ils iraient dans le dépôt, puis existeraient dans .git/whatever sur les caisses sous Windows et MacOS, puisque ces systèmes ignorent par défaut la casse : un fichier nommé .GIT/foo est en fait créé en tant que .git/foo depuis .git existe à ce moment-là. Ce bogue a été corrigé dans la version moderne de Git).
Je veux ajouter des données à mon repo de façon à ce que les données soient indépendantes de toutes les branches, mais apparaissent quand même dans toutes les branches, et lorsque vous clonez le repo, les données apparaissent.
Est-ce possible ?
Non, mais il y a d'autres moyens d'obtenir ce que tu veux.
Le clonage d'un référentiel est équivalent aux étapes suivantes :
- Créez un répertoire vide (ou utilisez un répertoire existant) :
mkdir _path_ .
- Créez un nouveau dépôt Git, vide, à cet endroit :
cd _path_ && git init .
- Ajouter un à distance habituellement nommé
origin pour l'URL : git remote add origin _url_ .
- Récupérer tout ce qui se trouve dans cette télécommande :
git fetch origin .
- Créer une branche via
git checkout : git checkout _branch_ , donde branche est normalement créé à partir d'un nom de suivi à distance qui a été créé au cours de l'opération précédente git fetch étape.
Il existe un certain nombre de particularités historiques, ainsi que des problèmes si quelque chose ne va pas, de sorte que ce qui précède n'est pas tout à fait parfait. Il omet également une option git config étape. La branche choisie à la fin, pour être créée, est celle de votre -b argument. Si votre -b nomme une balise au lieu d'une branche, Git vérifie simplement un HEAD détaché sans créer de branche. Si vous ne donnez pas de -b Git utilise les directives de la télécommande pour déterminer la branche à créer. La valeur par défaut, et donc le résultat habituel, est master créé pour pointer vers le même commit que origin/master .
Une fois qu'il y a une branche, ou quelques branches, dans un dépôt, ces branches, plus précisément, ces noms comme master y develop et ainsi de suite - sont la propriété de celui qui possède le référentiel. Ils peuvent en faire ce qu'ils veulent ; vous, en tant que propriétaire du référentiel qu'ils ont cloné, ne pouvez rien faire pour les arrêter. Vous ne pouvez pas faire ils ont un fichier qui apparaît dans leurs branches. Bien sûr, nous pouvons dire la même chose de l'ensemble du référentiel, c'est donc un argument un peu stupide : il est vrai que vous ne pouvez pas les contrôler, mais l'ensemble du référentiel n'est pas contrôlé. dépôt est à eux pour en faire ce qu'ils veulent.
Vraisemblablement, alors, ce que vous voulez c'est le rendre facile pour qu'ils installent du contenu dans un fichier quelque part. Le moyen d'y parvenir est de rendre le contenu accessible par un simple nom. Mais quels noms Git offre-t-il ?
Eh bien, au niveau inférieur, ce que les magasins Git sont commet qui, à son tour, stocke arbres (noms de chemin) qui stockent blobs (contenu du fichier). Le nom réel d'un commit, d'un arbre ou d'un blob donné est un ID de hachage brut, et les ID de hachage sont imprévisibles et ne sont généralement pas utiles ou accessibles aux humains. Ainsi, vous pourrait dire aux gens, dire, à :
extraire l'ID de hachage 1bdc91e282c5393c527b3902a208227c19971b84 en .oresoftware/foo
mais (1) l'ID de hachage est incompréhensible, et (2) qui veut taper tout ça ? Et si vous avez plusieurs fichiers, vous aurez besoin d'un ID de hachage de blob par fichier. Beurk !
Il existe cependant une meilleure façon de procéder. Vous pouvez créer un commettre qui contient des fichiers nommés .oresoftware/foo , .oresoftware/bar et ainsi de suite. Il s'agit d'un commit ordinaire qui peut être extrait dans un arbre de travail ordinaire à tout moment.
Maintenant, supposons que vous mettez ce commit sur une branche nommée ORESOFTWARE . Vous pouvez alors dire aux gens qu'ils devraient :
Ejecutar git checkout origin/ORESOFTWARE -- .oresoftware && git reset .oresoftware
qui, certes, n'est pas vraiment plus courte, mais qui au moins n'est pas pleine d'identifiants de hachage incompréhensibles.
El git checkout créera .oresoftware dans leur arbre de travail, pour autant qu'ils aient le nom de suivi à distance, qui est le suivant git fetch (de git clone ) auront créé. 1 Le site git reset .oresoftware supprimera le .oresoftware les entrées qui git checkout créés dans leur index. Si /.oresoftware/ est répertorié dans .gitignore les fichiers de l'arbre de travail seront ignorés. Cela signifie que vous devez avoir un .gitignore dans chaque tip commit de chaque branche, de sorte que le répertoire sera commodément ignoré automatiquement, mais c'est facile à faire.
Enfin, au lieu de demander aux gens d'exécuter deux commandes Git apparemment magiques, vous pouvez dire :
Ejecutar ./setup.sh
ce qui signifie que vous pouvez mettre les deux commandes Git dans un shell script, setup.sh que vous fournissez dans chaque pointe de branche, tout comme vous fournissez la .gitignore dans chaque pointe de branche. De plus, vous pouvez même faire en sorte que votre processus de construction de logiciels automatiquement exécuter ./setup.sh et vous n'avez pas besoin d'une action spéciale de leur part.
Si vous décidez de changer les fichiers qui vont dans .oresoftware vous devez juste faire un nouveau commit sur votre propre site. ORESOFTWARE branche. Celle-ci peut (et devrait probablement) contenir uniquement la branche .oresoftware répertoire. Étant donné que le processus de construction ré-extracte le répertoire à chaque construction, un fichier git fetch permettra à vos utilisateurs d'obtenir une mise à jour origin/ORESOFTWARE nom de suivi à distance, ce qui leur permettra d'obtenir les fichiers mis à jour.
