小型开发团队的 Git 分支策略

Git branch strategy for small dev team

提问by Bilal and Olga

We have a web app that we update and release almost daily. We use git as our VCS, and our current branching strategy is very simple and broken: we have a master branch and we check changes that we 'feel good about' into it. This works, but only until we check in a breaking change.

我们有一个几乎每天都会更新和发布的网络应用程序。我们使用 git 作为我们的 VCS，我们当前的分支策略非常简单和破碎：我们有一个主分支，我们检查我们“感觉良好”的更改。这有效，但仅在我们签入重大更改之前。

Does anyone have a favorite git branch strategy for small teamswhich meets the following requirements:

有没有人有最喜欢的满足以下要求的小型团队的git 分支策略：

1. Works well for teams of 2 to 3 developers
2. Lightweight, and not too much process
3. Allows devs to isolate work on bug fixes and larger features with ease
4. Allows us to keep a stable branch (for those 'oh crap' moments when we have to get our production servers working)

1. 适用于 2 到 3 个开发人员的团队
2. 轻量级，不需要太多过程
3. 允许开发人员轻松隔离错误修复和更大功能的工作
4. 允许我们保持一个稳定的分支（当我们必须让我们的生产服务器正常工作时）

Ideally, I'd love to see your step-by-step process for a dev working on a new bug

理想情况下，我很想看到你的开发人员处理新错误的分步过程

回答by Jimmy Cuadra

You might benefit from the workflow Scott Chacon describes in Pro Git. In this workflow, you have two branches that always exist, masterand develop.

您可能会受益于 Scott Chacon 在Pro Git 中描述的工作流程。在此工作流中，您有两个始终存在的分支，master和develop。

masterrepresents the most stable version of your project and you only ever deploy to production from this branch.

master代表您项目的最稳定版本，您只能从该分支部署到生产环境。

developcontains changes that are in progress and may not necessarily be ready for production.

develop包含正在进行的更改，可能不一定准备好用于生产。

From the developbranch, you create topic branches to work on individual features and fixes. Once your feature/fix is ready to go, you merge it into develop, at which point you can test how it interacts with other topic branches that your coworkers have merged in. Once developis in a stable state, merge it into master. It should always be safe to deploy to production from master.

从开发分支，您可以创建主题分支来处理单个功能和修复。一旦您的功能/修复准备就绪，您将其合并到develop中，此时您可以测试它如何与您的同事合并的其他主题分支交互。一旦develop处于稳定状态，将其合并到master 中。从master部署到生产应该总是安全的。

Scott describes these long-running branches as "silos" of code, where code in a less stable branch will eventually "graduate" to one considered more stable after testing and general approval by your team.

Scott 将这些长期运行的分支描述为代码的“孤岛”，在经过测试和团队的普遍批准后，不太稳定的分支中的代码最终会“升级”到被认为更稳定的分支。

Step by step, your workflow under this model might look like this:

一步一步，您在此模型下的工作流程可能如下所示：

1. You need to fix a bug.
2. Create a branch called myfixthat is based on the developbranch.
3. Work on the bug in this topic branch until it is fixed.
4. Merge myfixinto develop. Run tests.
5. You discover your fix conflicts with another topic branch hisfixthat your coworker merged into developwhile you were working on your fix.
6. Make more changes in the myfixbranch to deal with these conflicts.
7. Merge myfixinto developand run tests again.
8. Everything works fine. Merge developinto master.
9. Deploy to production from masterany time, because you know it's stable.

1. 你需要修复一个错误。
2. 创建一个基于开发分支的名为myfix的分支。
3. 处理此主题分支中的错误，直到修复为止。
4. 将myfix合并到develop 中。运行测试。
5. 您发现您的修复与另一个主题分支hisfix冲突，在您进行修复时，您的同事将其合并到了开发中。
6. 在myfix分支中进行更多更改以处理这些冲突。
7. 将myfix合并到开发中并再次运行测试。
8. 一切正常。合并发展成为主人。
9. 随时从master部署到生产，因为您知道它是稳定的。

