Deux référentiels git dans un répertoire?
Est-il possible d'avoir 2 dépôts Git dans un seul répertoire? Je ne penserais pas, mais pensais demander. En gros, j'aimerais vérifier les fichiers de configuration de mon répertoire personnel (par exemple .emacs), qui devraient être communs à toutes les machines sur lesquelles je travaille, mais disposer d'un second référentiel pour les fichiers locaux (par exemple .emacs.local) configurations spécifiques à la machine. Le seul moyen auquel je peux penser est de placer la configuration locale dans un sous-répertoire et d’ignorer ce sous-répertoire du référentiel git principal. D'autres idées?
Si je comprends ce que vous faites, vous pouvez gérer le tout dans un référentiel, en utilisant des branches distinctes pour chaque ordinateur et une branche contenant vos fichiers de configuration de répertoire de base habituel.
Initialisez le référentiel et validez-y les fichiers communs, en renommant éventuellement la branche MASTER en commun. Créez ensuite une branche distincte pour chaque ordinateur avec lequel vous travaillez et validez les fichiers spécifiques à cet ordinateur dans cette branche. Chaque fois que vous modifiez vos fichiers communs, fusionnez la branche commune dans chacune des branches de la machine et transmettez-la à vos autres machines (écrivez un script pour cela s'il y en a beaucoup).
Ensuite, sur chaque machine, vérifiez la branche de cette machine, qui inclura également les fichiers de configuration courants.
Cet article couvre ceci relativement bien:
En gros, si vous travaillez en ligne de commande, cela est plus simple que vous ne le pensez. Supposons que vous vouliez 2 Git Repos:
.gitone
.gittwo
Vous pouvez les configurer comme suit:
git init .
mv .git .gitone
git init .
mv .git .gittwo
Vous pouvez ajouter un fichier et le valider pour un seul comme ceci:
git --git-dir=.gitone add test.txt
git --git-dir=.gitone commit -m "Test"
Donc, les options pour git viennent en premier, puis la commande, puis les options de la commande git. Vous pouvez facilement assez alias une commande git comme:
#!/bin/sh
alias gitone='git --git-dir=.gitone'
alias gittwo='git --git-dir=.gittwo'
Vous pouvez donc vous engager dans l’un ou l’autre avec un peu moins de frappe, comme gitone commit -m "blah".
Ce qui semble devenir plus compliqué est ignoré. Étant donné que .gitignore se trouve normalement à la racine du projet, vous devez trouver un moyen de changer cela également sans changer la racine entière. Vous pouvez également utiliser .git/info/exclude, mais tous les ignorations que vous effectuez ne seront ni validées ni poussées, ce qui risquerait de nuire aux autres utilisateurs. D'autres utilisateurs de l'un ou l'autre des référentiels peuvent utiliser un fichier .gitignore, ce qui peut entraîner des conflits. Ce n'est pas clair pour moi la meilleure façon de résoudre ces problèmes.
Si vous préférez des outils graphiques tels que TortoiseGit, vous aurez également des problèmes. Vous pouvez écrire un petit script qui renomme temporairement .gitone ou .gittwo en .git pour que les hypothèses de ces outils soient satisfaites.
Jetez un coup d'œil à sous-module git .
Les sous-modules autorisent les référentiels étrangers être intégré dans un .__ dédié. sous-répertoire de l’arbre source, toujours pointé sur un commit particulier.
RichiH a écrit un outil appelé vcsh , outil permettant de gérer les fichiers de points à l’aide des faux dépôts non autorisés de git afin de mettre plusieurs répertoires de travail dans $ HOME. Rien à voir avec csh AFAIK.
Cependant, si vous avez plusieurs répertoires, une alternative à git-submodules (ce qui pose problème dans le meilleur des cas et cet exemple d'utilisation n'est pas le meilleur des cas) est gitslave qui laisse les mises en pension réduites en esclavage. la pointe d'une branche à tout moment et ne nécessite pas le processus en trois étapes pour effectuer une modification dans le dépôt secondaire (archiver la branche appropriée, effectuer et valider la modification, puis accéder au superprojet et commettre le nouveau commit du sous-module) .
Cela est possible en utilisant la variable GIT_DIR mais comporte de nombreuses mises en garde si vous ne savez pas ce que vous faites.
ma méthode préférée utilise un repo dans un sous-répertoire et utilise des liens symboliques récursifs:
git clone repo1
cd somerepo
git clone repo2
cd repo2
./build
où le fichier ' repo/build ' - ressemble à ceci:
#!/bin/bash
SELF_PATH="$(dirname "$(readlink -f "$0")" )" # get current dir
cd .. && git stash && git clean -f -d '' # remove previous symlinks
cp -sR "$SELF_PATH"/* ../. # create recursive symlinks in root
caution : ne pas utiliser 'git add.'
Oui, les sous-modules sont probablement ce que vous voulez. Une autre option consisterait à placer votre copie de travail dans un sous-répertoire, puis à pointer les liens symboliques de votre répertoire de départ vers les fichiers qui vous intéressent.
L’autre option consiste à créer des liens symboliques d’un dossier à l’autre dans des dossiers distincts.
Par exemple, s’il existe des référentiels:
- Repo1/DossierA
- Repo1/DossierB
Et:
- Repo2/DossierC
Vous pouvez créer un lien symbolique entre les dossiers FolderA et FolderB du repo1 au repo2. Pour Windows, la commande à exécuter sur le Repo1 serait:
User@Repo1$ mklink /J FullPath/Repo2/FolderA FullPath/Repo1/FolderA
User@Repo1$ mklink /J FullPath/Repo2/FolderB FullPath/Repo1/FolderB
User@Repo1$ printf "/FolderA/*\n/FolderB/*\n" >> .gitignore
Pour les fichiers des référentiels principaux, vous devez créer un lien symbolique pour chacun d'entre eux, en les ajoutant également au référentiel .gitignore pour éviter le bruit, à moins que vous ne le souhaitiez.
Disclaimer: Ceci n'est pas de la publicité. Je suis le développeur de la bibliothèque fournie.
J'ai créé une extension git pour gérer les cas dans lesquels vous souhaitez mélanger plusieurs référentiels dans un seul dossier. L'avantage de la lib est de garder une trace des référentiels et des conflits de fichiers. vous pouvez le trouver sur github . Il existe également 2 exemples de référentiels pour l'essayer.