首页 文章

小开发团队的Git分支战略[关闭]

提问于
浏览 次
177

我们有一个网络应用程序，我们几乎每天更新和发布 . 我们使用git作为我们的VCS，我们当前的分支策略非常简单和破坏：我们有一个主分支，我们检查我们感觉良好的变化 . 这是有效的，但直到我们检查一个突破性的变化 .

有没有人对 small teams 最喜欢的git分支策略满足以下要求：

  • 适用于2到3名开发人员的团队

  • 轻量级，而不是太多的过程

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

  • 允许我们保持一个稳定的分支（对于那些我们必须使我们的 生产环境 服务器工作的时刻'oh crap'）

理想情况下，我很乐意看到一个开发人员处理新bug的分步过程

git branch git-branch

6 回答

  • 35

    您可能会受益于Scott Chacon在Pro Git中描述的工作流程 . 在此工作流程中，您有两个始终存在，主控和开发的分支 .

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

    开发包含正在进行的变更，可能未必为 生产环境 做好准备 .

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

    Scott将这些长期运行的分支机构描述为代码的“孤岛”，其中一个不太稳定的分支中的代码最终将“毕业”为经过测试和团队一般批准后更稳定的代码 .

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

    • 你需要修复一个bug .

    • 创建一个名为myfix的分支，该分支基于develop分支 .

    • 处理此主题分支中的错误，直到修复为止 .

    • 将myfix合并到develop中 . 运行测试 .

    • 您发现修复与另一个主题分支hefix发生冲突时，您的同事合并后会在您修复时进行开发 .

    • 在myfix分支中进行更多更改以处理这些冲突 .

    • 将myfix合并到开发和运行测试中 .

    • 一切正常 . 合并发展为大师 .

    • 随时从master转发到 生产环境 ，因为你知道它是稳定的 .

    有关此工作流程的更多详细信息，请查看Pro Git中的Branching Workflows章节 .

    回复于
  • 4

    作为一名新手进入后试图找到一个直接的策略，教给其他从未使用过源代码控制的开发人员 . 这是适合http://nvie.com/posts/a-successful-git-branching-model/我尝试使用手册页中的标准GIT工作流程，但它让我和我的 Spectator 完全混淆了 .

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

    回复于
  • 234

    （让我的comment高于它自己的答案，就像我最初应该的那样 . ）

    来自Github的Scott Chacon：

    我们如何做到这一点，什么是GitHub Flow？主分支中的任何内容都是可部署的 . 要处理新事物，请从master创建一个描述性命名的分支（即：new-oauth2-scopes）在本地提交该分支并定期将您的工作推送到服务器上的同一命名分支当您需要反馈或帮助，或者您认为分支已准备好进行合并，打开拉取请求在其他人审核并签署该功能后，您可以将其合并为主要一旦合并并推送到“主”，您就可以并应立即部署

    有关详细信息，请参阅整篇文章：http://scottchacon.com/2011/08/31/github-flow.html

    请注意"pull requests"是Github的发明，并且's something that'被写入他们的网站，而不是Git本身：https://help.github.com/articles/using-pull-requests/

    回复于
  • 45

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

    任何新功能都将在开发窗口期间进行 master （直接提交或作为带有pull-requests的主题分支，由您决定 - 未在图中显示） . 完成所有计划的功能后，输入功能冻结并执行测试 . 如果您满意，请将 master 上的版本标记为 v1.0 .

    随着时间的推移，您的用户将发现错误在 v1.0 中，因此您需要从该标记创建分支（例如，在发布 1.0 之后将其命名）并修复分支中的这些错误 . 如果你已经修复了足够的bug，你认为它需要一个新版本，那么将其标记为 v1.0.1 并将其合并回 master .

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

    冲洗并重复 .

    这遵循Semantic Versioning编号逻辑 .

    ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1
    回复于
  • 3

    在VCS中，只有一个"master"分支快速显示其限制，因为您无法在一个分支上同时进行所有开发工作 .
    这意味着你需要知道 when to branch .

    但是在DVCS中（如在"Decentralized" VCS中），您还有一个 publication issue ，其中包含您保存在本地存储库中的分支，以及您要推送或从中拉出的分支 .

    在此上下文中，首先确定您的并发开发工作，并决定发布（推/拉）过程 . 例如（这不是唯一的方法）：

    • prod是一个只读的公共分支，其代码正在 生产环境 中 . 每个人都可以从中拉出来以便：

    • 在它之上重新定义它当前的开发（用于本地测试，或者在本地dev repo上集成prod分支上的prod repo中完成的修补程序）

    • 分支执行新功能（来自已知的稳定代码）

    • 分支启动下一个发布分支（即将 生产环境 的分支）
      没有人应该直接推动产品（因此是只读的）

    • release是一个读写合并分支，其中相关提交被选为下一个版本的一部分 .
      每个人都可以推出发布以更新下一个版本 .
      每个人都可以从上述版本中提取，以便更新他/她的本地整合过程 .

    • featureX是一个私有读写分支（因为它不需要推送到中央prod repo），并且可以在dev repos之间推/拉 . 它代表中长期努力，不同于每日开发

    • master表示当前dev，并在dev repos之间推/拉 .

    存在其他发布管理过程，如SO question attests .

    回复于
  • 15

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

    这对小型团队非常有效 . 这里的目标是确保可能存在潜在不稳定性的一切都进入某种分支 . 当您准备好在功能分支之外工作的每个人使用它时，才会合并回主服务器 .

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

    回复于

相关问题