Kann ich den .git-Ordner außerhalb der Dateien speichern, die ich verfolgen möchte?

Ich habe eine ungewöhnliche Idee, Git als Backup-System zu verwenden. Nehmen wir also an, ich habe ein Verzeichnis ./backup/myfiles und möchte dieses mit git sichern. Um die Dinge sauber zu halten, möchte ich kein .git-Verzeichnis im Ordner myfiles haben, also dachte ich, ich könnte ./backup/git_repos/myfiles erstellen. Beim Betrachten der Git-Dokumente habe ich Folgendes versucht:

$ 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

Sie können die Fehlermeldung sehen, die ich dort erhalte. Was mache ich falsch?

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

Dies wird tun, was Sie wollen, wird aber offensichtlich scheiße sein, wenn Sie es mit jedem Git-Befehl angeben müssen, den Sie jemals verwenden.

Sie können exportieren GIT_WORK_TREE=.und GIT_DIR=../backupGit holt sie bei jedem Befehl ab. Dadurch können Sie jedoch nur bequem in einem einzigen Repository pro Shell arbeiten.

Ich würde eher vorschlagen, das .git-Verzeichnis mit einem anderen Ort zu verknüpfen oder einen Symlink mit dem .git-Verzeichnis aus Ihrem Hauptsicherungsverzeichnis zu erstellen.

Sie müssen nur sicherstellen, dass das Repository weiß, wo sich der Arbeitsbaum befindet und umgekehrt.

Legen Sie den Konfigurationswert fest, damit das Repository weiß, wo sich der Arbeitsbaum befindet core.worktree. Fügen Sie eine Datei mit dem Namen .git (kein Ordner!) Und eine Zeile wie hinzu, um dem Arbeitsbaum mitzuteilen, wo sich das Git-Verzeichnis befindet

gitdir: /path/to/repo.git

Seit git 1.7.5 hat der Befehl init eine zusätzliche Option dafür gelernt.

Sie können ein neues separates Repository mit initialisieren

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

Dadurch wird das Git-Repository im separaten Verzeichnis initialisiert und die Git-Datei im aktuellen Verzeichnis hinzugefügt, das das Arbeitsverzeichnis des neuen Repositorys ist.

Vor 1.7.5 mussten Sie leicht unterschiedliche Parameter verwenden und die .git-Datei selbst hinzufügen.

Um ein separates Repository zu initialisieren, verknüpft der folgende Befehl den Arbeitsbaum mit dem Repository:

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

Ihr aktuelles Verzeichnis ist der Arbeitsbaum und Git verwendet das Repository unter /path/to/repo.git. Der Befehl init setzt automatisch den core.worktreemit dem --git-dirParameter angegebenen Wert .

Sie können sogar einen Alias ​​hinzufügen:

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

Verwenden Sie die Git-Versionskontrolle für ein schreibgeschütztes Arbeitsverzeichnis

Mit den oben genannten Kenntnissen können Sie sogar die Git-Versionskontrolle für ein Arbeitsverzeichnis einrichten, ohne über Schreibberechtigungen zu verfügen. Wenn Sie entweder --git-dirfür jeden git-Befehl verwenden oder jeden Befehl aus dem Repository (anstelle des Arbeitsverzeichnisses) ausführen, können Sie die .git-Datei weglassen und müssen daher keine Dateien im Arbeitsverzeichnis erstellen. Siehe auch Leos Antwort

Die --separate-git-dirOption für git init(und git clone) kann verwendet werden, um dies in meiner Version von git ( 1.7.11.3) zu erreichen. Die Option trennt das Git-Repository vom Arbeitsbaum und erstellt .gitim Stammverzeichnis des Arbeitsbaums einen dateisystemunabhängigen symbolischen Git-Link (in Form einer Datei mit dem Namen ). Ich denke, das Ergebnis ist identisch mit der Antwort von Niks .

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