For more details on this workflow, check out the Branching Workflowschapter in Pro Git.

有关此工作流的更多详细信息，请查看Pro Git 中的分支工作流章节。

回答by Clutch

After coming in as a novice trying to find a straight-forward strategy to teach to other devs who have never used source control. This is the one that fit http://nvie.com/posts/a-successful-git-branching-model/I tried using the standard GIT workflow thats in the man pages but it confused me slightly and my audience completely.

在作为新手尝试找到一种直接的策略来教授其他从未使用过源代码控制的开发人员之后。这是适合http://nvie.com/posts/a-successful-git-branching-model/我尝试使用手册页中的标准 GIT 工作流程，但它让我和我的观众完全困惑。

Over the past 6 months I have only had to fix conflicts twice. I have added steps to always test after a merge and to 'fetch and merge" or 'pull --rebase" a lot (once in the morning and in the afternoon) while developing features. We also used github.com as the central place to pull the latest code.

在过去的 6 个月里，我只需要解决两次冲突。我添加了一些步骤，以便在合并后始终进行测试，并在开发功能时“获取并合并”或“拉--rebase”很多（早上和下午一次）。我们还使用 github.com 作为拉取最新代码的中心位置。

回答by program247365

(Made my commentabove it's own answer, as I should have initially.)

（在上面发表我的评论是我自己的答案，因为我最初应该这样做。）

From Scott Chacon of Github:

来自 Github 的 Scott Chacon：

How We Do It So, what is GitHub Flow?

• Anything in the master branch is deployable
• To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
• Commit to that branch locally and regularly push your work to the same named branch on the server
• When you need feedback or help, or you think the branch is ready for merging, open a pull request
• After someone else has reviewed and signed off on the feature, you can merge it into master
• Once it is merged and pushed to ‘master', you can and should deploy immediately

我们怎么做 那么，什么是 GitHub Flow？

• master 分支中的任何东西都是可部署的
• 要处理新事物，请从 master 创建一个描述性命名的分支（即：new-oauth2-scopes）
• 在本地提交到该分支并定期将您的工作推送到服务器上的同名分支
• 当您需要反馈或帮助，或者您认为分支已准备好合并时，请打开 拉取请求
• 在其他人并签署该功能后，您可以将其合并到 master
• 一旦合并并推送到“master”，您就可以并且应该立即部署

See the entire article for more details: http://scottchacon.com/2011/08/31/github-flow.html

详情请参阅整篇文章：http: //scottchacon.com/2011/08/31/github-flow.html

Note that "pull requests" are a Github invention, and it's something that's baked into their website, not Git itself: https://help.github.com/articles/using-pull-requests/

请注意，“拉取请求”是 Github 的一项发明，它已嵌入到他们的网站中，而不是 Git 本身：https: //help.github.com/articles/using-pull-requests/

回答by Leif Gruenwoldt

Use the masterbranch as your development branch and create release branches for performing bug fixes.

使用master分支作为您的开发分支并创建发布分支以执行错误修复。

Any new features will go on masterduring the development window (either committed directly or as topic branches with pull-requests, up to you -- not shown in graphic). Once all your planned features are implemented, enter feature freeze, and perform testing. When you're happy, tag the release on masteras v1.0.

任何新功能都将master在开发窗口期间继续进行（直接提交或作为带有拉取请求的主题分支，由您决定——未在图形中显示）。实现所有计划的功能后，进入功能冻结并执行测试。当您高兴时，将发布标记master为v1.0。

Over time your users will find bugs in v1.0so you'll want to create a branch from that tag (e.g. name it after the release 1.0) and fix those bugs in the branch. When you've got enough bugs fixed that you think it warrants a new release then tag it as v1.0.1and merge it back into master.

随着时间的推移，您的用户会发现错误，v1.0因此您需要从该标签创建一个分支（例如，以 release 命名1.0）并修复分支中的这些错误。当你修复了足够多的错误，你认为它值得发布一个新版本时，然后v1.0.1将其标记为并将其合并回master.

Meanwhile a new development window can be happening on the masterbranch which will eventually be tagged as v1.1.

同时，master分支上可能会出现一个新的开发窗口，最终将被标记为v1.1.

Rinse & repeat.

冲洗并重复。

This follows Semantic Versioningnumbering logic.

这遵循语义版本编号逻辑。

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

回答by VonC

In a VCS, having just a "master" branch shows quickly its limits because you cannot pursue all the development effort at the same time on one branch.
That means you need to know when to branch.

在 VCS 中，只有一个“主”分支很快就会显示出它的局限性，因为您不能在一个分支上同时进行所有的开发工作。
这意味着您需要知道何时进行分支。

But in a DVCS (as in "Decentralized" VCS), you also have a publication issue, with branches you keep local to your repositories, and branches you are pushing to or pulling from.

但是在 DVCS（如在“去中心化”VCS 中）中，您也有发布问题，您将分支保留在您的存储库的本地，以及您推送到或拉出的分支。

In this context, start by identifying your concurrent development effort, and decide on a publication (push/pull) process. For instance (and this is not the only way):

在这种情况下，首先确定您的并发开发工作，然后决定发布（推/拉）过程。例如（这不是唯一的方法）：

• prod is a read-only public branch with the code in production. Everyone could pull from it in order to:
  • rebase its current development on top of it (for local testing, or for integrating on the local dev repo a hotfix done in the prod repo on the prod branch)
  • branch to do new features (from a known stable code)
  • branch to start the next release branch (the one which is to be in production)
    no one should push directly to prod (hence the read-only)
• release is a read-write consolidation branch, where the relevant commits are cherry-picked to be part of the next release.
  Everyone can push to release to update the next release.
  Everyone can pull from said release in order to update his/her local consolidation process.
• featureX is a private read-write branch (in that it does not need to be push to the central prod repo), and can be pushed/pulled between dev repos. It represents middle to long term effort, different from the daily dev
• master represents the current dev, and is pushed/pulled between the dev repos.

• prod 是一个只读的公共分支，代码在生产中。每个人都可以从中拉出来，以便：
  • 在它的基础上重新构建当前的开发（用于本地测试，或者为了在本地开发仓库上集成在 prod 分支上的 prod 仓库中完成的修补程序）
  • 分支以执行新功能（来自已知的稳定代码）
  • 启动下一个发布分支（即将投入生产的分支）
    没有人应该直接推送到生产（因此是只读的）
• release 是一个读写合并分支，其中相关的提交被挑选出来作为下一个版本的一部分。
  每个人都可以推送到发布以更新下一个版本。
  每个人都可以从所述版本中提取，以更新他/她的本地整合过程。
• featureX 是一个私有的读写分支（因为它不需要推送到中央生产仓库），并且可以在开发仓库之间推送/拉取。它代表了中长期的努力，不同于日常开发
• master 代表当前的开发者，并在开发者仓库之间被推/拉。

Other release management processes exist, as this SO question attests.

存在其他发布管理流程，正如这个SO 问题所证明的那样。

回答by whaley

Read through ReinH's Git Workflow for Agile teams here: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

在这里阅读 ReinH 的敏捷团队 Git 工作流程：http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

This works very well for small teams. The goal here is to make sure everything that might be potentially unstable goes in to a branch of some kind. Only merge back to master when you are ready for everyone working outside of the feature branch to use it.

这对于小型团队非常有效。这里的目标是确保所有可能不稳定的东西都进入某种分支。仅当您准备好让在功能分支之外工作的每个人都可以使用它时才合并回 master。

Note: this strategy is hardly git specific, but git makes implementing this strategy pretty easy.

注意：这个策略几乎不是 git 特定的，但是 git 使这个策略的实现变得非常容易。