git工作流程(阮一峰完整总结版本各流程变化且有独到见解).docxVIP

Git 工作流程 （阮一峰完整总结版本，各流程变化，且有独到 见解） Git 作为一个源码管理系统， 不可避免涉及到多人协作。 协作必须有一个规范的工作流程，让大家有效地合作，使得 项目井井有条地发展下去。 工作流程 在英语里，叫做 workflow或者flow，原意是水流，比喻项目象水流那样， 顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。 本文介绍三种广泛使用的工作流程： Git flow Github flow Gitlab flow 如果你对 Git 还不是很熟悉，可以先阅读下面的文章。 Git 使用规范流程》 常用 Git 命令清单》 Git 远程操作详解》 、功能驱动 本文的三种工作流程， 有一个共同点： 都采用 功能驱动式开 发 （ Feature-driven development ，简称 FDD ）。 它指的是，需求是开发的起点，先有需求再有功能分支 feature branch )或者补丁分支( hotfix branch )。完成开 发后，该分支就合并到主分支，然后被删除。 二、 Git flow 最早诞生、并得到广泛采用的一种工作流程， 就是 Git flow 。 特点 它最主要的特点有两个。 首先，项目存在两个长期分支。 主分支 master 开发分支 develop 前者用于存放对外发布的版本，任何时候在这个分支拿到的， 都是稳定的分布版； 后者用于日常开发， 存放最新的开发版。 其次，项目存在三种短期分支。 功能分支( feature branch ) 补丁分支( hotfix branch ) 预发分支( release branch ) 旦完成开发， 它们就会被合并进 develop 旦完成开发， 它们就会被合并进 develop 或 master ，然后 被删除。Git flow 的详细介绍，请阅读我翻译的中文版Git 分支管理策略》。评价 被删除。 Git flow 的详细介绍，请阅读我翻译的中文版 Git 分支管 理策略》。 评价 Git flow 的优点是清晰可控，缺点是相对复杂， 需要同时维 护两个长期分支。大多数工具都将 master 护两个长期分支。大多数工具都将 master 当作默认分支， 可是开发是在 develop 分支进行的， 这导致经常要切换分支， 非常烦人。 更大问题在于，这个模式是基于 版本发布 的，目标是一段 时间以后产出一个新版本。 但是，很多网站项目是 持续发布 ，弋码一有变动，就部署一次。这时，master分支和develop 分支的差别不大，没必要维护两个长期分支。 、 Github flow Github flow 是 Git flow 的简化版，专门配合 持续发布 。它 是 G 使用的工作流程。 流程 它只有一个长期分支，就是 master ，因此用起来非常简单。 官方推荐的流程如下。 第一步：根据需求，从 master 拉出新分支，不区分功能分 第一步 支或补丁分支。 第二步：新分支开发完成后，或者需要讨论的时候，就向 master 发起一个 pull request （简称 PR ）。 第三步： Pull Request 既是一个通知，让别人注意到你的请 求，又是一种对话机制，大家一起评审和讨论你的代码。对 话过程中，你还可以不断提交代码。 第四步：你的 Pull Request 被接受，合并进 master ，重新 部署后，原来你拉出来的那个分支就被删除。 （先部署再合 并也可。） 评价 Github flow 的最大优点就是简单，对于 持续发布 的产品， 可以说是最合适的流程。 问题在于它的假设： master 分支的更新与产品的发布是一致 的。也就是说， master 分支的最新代码，默认就是当前的线 上代码。 可是，有些时候并非如此，代码合并进入 master 分支，并 不代表它就能立刻发布。比如，苹果商店的 APP 提交审核 以后，等一段时间才能上架。 这时，如果还有新的代码提交， master 分支就会与刚发布的版本不一致。 另一个例子是， 有 些公司有发布窗口，只有指定时间才能发布，这也会导致线 上版本落后于 master 分支。 上面这种情况， 只有 master 一个主分支就不够用了。 通常， 你不得不在 master 分支以外，另外新建一个 production 分 支跟踪线上版本。 四、 Gitlab flow Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了 两者的优点，既有适应不同开发环境的弹性，又有单一主分 支的简单和便利。它是 G 推荐的做法。 上游优先 Gitlab flow 的最大原则叫做 上游优先 ( upsteam first )，即 只存在一个主分支 m