Git? İle çoklu çalışma dizinleri?

Bunun Git tarafından desteklenen bir şey olup olmadığından emin değilim, ancak teorik olarak bana çalışacak gibi görünüyor.

İş akışım genellikle dosyaları aynı anda birden çok dalda düzenlememi içeriyor. Başka bir deyişle, genellikle bir dalda birkaç dosya açmak istiyorum, başka bir daldaki başka bir dosyanın içeriğini düzenlerken.

Buna tipik çözümüm iki ödeme yapmak, ancak aralarında şubeleri ve refleri paylaşamaması utanç verici. Ne istiyorum sadece aynı .git klasörü tarafından yönetilen iki çalışma dizinleri var.

Yerel git klon çözümlerinin farkındayım (varsayılan, paylaşılan nesneleri sabit bağlamaktır ve orijinal repo ile alternatif bir nesne deposu oluşturan --shared seçeneği), ancak bu çözümler yalnızca disk alanı kullanımını azaltır ve özellikle - paylaşımlı durumunda, tehlikeyle dolu görünüyor.

Bir .git klasörü kullanmanın ve onun tarafından desteklenen iki çalışma dizinine sahip olmanın bir yolu var mı? Yoksa Git herhangi bir anda yalnızca bir çalışma dizini kullanıma alınmış mı?

Git 2.5 Temmuz 2015'ten bu yana yeni bir ürün önerdi contrib/workdir/git-new-workdir: Git Worktree

Bkz 68a2e6a tamamlama ile Junio Cı Hamano ( gitster) .

Sürüm notu bahseder :

Bunun yerine contrib/workdir/git-new-workdirsembolik bağlantılara güvenilmez ve borçlu ile borçluları birbirlerinden haberdar ederek nesnelerin ve referansların paylaşımını daha güvenli hale getirmez.

Bkz. Taahhüt 799767cc9 (Git 2.5rc2)

Bu, artık birgit worktree add <path> [<branch>]

Oluşturun <path>ve satın <branch>alın. Yeni çalışma dizini vb KAFA, endeks olarak dizin belirli dosyaları çalışma dışında her şeyi paylaşan akım deposuna bağlı olan git worktreebölüm ekler:

Git deposu birden çok çalışma ağacını destekleyebilir ve aynı anda birden fazla dalı kontrol etmenizi sağlar.
İle git worktree add, depoyla yeni bir çalışma ağacı ilişkilendirilir.

Bu yeni çalışma ağacına " git init" veya " git clone" tarafından hazırlanan "ana çalışma ağacının" aksine "bağlantılı çalışma ağacı" denir .
Bir havuzun bir ana çalışma ağacı (çıplak bir depo değilse) ve sıfır veya daha fazla bağlantılı çalışma ağacı vardır.

ayrıntıları:

Bağlı her çalışma ağacının deponun dizininde özel bir alt $GIT_DIR/worktreesdizini vardır.
Özel alt yöneticinin adı genellikle bağlantılı çalışma ağacının yolunun temel adıdır ve muhtemelen benzersiz kılmak için bir numara eklenir.
Örneğin $GIT_DIR=/path/main/.git, komut git worktree add /path/other/test-next nextoluşturduğunda:

• bağlı çalışan ağaç /path/other/test-nextve
• Ayrıca yaratan $GIT_DIR/worktrees/test-nextdizini (veya $GIT_DIR/worktrees/test-next1eğer test-nextzaten alınmış).

Bağlantılı bir çalışma ağacında:

• $GIT_DIRbu özel dizini gösterecek şekilde ayarlanmışsa (örneğin /path/main/.git/worktrees/test-nextörnekte) ve
• $GIT_COMMON_DIRana çalışma ağacının $GIT_DIR(ör /path/main/.git.)

Bu ayarlar .git, bağlı çalışma ağacının en üst dizininde bulunan bir dosyada yapılır .

Bağlantılı bir çalışma ağacıyla işiniz bittiğinde silebilirsiniz.
Depoda çalışan ağacın idari dosyalar sonunda (bkz otomatik olarak silinecektir gc.pruneworktreesexpireiçinde git config) veya çalıştırabilir git worktree pruneherhangi bayat idari dosyaları temizlemek için ana veya herhangi bir bağlı çalışan ağacında.

Uyarı: Dikkat edilmesi gereken bir git worktree"HATA" bölümü var.

