Bir dizinde iki git deposu mu?

Bir dizinde 2 git deposuna sahip olmak mümkün mü? Sanmıyorum ama sorayım dedim. Temel olarak, üzerinde çalıştığım tüm makinelerde ortak olması gereken, ancak yerel dosyalar için ikinci bir depoya (örn. .Emacs.local) sahip olan, ana dizin yapılandırma dosyalarımı (örn. .Emacs) kontrol etmek istiyorum. makineye özel konfigürasyonlar. Bunu yapmayı düşünebildiğim tek yol, bir alt dizinde yerel yapılandırmaya sahip olmak ve bu alt dizini ana git deposundan yok saymaktır. Başka fikir var mı?

Ne yaptığınızı anlarsam, her makine için ayrı dallar ve ortak ev dizini yapılandırma dosyalarınızı içeren bir dal kullanarak hepsini tek bir depoda halledebilirsiniz.

Depoyu başlatın ve ortak dosyaları ona işleyin, belki MASTER şubesini Ortak olarak yeniden adlandırın. Ardından, çalıştığınız her makine için oradan ayrı bir dal oluşturun ve makineye özgü dosyaları bu dala işleyin. Ortak dosyalarınızı her değiştirdiğinizde, ortak dalı her bir makine dalına birleştirin ve diğer makinelerinize itin (çok sayıda varsa bunun için bir komut dosyası yazın).

Daha sonra, her makinede, makinenin ortak yapılandırma dosyalarını da içerecek şubesini kontrol edin.

Bu makale bunu nispeten iyi bir şekilde kapsamaktadır:

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

Temelde komut satırından çalışıyorsanız, bu tahmin edebileceğinizden daha basittir. 2 git deposu istediğinizi varsayalım:

.gitone
.gittwo

Bunları şu şekilde kurabilirsiniz:

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

Bir dosya ekleyebilir ve bu şekilde yalnızca bir dosyaya işleyebilirsiniz:

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

Yani git için seçenekler önce gelir, sonra komut, sonra git komutunun seçenekleri. Bir git komutunu aşağıdaki gibi kolayca takma ad yapabilirsiniz:

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

Böylece, biraz daha az yazarak birini veya diğerini taahhüt edebilirsiniz, örneğin gitone commit -m "blah" .

Daha da karmaşık görünen şey görmezden gelmektir. .Gitignore normalde proje kökünde oturduğundan, tüm kökü değiştirmeden bunu da değiştirmenin bir yolunu bulmanız gerekir. Veya .git / info / exclude kullanabilirsiniz, ancak gerçekleştirdiğiniz tüm yok saymalar tamamlanmayacak veya itilmeyecektir - bu da diğer kullanıcıları mahvedebilir. Depolardan birini kullanan diğerleri, çatışmalara neden olabilecek bir .gitignore gönderebilir. Bu sorunları çözmenin en iyi yolu benim için net değil.

TortoiseGit gibi GUI araçlarını tercih ederseniz, bazı zorluklarla da karşılaşabilirsiniz. Geçici olarak .gitone veya .gittwo'yu .git olarak yeniden adlandıran küçük bir komut dosyası yazabilirsiniz, böylece bu araçların varsayımları karşılanır.

Git alt modülüne bir göz atın .

Alt modüller, yabancı depoların kaynak ağacının özel bir alt dizinine gömülmesine izin verir ve her zaman belirli bir kesinliğe işaret eder.

RichiH bir araç olarak adlandırılan yazdı vcsh bir araçtır $ HOME içine birden fazla çalışma dizini koymak için git sahte çıplak repo kullanarak dotfiles yönetmek için. Csh AFAIK ile ilgisi yok.

Bununla birlikte, birden fazla dizininiz varsa, git-alt modüllerine bir alternatif (ki bu en iyi koşullarda bir sıkıntıdır ve bu örnek kullanım en iyi koşullar değildir), köle depolarını bir ucunda kontrol edilen gitslave'dir . her zaman şubeye girer ve yan kuruluş deposunda değişiklik yapmak için üç aşamalı süreci gerektirmez (doğru şubeye giriş yapın, değişikliği yapın ve uygulayın, ardından süper projeye gidin ve yeni alt modül taahhüdünü uygulayın).

Değişkeni kullanarak mümkündür, GIT_DIRancak ne yaptığınızı bilmiyorsanız birçok uyarı vardır.

Evet, alt modüller muhtemelen istediğiniz şeydir. Diğer bir seçenek, çalışma kopyanızın bir alt dizinde olması ve ardından ana dizininizdeki sembolik bağları ilgilendiğiniz dosyalara yönlendirmektir.

tercih ettiğim yöntem, bir alt dizinde bir depo kullanmak ve özyinelemeli sembolik bağlantılar kullanmaktır:

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

' repo / build ' dosyasının göründüğü yer:

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

dikkat : 'git add' kullanmayın.

Diğer seçenek, ayrı klasörlerde olmaları ve bir klasörden diğerine sembolik sabit bağlantılar oluşturmalarıdır.

Örneğin, depolar varsa:

1. Repo1 / KlasörA
2. Repo1 / KlasörB

Ve:

1. Repo2 / KlasörC

Klasörleri FolderAve FolderBRepo1'den Repo2'ye sembolik bağlayabilirsiniz. Windows için Repo1'de çalıştırılacak komut şöyle olacaktır:

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

Ana depolardaki dosyalar için, her birini sembolik olarak bağlamanız, ayrıca .gitignoreistemediğiniz sürece gürültüyü önlemek için bunları depoya eklemeniz gerekir .

Sorumluluk Reddi: Bu reklam değildir. Sağlanan kitaplığın geliştiricisiyim.

Birden çok depoyu tek bir klasörde karıştırmak istediğiniz durumları ele almak için bir git uzantısı oluşturdum. Kitaplığın avantajı, depoları ve dosya çakışmalarını takip etmektir. github'da bulabilirsiniz . Denemek için 2 örnek depo da var.