Ich finde es einfacher, die in der Antwort von niks verwendeten Verzeichnisse --work-treeund umzukehren :--git-dir

$ 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
        ...

Dieser Ansatz hat zwei Vorteile:

• Es werden keine Befehlszeilenoptionen oder .git-dateien mehr benötigt. Sie arbeiten einfach normal im Stammverzeichnis des Repositorys.
• Sie können ein Dateisystem auch dann versionieren, wenn Sie es nicht besitzen. Git schreibt nur in den Repository-Speicherort.

Die einzige Einschränkung, auf die ich gestoßen bin, ist, dass Sie anstelle der Verwendung einer .gitignoreDatei bearbeiten info/exclude.

Sie können das Repository dann read_only_repos/fooals Remote in Ihren eigenen Repositorys verwenden, auch wenn die Originaldateien nicht der Versionskontrolle unterliegen.

Es ist üblich, ein Verzeichnis zu benennen, bei dem es sich um ein Git-Repository handelt, dessen Arbeitsbaum sich an einem ungewöhnlichen Ort mit der Erweiterung '.git' befindet, ähnlich wie bei einem nackten Repository.

mkdir ../git_repos/myfiles.git

Wenn Sie die --work-treeOption zur Init-Zeit angegeben hätten, hätte dies automatisch die core.worktreeKonfigurationsvariable eingerichtet, was bedeutet, dass git weiß, wo sich der Arbeitsbaum befindet, sobald Sie das git-Verzeichnis angegeben haben.

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

Sie können diese Variable aber auch nachträglich festlegen.

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

Sobald Sie dies getan haben, sollte der Befehl add wie erwartet funktionieren.

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

Verwendung gitim Repo:

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

Von nun an können Sie gitinnerhalb des ./backup/git_repos/myfilesVerzeichnisses verwenden, ohne Umgebungsvariablen oder zusätzliche Parameter festzulegen.

Sie könnten ein "Nodgit" -Skript (No Dot GIT) mit so etwas wie erstellen

#!/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

Sie können nodgit anstelle von git aufrufen und es werden nach Bedarf Variablen festgelegt, indem nach einem git-Repo gesucht wird. Angenommen, Sie haben ein (nacktes) Repo in / usr / local / gits / __ home__foo_wibbles und Sie befinden sich in / home / foo / wibbles / one. Dann wird das richtige Arbeitsverzeichnis (/ home / foo / wibbles) und Repo gefunden .

Oh, Sie können auch "nodgit shell" verwenden, um eine Shell mit den richtigen vars zu erhalten, so dass Sie einfache alte git-Befehle verwenden können.

Angenommen, Ihre myfilesVerzeichnisse sind bereits vorhanden und enthalten Inhalte. Könnten Sie damit leben:

cd ~/backup
git init
git add myfiles

Das .gitVerzeichnis befindet sich in backup, nicht in myfiles.

Ich erstelle Skripte, die aussehen

~ / 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 $?

Die Verwendung von --git_dir = $ GIT_DIR ist überflüssig, erinnert mich jedoch daran, dass ich Umgebungsvariablen auch außerhalb des Skripts festlegen kann.

Das obige Beispiel dient zum Verfolgen lokaler Änderungen an Cygwin-Systemdateien.

Kann ein solches Skript für jedes größere Projekt erstellen, das dies benötigt - aber / ohne /.git ist meine Hauptverwendung.

Das Obige ist klein genug, um einen Shell-Alias ​​oder eine Shell-Funktion zu erstellen, wenn Sie die Redundanz beseitigen.

Wenn ich dies oft genug mache, würde ich den Arbeitsbereich für die Repository-Zuordnung von wiederbeleben

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

Das nächste moderne Gegenstück sind Perforce-Zuordnungen oder -Ansichten , die teilweise Auschecken sowie die Nicht-Colocation von Arbeitsbereich und Repo unterstützen.