Alt modüller için destek eksiktir .
Bir süper projenin birden fazla check-out yapılması önerilmez.

Not: git 2.7rc1 (Kasım 2015) ile size edebiliyoruz listelemek için worktrees.
Bkz bb9c03b işlemek , 92718b7 taahhüt , 5193490 taahhüt , 1ceb7f9 taahhüt , 1ceb7f9 taahhüt , 5193490 taahhüt , 1ceb7f9 taahhüt , 1ceb7f9 taahhüt , (2015 08 Eki) 92718b7 işlemek , 5193490 taahhüt , 1ceb7f9 taahhüt , 1ceb7f9 taahhüt , (2015 08 Eki) 5193490 işlemek , 1ceb7f9 (08 Ekim 2015), 1ceb7f9 (08 Eki 2015) taahhüt ve ac6c561(02 Eki 2015) tarafından Michael Rappazzo ( rappazzo) .
^{(Göre Birleştirilmiş Junio Cı Hamano - gitster- içinde a46dcfb tamamlama , 26 Ekim 2015)}

worktree: add ' list' komutu

' git worktree list' çalışma listesi listesini tekrarlar ve çalışma ağacının yolu, şu anda kullanıma alınmış revizyon ve şube ve çalışma ağacının çıplak olup olmadığı da dahil olmak üzere çalışma ağacının ayrıntılarını verir.

$ git worktree list
/path/to/bare-source            (bare)
/path/to/linked-worktree        abcd1234 [master]
/path/to/other-linked-worktree  1234abc  (detached HEAD)

Ayrıca porselen format seçeneği de mevcuttur.

Porselen biçimin özellik başına bir satırı vardır.

• Nitelikler, tek bir boşlukla ayrılmış bir etiket ve değerle listelenir.
• Boolean öznitelikleri ('çıplak' ve 'ayrılmış' gibi) yalnızca etiket olarak listelenir ve yalnızca ve yalnızca değer doğruysa bulunur.
• Boş bir çizgi, bir çalışma ağacının sonunu gösterir

Örneğin:

$ git worktree list --porcelain

worktree /path/to/bare-source
bare

worktree /path/to/linked-worktree
HEAD abcd1234abcd1234abcd1234abcd1234abcd1234
branch refs/heads/master

worktree /path/to/other-linked-worktree
HEAD 1234abc1234abc1234abc1234abc1234abc1234a
detached

Not: bir çalışma ağacı klasörünü TAŞIYORSANIZ dosyayı manuel olarak güncellemeniz gerekir gitdir.

Bkz. Taahhüt 618244e (22 Ocak 2016) ve taahhüt d4cddd6 (18 Ocak 2016), Nguyễn Thái Ngọc Duy ( pclouds) .
Yardım eden: Eric Sunshine ( sunshineco) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde d0a1cbc tamamlama 2016 Şubat 10)}

Git 2.8'deki (Mart 2016) yeni doküman şunları içerecek:

Bağlantılı bir çalışma ağacını taşırsanız gitdir, giriş dizinindeki ' ' dosyasını güncelleştirmeniz gerekir .
Örneğin, bağlı bir çalışma ağacı adresine taşınmışsa /newpath/test-nextve .gitdosyası işaret ediyorsa /path/main/.git/worktrees/test-next, bunun yerine /path/main/.git/worktrees/test-next/gitdirbaşvurmak üzere güncelleştirin /newpath/test-next.

Bir dalı silerken dikkatli olun: git 2.9'dan (Haziran 2016) önce, başka bir çalışan ağaçta kullanımda olanı silebilirsiniz .

" git worktree" Özelliği kullanıldığında, " git branch -d" başka bir çalışma ağacında teslim alınan bir dalın silinmesine izin verdi.

Bkz . Kazuki Yamaguchi ( ) tarafından f292244 (29 Mar 2016) taahhüdü . Yardım eden: Eric Sunshine ( ) . ^{(Göre Birleştirilmiş - Junio Cı Hamano - içinde 4fca4e3 tamamlama 2016, 13 May)}rhenium
sunshineco
gitster

branch -d: şu anda kullanıma alınmış bir şubeyi silmeyi reddetme

Bir dal geçerli çalışan ağaç tarafından teslim alındığında, dalın silinmesi yasaktır.
Ancak dal yalnızca diğer çalışan ağaçlar tarafından teslim alındığında, hatalı silme işlemi başarılı olur. Sadece mevcut çalışma ağacının KAFA ile karşılaştırmakla kalmayıp dalın
kullanımda find_shared_symref()olup olmadığını kontrol etmek için kullanın.

Benzer şekilde, git 2.9'dan (Haziran 2016) önce, başka bir çalışma ağacında kontrol edilen bir şubenin yeniden adlandırılması, söz konusu diğer çalışma ağacındaki sembolik KAFA'yı ayarlamadı.

Bkz. Taahhüt 18eb3a9 (08 Nis 2016) ve taahhüt 70999e9 , taahhüt 2233066 (27 Mar 2016) Kazuki Yamaguchi ( rhenium) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 741a694 tamamlama 2016, 18 May)}

branch -m: iş başına tüm HEAD'leri güncelleyin

Bir dalı yeniden adlandırırken, şu anda yalnızca geçerli çalışma ağacının HEAD'i güncellenir, ancak eski şubeye işaret eden tüm çalışan ağaçların HEAD'lerini güncellemesi gerekir.

Bu geçerli davranıştır, / path / to / wt HEAD güncellenmez:

  % git worktree list
  /path/to     2c3c5f2 [master]
  /path/to/wt  2c3c5f2 [oldname]
  % git branch -m master master2
  % git worktree list
  /path/to     2c3c5f2 [master2]
  /path/to/wt  2c3c5f2 [oldname]
  % git branch -m oldname newname
  % git worktree list
  /path/to     2c3c5f2 [master2]
  /path/to/wt  0000000 [oldname]

Bu düzeltme eki, bir şube yeniden adlandırılırken ilgili tüm çalışma ağacı HEAD'lerini güncelleştirerek bu sorunu giderir.

Kilitleme mekanizması git 2.10 (Q3 2016) ile resmen desteklenmektedir

Bakınız taahhüt 080739b , taahhüt 6d30862 , taahhüt 58142c0 , taahhüt 346ef53 , taahhüt 346ef53 , taahhüt 58142c0 , taahhüt 346ef53 , taahhüt 346ef53 (13 Haziran 2016) ve taahhüt 984ad9e , taahhüt 6835314 (03 Haz 2016), Nguyễn Thái Ngọc Duy ( pclouds) .
Önerilen: Eric Sunshine ( sunshineco) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 2c608e0 tamamlama 2016, 28 Tem)}

git worktree lock [--reason <string>] <worktree>
git worktree unlock <worktree>

Bağlı bir çalışma ağacı, her zaman bağlanmayan taşınabilir bir aygıtta veya ağ paylaşımında depolanırsa git worktree lock, isteğe bağlı --reasonolarak çalışma ağacının neden kilitlendiğini açıklayarak , komut vererek yönetim dosyalarının budanmasını önleyebilirsiniz .

<worktree>: Çalışma ağacının yolundaki son yol bileşenleri çalışma ağaçları arasında benzersizse, çalışma ağaçlarını tanımlamak için kullanılabilir.
Örneğin, yalnızca " /abc/def/ghi" ve " /abc/def/ggg" ağaçlarında çalışmak zorundaysanız , " ghi" veya " def/ghi" eski çalışma ağacını işaret etmek için yeterlidir.

Git 2.13 (Q2 2017) bir ekleme lockseçeneği de 507e6e9 taahhüt tarafından (2017 Nisan 12) Nguyen Tay Ngọc Duy ( pclouds) .
Önerilen: David Taylor ( dt) .
Yardım eden: Jeff King ( peff) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde e311597 tamamlama 2017 26 Apr)}

Bir çalışma ağacını oluşturulduktan hemen sonra kilitlemeye izin verin.
Bu, " git worktree add; git worktree lock" ve " git worktree prune" arasında bir yarışın önlenmesine yardımcı olur .

Yani git worktree add' --lock eşdeğerdir git worktree locksonra git worktree addancak yarış durumu olmadan.

Git 2.17+ (2. Çeyrek 2018) ekler git worktree move/ git worktree remove: bu cevaba bakınız .

Git 2.19 (3. Çeyrek 2018) --quiet" git worktree add" daha az ayrıntılı yapmak için bir " " seçeneği ekliyor.

Bakınız Elia Pinto ( ) tarafından 371979c (15 Ağu 2018) taahhüdü . Yardım eden: Martin Ågren, Duy Nguyen ( ) ve Eric Sunshine ( ) . ^{(Tarafından Birleştirilmiş - Junio C Hamano - içinde a988ce9 taahhüt 2018 27 Ağustos)}devzero2000
pcloudssunshineco
gitster

worktree: --quietseçenek ekle

Diğer komutlarda olduğu gibi ' --quiet' seçeneğini ekleyin . ' ' dışındaki tüm komutlar şu anda varsayılan olarak sessiz olduğundan, ' ' etkilenen tek komuttur .git worktreegit
addlist

" git worktree add" , " Stat ile kullanılabilir bir ad bulun ve sonra mkdiryarışa eğilimli" olarak kullanılır.
Bu, bir döngü içinde kullanarak mkdirve buna tepki vererek Git 2.22 (Q2 2019) ile düzeltildi EEXIST.

Bakınız Michal Suchanek ( ) tarafından 7af01f2 (20 Şub 2019) taahhüdü . ^{(Göre Birleştirilmiş - Junio Cı Hamano - içinde 20fe798 tamamlama 2019 09 Apr)}hramrach
gitster

worktree: worktree addyarışı düzeltin

Git, kullanılabilen bir çalışma ağacı adı bulmak için bir stat döngüsü çalıştırır ve ardından mkdirbulunan adda çalışır. Aynı ücretsiz adı bulmak ve önce dizini oluşturmak eklemek çalışma ağacı başka bir çağırma önlemek
için mkdirdöngü için çevirin .

Git 2.22 (2. Çeyrek 2019), Git deposunun çalışan bir ağacı olup olmadığını anlamak için mantığı düzeltir ve " git branch -D" şu anda yanlışlıkla teslim alınan dalı kaldırmasını önler.
Bu mantığın uygulanması, bu günlerde maalesef alt modüllerin normu olan olağandışı isme sahip depolar için kırıldı.

Bakınız Jonathan Tan ( ) tarafından f3534c9 (19 Nis 2019) taahhüdü . ^{(Göre Birleştirilmiş Junio Cı Hamano - - içinde ec2642a tamamlama 2019 08 Mayıs)}jhowtan
gitster

Kod Çekme istekleri 178 Analizler

worktree: is_barebuluşsal yöntemler

" git branch -D <name>" Çalıştırıldığında, Git genellikle önce bu dalın kullanıma alınmış olup olmadığını kontrol eder.
Ancak bu deponun Git dizini " <repo>/.git" değerinde değilse, bu denetim gerçekleştirilmez ; bu, söz konusu deponun Git dizini " super/.git/modules/<repo>" olarak depolanmış bir alt modül olması durumudur .
Bu, dalın kullanıma alınmış olmasına rağmen silinmesine neden olur.

Bunun nedeni get_main_worktree()de worktree.csetleri is_baresadece worktree yolunun "sona etmezse bir Repo çıplak olduğunu sezgiseli kullanan bir worktree üzerine /.git", ve aksi takdirde çıplak değil.
Bu is_barekod, bir sezgisel tarama sonrasında 92718b7'de (" worktree: çalışma ağacı yapısına ayrıntılar ekle", 2015-10-08, Git v2.7.0-rc0) tanıtıldı pre-core.bare.

Bu yama 2 şey yapar:

• Bunun yerine get_main_worktree()kullanmayı öğretin is_bare_repository(), 7d1864c ("is_bare_repository () ve core.bare yapılandırma değişkeni ile tanışın", 2007-01-07, Git v1.5.0-rc1) ile tanıtıldı ve e90fdc3 ("Çalışma ağacı işlemeyi temizleme", 2007'de güncellendi) -08-01, Git v1.5.3-rc4).
  Bu git branch -D <name>, yukarıda açıklanan " " sorununu çözer .

Ancak ... Bir havuz ikincil çalışma ağaçlarından birinden çalıştırılıyor core.bare=1ancak " git" komutu çalıştırılıyorsa, is_bare_repository()false değerini döndürür (bu bir çalışma ağacı olduğu için iyidir).

Ve ana çalışma ağacına çıplak olduğunda çıplak olarak davranmak sorunlara neden olur:

Örneğin, ana çalışma ağacı çıplak olsa bile, bir ana çalışma ağacının KAFASININ başvurduğu ikincil bir çalışma ağacından bir dalın silinememesi.

Bundan kaçınmak için, core.bareayar yaparken de kontrol edin is_bare.
Eğer core.bare=1güvenin ve aksi takdirde kullanın is_bare_repository().

gitDağıtım ile geliyor bir katkıda senaryo olarak adlandırılan git-new-workdir. Aşağıdaki gibi kullanabilirsiniz:

git-new-workdir project-dir new-workdir branch

Burada project-dir deponuzu içeren dizinin adıdır .git. Bu komut .gitdosyaları, paylaşılamayan dosyalar (geçerli dal gibi) haricinde, iki farklı dalda çalışmanıza olanak tanıyan, özgün dizine birçok sembol içeren başka bir dizin oluşturur .

Biraz kırılgan geliyor, ama bir seçenek.

Burada bulamadığım bir çözüm umarak bu soruya rastladım. Bu yüzden şimdi o did ne ihtiyaç bulmak, ben başkaları için buraya göndermeye karar verdi.

Uyarı: OP durumları gibi birden çok dalı aynı anda düzenlemeniz gerekiyorsa, bu muhtemelen iyi bir çözüm değildir . Birden fazla şubesi olan içindir teslim bunu aynı anda yok düzenlemek niyetinde. (Bir .git klasörü tarafından desteklenen birden çok çalışma dizini.)

Bu soruya ilk kez geldiğimden beri öğrendiğim birkaç şey vardı:

1. “ Çıplak bir depo ” nedir. Bu, .gitçalışan bir ağaçta bulunmadan , dizinin içeriğidir.

2. .gitKomut satırında kullandığınız repo konumunu ( direktifinizin konumu ) gitseçeneğiyle belirtebilirsiniz.--git-dir=

3. Çalışma kopyanızın konumunu ile belirtebilirsiniz. --work-tree=

4. "Ayna repo" ne demek.

Bu sonuncusu oldukça önemli bir ayrım. Aslında repo üzerinde çalışmak istemiyorum , sadece farklı dalların ve / veya etiketlerin eşzamanlı olarak kontrol edilmesini istiyorum. Aslında, şubelerin uzaktan kumandanın şubelerinden farklı olmadığını garanti etmeliyim . Yani bir ayna benim için mükemmel.

Bu yüzden kullanım durumum için, ihtiyacım olanı aldım:

git clone --mirror <remoteurl> <localgitdir> # Where localgitdir doesn't exist yet
mkdir firstcopy
mkdir secondcopy
git --git-dir=<localgitdir> --work-tree=firstcopy checkout -f branch1
git --git-dir=<localgitdir> --work-tree=secondcopy checkout -f branch2

Bununla ilgili büyük uyarı, iki kopya için ayrı bir KAFA olmamasıdır. Bu nedenle, yukarıdakilerden sonra, çalışma git --git-dir=<localgitdir> --work-tree=firstcopy status, branş2 ile branş1 arasındaki tüm farkları taahhüt edilmemiş değişiklikler olarak gösterecektir - çünkü HEAD branş2'yi işaret ediyor. (Bu yüzden bu -fseçeneği kullanıyorum checkout, çünkü aslında yerel olarak herhangi bir değişiklik yapmayı planlamıyorum. -fSeçeneği kullandığım sürece herhangi bir çalışma ağacı için herhangi bir etiketi veya dalı kontrol edebilirim .)

Birden fazla kasanın aynı bilgisayarda bir arada bulunmasına izin vermeme kullanımım için , bu mükemmel çalışıyor. Diğer cevaplarda kapsanan gibi bir komut dosyası olmadan birden çok iş ağaç için birden fazla KAFA için herhangi bir yolu olup olmadığını bilmiyorum, ama umarım bu zaten başka birine yardımcı olur.

Aklıma gelen tek çözüm iki dizini klonlamak ve bunları birbirlerinin uzak depoları olarak eklemek. Daha sonra, uzak depoya hiçbir şey itmeden değiştirilen birinden diğerine bir şeyler çekmeye devam edebilirsiniz.

Uzaktan kumandanın iki klonuna değil, iki çalışma dizinine sahip olmak istediğinizi varsayıyorum çünkü bazı dalları uzaktan kumandaya itmek istemiyorsunuz. Aksi takdirde, uzaktan kumandanızın iki klonu gayet iyi çalışır - sadece üçünü de senkronize tutmak için bazı itme ve çekme işlemleri yapmanız yeterlidir.