2012-04-27 5 views
1

下面是這種情況:是否有可能跟隨文件的歷史記錄在另一個倉庫

我們有一個包含一些文件夾的「官方」版本庫。此文件夾被用戶A擁有,用戶A應該被允許推動它只有一個:

repoA 
| 
-- folderA1 
    | 
    |- fileA11 .. fileA12 
| 
-- folderA2 
    | 
    |.... 

用戶B需要維護自己的folderA1的複印件(repoA),應該能夠將用戶A推送的提交合併到自己的副本中。用戶B並不想folderA2

當然,用戶B會犯一些修改自己的folderA1副本和folderA1(從用戶B的角度看)的歷史應該看起來像:

HEAD 
| 
* Merge user A master into user B master 
| \ 
* | Last commit made by user A 
* | Previous commit made by user A 
| * Last commit made by user B 
| * Previous commit made by user B 
|/ 
* Initial commits made by user A 
* 
* 
| 

用戶B不應在他自己的存儲庫中擁有folderA2(來自用戶A)。

用戶B應該能夠有folderB1和folderB2在他自己的倉庫。

感謝

+0

我想這應該http://help.github.com/subtree-merge/幫助 – 2012-04-27 08:48:03

回答

0

考慮您可以控制在一個倉庫級別的寫權限(通過,例如,Gitolite),這將是最好的,如果folderA1是:

  • 自身的
  • 一個Git回購
  • repoA中引用爲submodule

控制誰更新的內容將與subtree merging更加複雜。

+0

訪問控制是沒有問題的,我們有gitlab和推訪問受到限制。我們現在正在嘗試子樹合併解決方案 – 2012-05-03 09:07:26

+1

@GhislainLeveque推送訪問受限於每個存儲庫。而一個子樹合併將導致只有一個回購,這使所有用戶訪問該回購的兩個部分完全寫入訪問回購。我不認爲子樹合併在你的情況下是一個適當的解決方案。 – VonC 2012-05-03 09:35:33

+0

Thansk爲您的評論。目前,我們正在使用的子樹合併和它的作品很好,但我們沒有用戶之間的互動很多尚未所以我們無法知道它是一個很好的長期的,「易維護」的解決方案 – 2012-05-22 08:27:15

相關問題