Puis-je stocker le dossier .git en dehors des fichiers que je souhaite suivre?

J'ai une idée inhabituelle d'utiliser git comme système de sauvegarde. Alors disons que j'ai un répertoire ./backup/myfiles et je veux le sauvegarder en utilisant git. Pour garder les choses propres, je ne veux pas avoir de répertoire .git dans le dossier myfiles, alors j'ai pensé que je pourrais créer ./backup/git_repos/myfiles. En regardant la documentation git, j'ai essayé de faire ceci:

$ cd backup/myfiles
$ mkdir ../git_repos/myfiles
$ git --git-dir=../git_repos/myfiles init
Initialized empty Git repository in backup/git_repos/myfiles/
$ git --git-dir="../git_repos/myfiles/" add foo
fatal: pathspec 'foo' did not match any files

Vous pouvez voir le message d'erreur J'y arrive. Qu'est-ce que je fais mal?

git --git-dir=../repo --work-tree=. add foo

Cela fera ce que vous voulez mais sera évidemment nul lorsque vous devrez le spécifier avec chaque commande git que vous utiliserez.

Vous pouvez exporter GIT_WORK_TREE=.et GIT_DIR=../backupGit les récupérera à chaque commande. Cela ne vous permettra cependant que de travailler confortablement dans un seul référentiel par shell.

Je suggère plutôt de créer un lien symbolique vers le répertoire .git ailleurs ou de créer un lien symbolique vers le répertoire .git à partir de votre répertoire de sauvegarde principal.

Il vous suffit de vous assurer que le référentiel sait où se trouve l'arbre de travail et vice versa.

Pour indiquer au référentiel où se trouve l'arborescence de travail, définissez la valeur de configuration core.worktree. Pour que l'arborescence de travail sache où se trouve le répertoire git, ajoutez un fichier nommé .git (pas un dossier!) Et ajoutez une ligne comme

gitdir: /path/to/repo.git

Depuis git 1.7.5, la commande init a appris une option supplémentaire pour cela.

Vous pouvez initialiser un nouveau référentiel séparé avec

git init --separate-git-dir /path/to/repo.git

Cela initialisera le référentiel git dans le répertoire séparé et ajoutera le fichier .git dans le répertoire actuel, qui est le répertoire de travail du nouveau référentiel.

Avant la version 1.7.5, vous deviez utiliser des paramètres légèrement différents et ajouter vous-même le fichier .git.

Pour initialiser un référentiel distinct, la commande suivante relie l'arborescence de travail au référentiel:

git --git-dir=/path/to/repo.git --work-tree=. init && echo "gitdir: /path/to/repo.git" > .git

Votre répertoire actuel sera l'arborescence de travail et git utilisera le référentiel à /path/to/repo.git. La commande init définira automatiquement la core.worktreevaleur spécifiée avec le --git-dirparamètre.

Vous pouvez même ajouter un alias pour cela:

[alias]
    initexternal = !"f() { git --work-tree=. --git-dir=\"$1\" init && echo \"gitdir: $1\" >> .git; }; f"

Utiliser le contrôle de version git sur un répertoire de travail en lecture seule

Avec les connaissances ci-dessus, vous pouvez même configurer le contrôle de version git pour un répertoire de travail sans avoir les autorisations d'écriture. Si vous utilisez --git-dirsur chaque commande git ou exécutez chaque commande à partir du référentiel (au lieu du répertoire de travail), vous pouvez omettre le fichier .git et n'avez donc pas besoin de créer de fichiers dans le répertoire de travail. Voir aussi la réponse des Léos

L' --separate-git-diroption pour git init(et git clone) peut être utilisée pour accomplir cela sur ma version de git ( 1.7.11.3). L'option sépare le référentiel git de l'arborescence de travail et crée un lien symbolique git indépendant du système de fichiers (sous la forme d'un fichier nommé .git) à la racine de l'arborescence de travail. Je pense que le résultat est identique à la réponse de Niks .

git init --separate-git-dir path/to/repo.git path/to/worktree

Je trouve plus simple d'inverser les répertoires --work-treeet --git-dirutilisés dans la réponse de niks:

$ cd read_only_repos
$ git --work-tree=/some/readonly/location/foo/ --git-dir=foo init
$ cd foo
$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        .file_foo
        bar
        ...

Cette approche a deux avantages:

