使用两个git存储库（内部和外部）向客户机交付代码的工作流

我有一种情况，客户机将在使用Git的版本控制下接收源代码。客户希望在回购协议中跟踪、区分和控制每周冲刺的进度。最终，客户人员也将对回购做出承诺

我的团队（我们称之为内部团队）也在使用Git和Git流工作流。因此，内部回购的每一次发行都应转化为客户回购的提交。我们不希望内部回购上的每个提交都显示在客户端回购上

因此，我目前的想法/解决方案是使用rsync脚本将工作目录从内部复制到客户端（在本地文件系统上），然后提交到客户端repo。这可以作为内部服务器上的post接收挂钩或类似的东西

这个解决方案对我来说似乎太笨拙了，也许有更好的方法来实现我所需要的。还有什么想法

---

编辑以包括接受的解决方案：

正如Scott Weldon在接受的响应中指出的那样，

git merge

允许在良好的工作流中实现这一点。但是，要使其工作，还需要其他标志。一个是允许git有效地合并这两个故事，另一个是给出解决冲突的适当策略

因此，假设我从内部回购合并的参考是

发行版/x.x.x.

，流程是

git fetch internal
git merge --allow-unrelated-histories -s recursive -Xtheirs --squash internal/release/x.x.x
git commit
git push origin master

---

一种方法是使用Git的能力来添加和合并不相交的历史

将内部存储库作为远程存储库添加到外部存储库：

git remote add internal ssh://user@host/path.git

无论何时在内部回购中进行发行，都应在外部回购中执行以下操作：

git fetch internal
git merge --squash internal/master
git commit
git push origin master

这将在外部回购中创建一个提交，其中包含自上次合并以来

internal/master

的任何更改

从

git merge

的手册页：

--squash

生成工作树和索引状态，就像发生了真正的合并一样（合并信息除外），但实际上不进行提交，移动

头

，或记录

$GIT\u DIR/merge\u头

（以使下一个

GIT commit

命令创建合并提交）。这允许您在当前分支上创建一个提交，其效果与合并另一个分支相同（如果是八达通，则为多个分支）

因此，如果没有

--squash

标志，来自

内部

的历史记录将包括在外部回购中

---

如果您使用的是Git>=2.9的版本，那么还需要将

--allow unrelated histories

标志添加到

Git merge

命令中，因为默认情况下Git将拒绝合并不相关的历史。请参阅。

谢谢@Scott Weldon。我曾在一次回购中使用挤压，但从未在两次回购之间使用挤压。这是一个很好的方法。您对在服务器上将其设置为post-commit钩子有何想法？本质上，我希望尽量减少内部团队的开发人员意外地（通过中间历史）向客户机发送未经修改的代码的可能性，这应该是可行的。如果您的服务器使用裸repos，您将不得不在服务器上的其他地方进行完全签出，但只要您具有shell访问权限，这应该不会有问题。您的

post receive

内部回购挂钩可以在需要时更新外部回购并合并。