这对我来说是一件很新鲜的事情。我们已经允许我们的客户访问我们的源代码。使用bitbucket/Sourcetree时,我的意思是使用Fork授予他对给定状态/提交的读访问权限。我不想授予对actual (仍在开发代码中)的访问权限。我计划只分享里程碑。可以这样使用Forks吗?是否有其他选项来仅共享特定的提交?BR,丹尼尔
发布于 2017-04-06 00:53:48
对于我认为你想要做的事情,最简单的方法是:
在另一个名称下提交share;
这样,客户端将看到您的代码的快照。没有当前提交和历史记录。
发布于 2017-04-06 01:34:28
我不相信有一种方法可以在repo中提供提交或分支级别的访问控制。创建一个更有限的repo是一种合理的方法,但根据您的需求,我可能会建议使用Sergio Tulentsev建议的方式来复制快照。
这样做的潜在缺点是会丢失任何会在内部将共享快照连接回您的历史记录的数据。如果您将来可能提供新版本,或者如果您可能接受从fork返回到代码库的补丁,那么这种分离会带来额外的工作。
解决方案的一部分是简单地跟踪您的提交(具有历史记录)和它们的提交(提供快照)之间的关系;而这部分问题您可以通过某种类型的标记约定来解决。但除此之外,如果您认为您可能想要来回迁移更改,那么您可以进行设置以避免一些手动迁移工作。
因此,您可以尝试如下所示:
首先,在您的存储库中,确定您最初希望共享的提交,并为fork创建一个分支。如果您将提交标记为提交-共享,那么
git checkout commit-to-be-shared
git checkout -b fork_master(或者可能是客户的名字,而不是fork-master,如果您认为这是您可能会为其他人做的事情……)
下一步,不是手动复制到新的存储库,而是创建一个原始数据的“浅克隆”。请注意,您必须使用URL (而不是本地路径);因此,如果您通常将存储库寻址为/path/to/my/repo,请使用类似于file://path/to/my/repo的内容...细节取决于你的操作系统,但希望你能明白我的意思……
cd ..
git clone --depth=1 -b fork-master http://my.server/origin-repo这将只复制一次提交,并将fetch设置为仅检索fork-master分支。但是,它将保留提交的身份。因此,在您的源中,将来您可以将更多的更改合并到fork-master中,并轻松地共享结果提交。但如果/当您推送更多更改时,请参阅下面的说明,以避免无意的历史暴露。
接下来,在您的服务器上准备一个空的repo (与您的源一起),它将用作客户的源。然后将其设置为新创建的浅存储库中的第二个遥控器:
git remote add fork-origin http://my.server/fork-origin-repo
git push -u fork-origin master(同样,如果您认为稍后可能会有更多信息,您可以为遥控器使用特定于客户的名称...)
如果您愿意,您的任何开发人员也可以添加fork-master,这样您就可以无缝地从客户那里接收补丁。
不过,有一个技巧可以确保您在未来不会无意中暴露历史。当您将来合并到fork-master并将其交付给fork-origin时,默认情况下会带来新合并的提交的历史记录。显而易见的简单解决方法是,在您的浅存储库中:
git pull --depth=1这里的问题是git可能会变得混乱。(简单的解释是,新获取的merge意味着在第二个父级上有深度1,而不是在第一个父级上,而且git似乎没有像您希望的那样处理它。)不是很难解决:
git pull --depth=2不过,现在您将看到,合并带来了新合并工作中的一个额外的历史提交。该提交只包含您合并到fork-master中的更改,因此它可能是可以的;但是,该提交可能具有提交消息或标记,或者您不一定想要共享的其他内容。在这种情况下,您总是可以在合并之前创建一种“缓冲区提交”。
F1 -------- F2 <--(fork-master)
/ /
/ B
/ /
X ---- X --- A --- X <--(master)其中F1是原始的共享快照,A包含您决定共享的更多更改,B是本质上复制A的“客户安全”提交,而F2是新的合并。然后客户就会看到
F1 ---- F2
/
B在调用git commit创建B时,您可能必须使用--allow-empty选项。
注意:我还没有机会进行端到端的测试;如果您在任何步骤中遇到错误,请让我知道,这样我就可以进行相应的更新。
https://stackoverflow.com/questions/43237139
复制相似问题