• Il supprime le besoin d'avoir des options de ligne de commande ou des .gitfichiers. Vous opérez simplement normalement à partir de la racine du référentiel.
• Il vous permet de versionner un système de fichiers même si vous ne le possédez pas. Git n'écrira que dans l'emplacement du référentiel.

La seule mise en garde que j'ai rencontrée est qu'au lieu d'utiliser un .gitignorefichier, vous modifiez info/exclude.

Vous pouvez ensuite utiliser le référentiel read_only_repos/foocomme distant dans vos propres référentiels même si les fichiers d'origine ne sont pas sous contrôle de version.

Il est conventionnel de nommer un répertoire qui est un dépôt git qui a son arbre de travail dans un endroit inhabituel avec une extension '.git', un peu comme un dépôt nu.

mkdir ../git_repos/myfiles.git

Si vous aviez fourni l' --work-treeoption au moment de l'initialisation, cela aurait automatiquement configuré la core.worktreevariable de configuration, ce qui signifie que git saura où trouver l'arborescence de travail une fois que vous aurez spécifié le répertoire git.

git --git-dir=../git_repos/myfiles.git --work-tree=. init

Mais vous pouvez également définir cette variable après coup.

git --git-dir=../git_repos/myfiles.git config core.worktree "$(pwd)"

Une fois que vous avez fait cela, la commande add devrait fonctionner comme prévu.

git --git-dir=../git_repos/myfiles.git add foo

Utiliser gità l'intérieur du repo:

cd ./backup/git_repos/myfiles
git init --bare
git config core.worktree ../myfiles
git config core.bare false

À partir de maintenant, vous pouvez utiliser gità l'intérieur du ./backup/git_repos/myfilesrépertoire, sans définir de variables d'environnement ni de paramètres supplémentaires.

Vous pouvez créer un script "nodgit" (No Dot GIT) avec quelque chose comme

#!/bin/sh
gits=/usr/local/gits
    x=`pwd`
    testdir() {( cd $1; pwd; )}
    while [ "$x" != "/" ]; do
      y=`echo $x|sed -e "s/\//__/g"`
      if ([ -d "$gits/$y" ]); then
        export GIT_DIR="$gits/$y"
        export GIT_WORK_TREE="$x"
        if ([ "$1" = "nodinit" ]); then
          mkdir -p "$GIT_DIR"
          git init --bare; exit $?
        elif ([ "$1" = "shell" ]); then
          bash; exit $?
        else
          exec git "$@"
        fi
      fi
      x=`testdir "$x/.."`
    done

Vous pouvez appeler nodgit à la place de git et il définira des variables si nécessaire en recherchant un dépôt git. Par exemple, disons que vous avez un dépôt (nu) dans / usr / local / gits / __ home__foo_wibbles et que vous êtes dans / home / foo / wibbles / one alors il trouvera le bon répertoire de travail (/ home / foo / wibbles) et le repo .

Oh, vous pouvez également utiliser "nodgit shell" pour obtenir un shell avec le bon jeu de variables afin que vous puissiez utiliser les anciennes commandes git.

En supposant que vos myfilesrépertoires existent déjà et contiennent du contenu, pourriez-vous vivre avec ceci:

cd ~/backup
git init
git add myfiles

Le .gitrépertoire sera dans backup, pas dans myfiles.

Je crée des scripts qui ressemblent à

~ / bin / git-slash:

#!/usr/bin/sh

export GIT_DIR=/home/Version-Control/cygwin-root.git/
export GIT_WORK_TREE=/

git --git-dir=$GIT_DIR --work-tree=$GIT_WORK_TREE "$@"

exit $?

Il est redondant d'utiliser --git_dir = $ GIT_DIR, mais cela me rappelle que je peux également définir des variables d'environnement en dehors du script.

L'exemple ci-dessus sert à suivre les modifications locales des fichiers système cygwin.

Je peux créer un tel script pour tout projet majeur qui en a besoin - mais / sans /.git est mon utilisation principale.

Ce qui précède est suffisamment petit pour créer un alias ou une fonction de shell, si vous éliminez la redondance.

Si je fais cela assez souvent, je raviverais l'espace de travail au mappage de référentiel de

"Boxes, Links, and Parallel Trees: Elements of a Configuration Management System", 
in Workshop Proceedings of the Software Management Conference. 1989.

dont l'homologue moderne le plus proche est les mappages ou vues Perforce , prenant en charge les extractions partielles ainsi que la non-colocation de l'espace de travail et du dépôt.