什么样的Git工作流程适合我们的情况？

Question

我们目前只有master分支。我们当前的工作流程包括在本地实现这些功能，提交到存储库并更新测试服务器，让客户了解它，如果他批准了更改，我们也会更新产品。

现在我们使用SVN并手动更新我们已更改的特定文件夹和文件，否则我们可能会对生产进行不必要的更改。使用Git作为我们已经用于一个项目的近期回购，什么样的Git工作流/分支能够满足我们的需求？ Git工作流程需要适用于这种情况：

1. 在当地做你的工作。
2. 更新测试服务器，让客户知道。
3. 如果客户批准了更改，也请更新产品。

理想情况下，我们希望可以一​​次将生产更新为特定标记所有文件和文件夹。测试和生产可能与许多开发人员有几个不同的变化，其中一些需要转移到生产中。

最初，我考虑过3个分支master用于生产稳定版本，test用于测试服务器（要合并到dev）和dev我们编码。我不确定这是否合适。

Answer 1

在我看来，你不一定需要每个服务器的分支 - 这可以创建（取决于你的忽略和一些其他因素）一些问题，当级联变化上下。相反，您的各种服务器可以检出分支并将更改拉到它。具有存储库完整副本的服务器非常非常有用。

我们的生态系统最初包括每个服务器，生产，登台和开发的分支 - 在分支之间同步更改有时会创建非常令人沮丧的合并问题。我们目前已经检查了生产分支机构的所有服务器，并且我们为自己省去了一些令人头疼的问题。我们在实际pull生产服务器之前检查所有内容 - 如果需要，您还可以切换分支以测试更激烈的编码更改。那里有很多灵活性。

我的建议是评估您的工作流程，看看您是否可以利用钩子来自动更新测试/临时服务器的过程。我们用gitolite完美地做到这一点。否则，您的工作流程很容易实现，您可以对概念进行一些改进，以进一步实现自动化。

Answer 2

（每个提交用圆圈表示）。 （虚线：需要额外合并）

<强>序言

• 这件事写得很快，肯定有错误，但应该对这种方法有一个很好的概述。

<强>概述

我们的用例与您的用例非常相似，这是我们迄今为止发现的最优化的解决方案。

您将需要3个不同的分支：

1. master（这是你的主要分支，所有 - 有用的 - 开发人员写的代码最后来到这里）
2. 生产

3. 预发布 - ＆gt;这是一个临时分支。它是在您向客户端演示内容的时间与该内容到达生产服务器的时间之间。

   • 请注意，生产和预发布最终都是主分支的旧版本，即master不包括其中的一些最新更改。因此，任何直接发布到预发布的更改（基于客户端请求）都应合并到master。生产分支中的任何更改（关键错误修复）都应该合并到主分支以及预发布分支（如果它是活动的）。这是最重要的考虑因素，否则你最终会陷入混乱，就像在一个git存储库中拥有多个代码库一样。

对于日常任务：

开发人员Foo会：

git pull 
git checkout -b new_feature

然后编写她的代码并经常提交给new_feature分支。 一旦她完成了：

git pull << to get the latest changes on master (in the picture you see Foo's branch is 2 commits behind master's ~HEAD)
git rebase -i master << -i to be interactive, so she can pull out some of the local changes she's made e.g. local changes config files or customized loggers for her own benefit, etc.
git merge --no-ff master << merge the changes with master
git push << push to the repository

测试服务器：

一旦你对客户端的测试/演示足够好，你就可以创建一个临时分支：

git pull
git checkout master
git checkout -b pre-release

您可能需要为测试计算机配置一些自定义配置，以便您可以拥有一个分支（test_server_local_changes）并将其提供给用户。当你有新的预发布分支然后做：git pull和git rebase -i pre-release

在此阶段，如果客户要求更改，开发人员应该从预发布中分支出来，并在进行更改合并后，将其分支与主数据库和预发布版本合并。

生产服务器：

客户批准更改后：

git pull和git checkout production and git rebase pre-release

您可能想要为生产分支服务。或者，如果您有特定于生产服务器的自定义更改，最好为其创建一个单独的分支（production_local_changes），并进行一些额外的更改，并始终在生产分支上对其进行重新定义。

严重漏洞修复：

假设有人会在您的生产服务器中发现一个关键错误，那么Bob将从生产分支创建一个分支，修复错误，提交错误，然后将其分支与生产服务器合并，然后拉出并重新生成prodction_local_changes。但是，更改将不会出现在master中，因此他也需要与master合并，如果它处于活动状态并且rebase test_server_local_changes也需要预先发布。

备注

• 在我看来，在git中（与SVN不同，因为我记得那些使用它的丑陋日子）用户应该在必要时进行分支并尽可能经常地进行提交。

• 每个用户可以而且应该让他的本地分支拥有他自己的所有配置并合并它，或者当他们从3个主要分支中的任何一个分支时首先选择樱桃。他们总是可以重新定义-i并删除他们自己的本地更改，然后再将它们合并回这3个分支中的任何一个。对于生产和预发布分支也是如此，对于每个分支都应该有一个分支，用于所有配置。

• 我喜欢gitolite，我认为这是一个很好的工具，可以在git上使用来管理权限，拥有一种中央存储库，并且可以更轻松地使用git。

Answer 3

看起来，您不需要3个分支，但更像是至少2个存储库。每个开发人员至少拥有自己的本地存储库，并且每个人都可以访问，这是“dev分支”。然后有测试人员必须知道要测试哪些提交，测试团队负责维护具有工作提交的官方存储库。 （存储库总数=成员数+ 2）

拥有单个存储库和3个分支（master，test，dev）并不是一个好主意，因为您的产品最终会发展，您将获得新功能（使用分支），版本（分支和标签）以及不同的人将贡献源代码（更多分支）。