小团队的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

这个工作流程的唯一问题是裸机库似乎没必要......不是吗？最后，我了解将在本地存储库中记录的内容（用户更改，提交等），但我不清楚将在裸存储库（推送后），暂存（在拉动之后）上记录的内容）和生产（拉动后）;是否可以轻松跟踪和记录上述所有步骤？

感谢您提供任何建议/答案！

Answer 1

这是一个interestion git工作流程：http://nvie.com/posts/a-successful-git-branching-model/

如果你的开发人员和设计人员不熟悉命令行interphase，使用GUI git包装器，有几个：gitx，gitbox，git tower，只是google他们得到他们的网站。找到您的团队感到舒适的工具。

最佳工作流程是满足您团队需求的工作流程，并且可能会随着时间的推移而发生变化。

Answer 2

  

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

非常如此。

我以前的方式，让设计师在design分支或类似命名的东西上工作，并且总是只有一个命令可以推送。

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

要仅设置更改设计更改而不更改设备更改，您始终可以将分段中的分支切换到设计分支。为此，您可以为设计人员提供推送最新更改的部署脚本，切换到设计分支。

话虽如此，鼓励设计师慢慢地逐渐使用git。首先将它们挂钩到stash命令。拉。然后，让他们创建不同的分支。

至于裸存储库，这是让所有人保持同步的标准方法，并且没有技术理由真正拥有这一个。除了大多数人使用github或等效的远程备份服务，它具有良好的Web UI进行通信和协调，其中defacto成为中央裸存储库。

Answer 3

我也没有看到使用裸存储库的原因。我写了一篇关于简单开发人员流程的简短帖子： A simple developer process with Git

这不是你的情况，而是一个更通用的解决方案。使用功能分支的想法是允许人们将他们的更改推送到主回购，而不会弄乱每个人的工作，并且更容易合并其他人的更改。

如果我这样做，这就是我要做的事情：

1. 安装Gitorious。没必要但有助于跟踪事情，
2. 在Gitorious中创建您的生产存储库。
3. 向生产存储库添加一个后挂钩，当收到更新时，会自动更新生产服务器（可能会延迟到第二天晚上，最适合您的情况）。
4. 在Gitorious中创建开发存储库。
5. 将类似的post-hook添加到更新开发服务器的开发存储库中。

此设置有许多优点：

• 开发人员无需担心更新网站。他们所要做的只是推动开发回购。
• 在测试通过后更新生产服务器非常简单，仅仅推送就足够了（生产存储库永远不会从开发服务器以外的任何地方更新）。你甚至可以在post-hook中添加一个部分，如果按下一个标签就会这样做。因此，您可以使用标记标记版本号的可释放版本，这将自动更新生产服务器。
• 有人可以搞砸事情的点数要少得多（“哎呀！我的意思是推动开发，但反而推动。”）。