2012-04-27 32 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

相关问题