小型团队的Git发展战略

Question

我们有一个小型的数字团队(3名设计师，3名开发人员)，并正在寻求将Git集成到我们的系统中。

目前，我们的大多数站点都有一个分期站点(dev.example.com)和一个生产站点(example.com)。我们的开发人员通常对本地版本进行代码更改，将这些更改移动到暂存站点，然后，一旦批准，这些更改将被实时移动。我们的设计师，另一方面，做小编辑(当开发人员太忙)直接到分期网站，然后推动现场直播一旦批准。另外，在某些情况下，我们没有一个分期站点，编辑被直接推送到生产站点。

我知道不同的工作流并不理想，但是对于我们来说，将Git集成到当前系统并保持工作流相当简单(为了设计者的缘故)的最佳方式是什么呢？我们当前的工作流程是在整合Git之前首先标准化的(也就是说，阶段站点是强制性的，设计师必须在本地开发才能推进阶段)，还是Git足够灵活地按原样工作？

我对Git相当陌生，但我读过这样的文章:应该只对一个裸存储库进行推送。这有必要吗？如果是的话，这会不会是集结地呢？或者应该是它自己的实体(例如，在内部服务器上，如example.local)？

一个好的工作流程是否是这样的：

1. 用户获取裸存储库并将其合并到本地存储库中。
2. 用户在本地开发并提交对本地存储库的更改。
3. 用户将更改推送到example.local上的裸存储库(或类似的内容)
4. 用户从裸存储库提取更改到暂存存储库dev.example.com。
5. 批准后，用户将从裸存储库提取到生产存储库example.com。

我对这个工作流唯一的问题是，裸露的存储库看起来像是unnecessary...no？最后，我理解将记录在本地存储库上的内容(用户更改、提交等)。但我不清楚裸存储库(推送后)、分段(拉后)和生产(拉后)会记录什么；是否可以很容易地跟踪和记录上述所有步骤？

谢谢你所有的建议/答案！

Answer 1

下面是一个干预git工作流：http://nvie.com/posts/a-successful-git-branching-model/

如果您的开发人员和设计人员不熟悉命令行中间阶段，可以使用GUI包装器，有几种：gitx、gitbox、git tower，只需用谷歌搜索它们的站点。找到一个或多个工具，你的团队是舒适的。

最好的工作流是满足您的团队需求的工作流，它可能会随着时间的推移而改变。

Answer 2

Git是否足够灵活，可以按原样工作吗？

完全是这样的。

按照我以前的做法，让设计人员在design分支上工作，或者使用类似的名称，并且总是有一个命令来推送。

每当开发人员更新服务器时，他都会合并来自设计分支的内容。实际上，在自动部署脚本中，合并将是一个命令。

要只进行设计更改而不是开发更改，您可以始终将阶段中的分支切换到设计分支。为此，您可以向设计器提供推动最新更改的部署脚本，然后切换到设计分支。

也就是说，鼓励设计师慢慢地、逐步地使用git。首先将它们挂到stash命令中。然后拉。然后，让他们创建不同的分支。

至于裸存储库，这是保持所有人员同步的一种标准方法，而且没有任何技术上的理由真正拥有这一额外的存储库。除了大多数人使用github或具有良好的web UI的对等远程备份服务来进行通信和协调之外，它实际上成为了中心的裸存储库。

Answer 3

我也看不出使用裸存储库的理由。我写了一篇关于一个简单的开发过程的短文：使用Git的简单开发过程

这不是你的情况，而是一个更普遍的解决方案。使用特性分支的想法是允许人们将自己的更改推送到主回购中，而不影响每个人的工作，并使合并其他人的更改变得更容易。

如果我这么做，我就会这么做：

1. 安装盖特立功。没有必要，但能帮助你了解事情的发展，
2. 创建您的生产存储库中的Gitorious。
3. 在生产存储库中添加一个后置钩子，当接收到更新时，它会自动更新生产服务器(可能会推迟到第二天晚上，任何最适合您的东西)。
4. 在Gitorious中创建一个开发存储库。
5. 在更新开发服务器的开发存储库中添加类似的后置钩子。

这种设置有许多优点：

• 开发者不需要担心网站的更新。他们所需要做的就是推动开发回购。
• 测试通过后更新生产服务器是非常简单的，仅仅是推送就足够了(除了开发服务器之外，任何地方都不会更新生产存储库)。您甚至可以在后置钩子中添加一个节，如果按下标记，就可以这样做。因此，您可以使用标签使用版本号标记可发布版本，这将自动更新生产服务器。
• 很少有人会把事情搞砸(“哎呀！我是想推到dev，而不是推到prod上。”)