小开发团队的Git分支战略 [英] Git branch strategy for small dev team

问题描述

我们有一个几乎每天都会更新和发布的网络应用程序。我们使用git作为我们的VCS，而我们目前的分支策略非常简单和破坏：我们有一个主分支，并且检查我们对它感觉良好的更改。这种方式很有效，但直到我们检查到一项重大更改。

有没有人对小型团队拥有最喜欢的git分支策略，符合以下要求要求：

1. 适用于2至3名开发人员的团队


2. 轻量级，进程


3. 允许开发人员轻松隔离错误修复和更大功能的工作


4. 允许我们保留一个稳定的分支（对于那些'哦，废话'当我们必须让我们的生产服务器正常工作时）

理想情况下，我希望看到您的分步过程一个开发新bug的开发人员您可能会从Scott Chacon在 Pro Git 。在这个工作流程中，您有两个始终存在的分支， master 和 develop 。

/ em>表示您的项目的最稳定版本，并且您只能从该分支部署到产品。

$ b

开发包含进度，并不一定准备好生产。

通过 develop 分支，您可以创建主题分支来处理各个功能和修补程序。一旦您的功能/修复准备就绪，您就可以将它合并到 develop 中，此时您可以测试它与同事合并的其他主题分支的交互方式。一旦开发 em>处于稳定状态，将其合并到 master 中。从 master 部署到生产应始终是安全的。

Scott将这些长期运行的分支描述为代码的孤岛，其中代码在一个不太稳定的分支中，最终会毕业到你的团队测试和普遍批准后认为更稳定的分支。

一步一步地，您在这个模型下的工作流可能会看起来像像这样：
$ b

1. 您需要修复一个bug。
   
2. 创建一个名为基于 develop 分支的myfix 。
   
3. 处理本主题分支中的错误，直至解决问题。


4. 合并 myfix 到开发。运行测试。


5. 当您在工作时，发现您的修复与另一个主题分支 hisfix 冲突，您的同事合并到开发修正。


6. 在 myfix 分支中进行更多更改以处理这些冲突。 / em>转换成开发并再次运行测试。 一切正常。合并开发到 master 。
   
7. 随时从 master 部署到产品，因为您知道它是稳定的。

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

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.

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

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)

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

解决方案

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

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

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

From the develop branch, 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 develop is in a stable state, merge it into master. It should always be safe to deploy to production from 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.

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

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

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

这篇关于小开发团队的Git分支战略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！