Zwei Git-Repositories in einem Verzeichnis?

Ist es möglich, 2 Git-Repositories in einem Verzeichnis zu haben? Ich würde nicht denken, aber ich dachte, ich würde fragen. Grundsätzlich möchte ich in meinem Home-Verzeichnis Konfigurationsdateien (z. B. .emacs) einchecken, die auf allen Maschinen, auf denen ich arbeite, gemeinsam sein sollten, aber ein zweites Repository für lokale Dateien (z. B. .emacs.local) enthalten maschinenspezifische Konfigurationen. Die einzige Möglichkeit, die mir dazu einfällt, besteht darin, die lokale Konfiguration in einem Unterverzeichnis zu haben und dieses Unterverzeichnis aus dem Haupt-Git-Repository zu ignorieren. Irgendwelche anderen Ideen?

Dieser Artikel behandelt dies relativ gut:

https://github.com/rrrene/gitscm-next/blob/master/app/views/blog/progit/2010-04-11-environment.markdown

Wenn Sie von der Befehlszeile aus arbeiten, ist dies im Grunde einfacher als Sie vielleicht vermuten. Angenommen, Sie möchten 2 Git-Repos:

.gitone
.gittwo

Du könntest sie so einrichten:

git init .
mv .git .gitone
git init .
mv .git .gittwo

Sie könnten eine Datei hinzufügen und sie wie folgt an nur eine übergeben:

git --git-dir=.gitone add test.txt
git --git-dir=.gitone commit -m "Test"

Also kommen zuerst die Optionen für git, dann der Befehl, dann die Optionen des git-Befehls. Sie könnten leicht genug einen Git-Befehl aliasieren wie:

#!/bin/sh
alias gitone="git --git-dir=.gitone"
alias gittwo='git --git-dir=.gittwo'

Sie können sich also mit etwas weniger Tippen auf das eine oder andere festlegen, z gitone commit -m "blah".

Was schwieriger zu werden scheint, ist das Ignorieren. Da sich .gitignore normalerweise im Projektstamm befindet, müssten Sie einen Weg finden, dies ebenfalls zu wechseln, ohne den gesamten Stamm zu wechseln. Oder Sie könnten .git/info/exclude verwenden, aber alle Ignorierungen, die Sie dann durchführen, werden nicht festgeschrieben oder gepusht – was andere Benutzer vermasseln könnte. Andere, die eines der Repos verwenden, könnten eine .gitignore-Datei pushen, was zu Konflikten führen kann. Mir ist nicht klar, wie ich diese Probleme am besten lösen kann.

Wenn Sie GUI-Tools wie TortoiseGit bevorzugen, stehen Sie ebenfalls vor einigen Herausforderungen. Sie könnten ein kleines Skript schreiben, das .gitone oder .gittwo vorübergehend in .git umbenennt, damit die Annahmen dieser Tools erfüllt werden.

Wenn ich verstehe, was Sie tun, können Sie alles in einem Repository handhaben, indem Sie separate Branches für jede Maschine und einen Branch verwenden, der Ihre gemeinsamen Konfigurationsdateien für das Home-Verzeichnis enthält.

Initialisieren Sie das Repo und übertragen Sie die gemeinsamen Dateien darauf, indem Sie möglicherweise den MASTER-Zweig in Common umbenennen. Erstellen Sie dann von dort aus einen separaten Zweig für jede Maschine, mit der Sie arbeiten, und übertragen Sie maschinenspezifische Dateien in diesen Zweig. Jedes Mal, wenn Sie Ihre gemeinsamen Dateien ändern, führen Sie den gemeinsamen Zweig mit jedem der Maschinenzweige zusammen und übertragen Sie ihn auf Ihre anderen Maschinen (schreiben Sie ein Skript dafür, wenn es viele gibt).

Checken Sie dann auf jeder Maschine den Zweig dieser Maschine aus, der auch die gemeinsamen Konfigurationsdateien enthält.

Schau mal rein git-Submodul.

Untermodule ermöglichen das Einbetten fremder Repositories in ein dediziertes Unterverzeichnis des Quellbaums, das immer auf ein bestimmtes Commit zeigt.

RichiH schrieb ein Tool namens vcsh welches ein Tool zum Verwalten von Punktdateien mit gits gefälschten Bare-Repos ist, um mehr als ein Arbeitsverzeichnis in $HOME abzulegen. Nichts mit csh AFAIK zu tun.

Wenn Sie jedoch mehrere Verzeichnisse haben, ist eine Alternative zu git-submodules (die unter den besten Umständen ein Problem sind und diese Beispielverwendung nicht die besten Umstände ist) Gitslave wodurch die Slave-Repos jederzeit an der Spitze eines Zweigs ausgecheckt bleiben und der dreistufige Prozess nicht erforderlich ist, um eine Änderung im untergeordneten Repo vorzunehmen (Auschecken auf den richtigen Zweig, Vornehmen und Festschreiben der Änderung, dann Wechseln in die Superprojekt und Commit des neuen Submoduls Commit).

Es ist möglich, indem Sie die Variable verwenden GIT_DIR hat aber viele Vorbehalte, wenn Sie nicht wissen, was Sie tun.

Ja, Untermodule sind wahrscheinlich das, was Sie wollen. Eine andere Möglichkeit wäre, Ihre Arbeitskopie in einem Unterverzeichnis zu haben und dann Symlinks von Ihrem Home-Verzeichnis auf die interessierenden Dateien zu verweisen.

Meine bevorzugte Methode ist die Verwendung eines Repos in einem Unterverzeichnis und die Verwendung rekursiver symbolischer Links:

git clone repo1
cd somerepo
git clone repo2
cd repo2
./build

bei dem die ‘Repo/Build‘-Datei sieht so aus:

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

Vorsicht: Verwenden Sie nicht ‘git add .’