Zwei Git-Repositories in einem Verzeichnis?

Lesezeit: 6 Minuten

Zwei Git Repositories in einem Verzeichnis
Joe Casadonte

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?

  • git subtree wird die Arbeit erledigen.

    – Syd Pao

    11. November 2016 um 6:48 Uhr


  • Wenn Sie es nicht mit zu vielen Dateien zu tun haben, können Sie auch Symlinks/Junctions erstellen.

    – thdoan

    27. November 2018 um 17:22 Uhr

1646642887 619 Zwei Git Repositories in einem Verzeichnis
Chris Moschini

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 Sie es als Alias ​​festlegen, wird dieser Fehler ausgegeben: $ git config –global alias.pub ‘–git-dir=~/Server/www/.gitpublic’ $ git pub add . fatal: Alias ​​’pub’ ändert Umgebungsvariablen Sie können dazu ‘!git’ im Alias ​​verwenden. Wo würden Sie in diesem Fall das “!git” setzen?

    – JaredBroad

    20. Juli 2014 um 19:45 Uhr

  • @JaredBroad Interessant – Ich habe vorgeschlagen, dass Sie einen Bash-Alias ​​verwenden, keinen Git-Alias. Wie alias gitone='git --git-dir=.gitone'

    – Chris Moschini

    20. Juli 2014 um 22:55 Uhr

  • Sie können die Repos so konfigurieren, dass sie ihre eigenen Ausschlussdateien verwenden, und Sie können diese verfolgen, dh gitone config core.excludesfile gitone.exclude und gitone add gitone.exclude. Ich habe ein Skript erstellt, das diese Lösung erweitert: github.com/capr/multigit

    Benutzer519179

    9. April 2015 um 6:06 Uhr


  • @JaredBroad Ich habe es so gemacht git config --global alias.youralias '!git --git-dir="/d/MyProject/_git"' dann git youralias status 🙂

    – Starikows

    19. September 2016 um 15:29 Uhr

  • Wenn Sie davon ausgehen .gitignore Dateien werden normalerweise gesetzt und vergessen, dann können Sie für jedes Repo unterschiedliche Kopien erstellen und dann die relevante Version als Teil des Alias ​​​​in das Verzeichnis kopieren. Dies gilt für andere Dateien im Stammverzeichnis, die möglicherweise Konflikte verursachen, wie z README.md und .gitattributes.

    – thdoan

    27. November 2018 um 17:55 Uhr


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.

  • Während Submodule auch funktionieren werden, denke ich, dass dies der beste Ansatz für mich ist. Die lokalen Dateien folgen einer Vorlage, und wenn ich Änderungen an der Vorlage im MASTER-Zweig vornehme, kann ich sie mit den lokalen Zweigen der Maschine zusammenführen und die lokalen Konfigurationsdateien inkrementell aktualisieren. Danke für die Hilfe!

    – Joe Casadonte

    14. Januar 2009 um 13:43 Uhr

  • Verwenden Sie sowohl Mercurial als auch Git.

    – Linc

    26. August 2020 um 6:08 Uhr

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.

  • Nicht gut für Dateien, die sich im Stammverzeichnis Ihres Verzeichnisses befinden müssen. Die einzige Chance besteht darin, die Wurzel der Symlinks zu diesen zu füllen.

    – WhyNotHugo

    22. November 2010 um 20:57 Uhr

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

1646642888 935 Zwei Git Repositories in einem Verzeichnis
zervo

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

1646642888 341 Zwei Git Repositories in einem Verzeichnis
Pat Notz

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.

1646642889 171 Zwei Git Repositories in einem Verzeichnis
coderofsalvation

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

964520cookie-checkZwei Git-Repositories in einem Verzeichnis?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy