分層項目的git

有不同的版本庫repoA，repoB和repoC每個尊重相同的目錄佈局的原則，將被合併到第三repoM的工作目錄（「主」項目）。

repoM有一個非典型的設置（--work-dir和--git-dir是sepparate）。 repo [A-C]被克隆爲裸露，並且它們被設置爲core.bare = false和core.worktree=<--work-dir-of-repoM>。

的要求：

我需要始終有一個概述了在repoM的工作目錄中的所有文件，這些文件可以從回購[A-C]朵朵的歷史。用這種方法，我會失去所有的信息。

備選：

我一直在想使用Git樹代替（git version 1.7.11.2，所以它已經內置），留下回購[AC]裸露，然後

git pull -s subtree ，或
git subtree ...

隨着子樹拉動戰略，我失去了合併衝突的歷史（git blame如此說）。

我以前從來沒有使用過子樹，但是從我的理解來說，無法將從repo [A-C]中的文件合併到repoM的工作目錄中，這些文件必須放入repo [A-C]的子目錄中。這絕對不是我所需要的。 爲什麼？因爲以下的原因...

問題陳述：

你有不同的Git倉庫每個包含不同的文件集，通常配置文件和一些shell腳本。您希望將所有這些存儲庫中的所有內容都放入$HOME（即<--work-dir-of-repoM>）目錄中。您應該始終能夠看到每個文件的來源，編輯，提交併將更改推送到每個文件的origin。你已經猜到了，它有點類似vundle，但推廣到任何程序的任何配置，而不僅僅是vim捆綁。如果發生衝突，應該能夠追蹤同一文件的哪兩位作者需要彼此聯繫並達成協議（如果需要的話）。

這是一個開源項目，我試圖讓一個原型的工作，所以任何幫助，高度讚賞。關於已經存在的以類似方式做到這一點的項目的想法也受到高度讚賞。

注意：「主目錄」並不一定是$HOME，我用它作爲可能解決的問題的一種可能的提示。

來源

2012-08-05 Flavius

爲什麼子樹的複雜性？爲什麼不以你想要的任何[集成管理器]工作流的方式來對待這個問題？ – Christopher 2012-08-06 03:52:36

@Christopher考慮到需求暴露，我剛剛列出了我嘗試過的東西。你的提案如何符合這些要求？ – Flavius 2012-08-06 14:11:21

我其實不太清楚我的理解你的要求，因此我的問題。這聽起來像是你有三個回購站，它們以較小的方式派生出一個有福的倉庫，它應該包含來自三者中每一個的所有變化。這是準確的還是有一些複雜的，我沒有看到（完全可能）？ – Christopher 2012-08-06 14:31:45

爲什麼不簡單地在您的「主項目」中使用Git Submodules？

來源

2012-08-06 12:57:01

我必須引用自己的這一點：*這些文件必須放入repo子目錄[A-C]。這絕對不是我所需要的。* – Flavius 2012-08-06 13:05:02

他們是否絕對需要_must_共享相同的根目錄？所有存儲庫是你控制的還是他們是_independent_ projects？ – 2012-08-06 13:17:28

是的，這是絕對的要求。這是必須做的事情。他們在某種程度上是獨立的，但他們不知道如何尊重特定的目錄佈局，因此可能會發生衝突。你是一個Linux用戶？如果你是，你會從**問題陳述**中理解它的含義。 – Flavius 2012-08-06 13:22:28

分層項目的git

回答

相關問題