0

背景

到目前为止，我们一直在使用 Plastic SCM 进行版本控制。最近我们一直在研究 Git，我提出了一个基本计划 -可在 Google Docs 上找到

我的计划是不允许开发人员直接提交或 FTP 到服务器，而是将我们的工作推送到实时或证明中心，这反过来又会导致实时/证明工作区从各自的中心提取更改。

在我看来，这种方法的主要好处之一是我们可以及时了解用户上传的内容。例如，当用户通过我们的 CMS 上传图像时，下次开发人员将一些工作推送到集线器时，服务器将自动添加、提交并将其推送到集线器。因此，我们可以随时将实时存储库或证明存储库克隆到全新的服务器。

到目前为止，我们在将工作发送给客户端进行证明同时将新功能上传到实时服务器时遇到了问题 - 证明工作最终在实时站点上，所有的地狱都失败了。

问题

  1. 你看到这个计划有什么漏洞吗？
  2. Git 是否适合用于这种结构？
  3. 有没有我们可以使用的预先存在的计划？

提前致谢。

4

2 回答 2

2

看看 Heroku 和 AppHarbour 是如何工作的。你绝对是在正确的轨道上。

于 2011-09-27T16:32:49.570 回答
0

您应该考虑使用Gerrit - 代码审查引擎，它也恰好是完全兼容 git 的 git 服务器。Gerrit 是由 Google 用 Ja​​va 编写的，用于满足 Android 项目的需求。

您可以使用审核功能让内容“进入”审批队列，直到最终获得批准并成为官方（或再次被拒绝/审核）。同时，你可以为不同的人设置灵活的访问权限规则——比如有人可以直接push绕过code review（这样就变成了标准的git服务器），或者只能提交review，或者approves，或者只能投票或向下 - 你制定规则。如果您有多个 git 存储库，您还可以限制您不信任的用户或第三方对某些高度机密的存储库的访问。

它易于设置，并且使管理员和最终用户的生活更加轻松 - Gerrit Web 界面上自动提供 ssh 密钥管理。

于 2012-12-05T10:56:15.163 回答