Git workflow

git workflow

workfolw

Git作为一个分布式版本控制系统，不可避免涉及到多人协作，协作通常指的是分支工作流程。Git工作流是基于Git的分支能力而形成的代码拉取、合并、构建的开发工作流，Git工作流可以解为工作中团队成员需要遵守的代码交流机制和代码管理方案。

主流workflow

集中式工作流

集中式工作流类似于svn的协作方式，所有的开发者都工作在相同的分支上，这个分支一般是master分支。这个工作流的原理很简单：有一个远程仓库，每个开发人员都clone这个仓库，在本地代码上工作，更改、提交，并将其推送到远程仓库，供其他开发人员使用。

1. 开发者clone中央仓库到本地。
2. 在本地仓库的master分支上编辑文件和提交修改(git add 、git commit)
3. 开发完毕后push到远程仓库，此过程中还有可能需要pull远程分支，解决冲突等

好处

• 只有master一个分支，不用切换分支，合并分支
• 所有开发者都都工作在master分支上，可以尽快共享其他人的成果
• 线性的提交历史，更清晰、简洁、易读

缺点

• 只有一个master分支不能发挥git强大的分支管理优势
• master分支不稳定，不利于生产发布
• 所有开发者都工作在master分支上，代码冲突的几率更大
• 不利于单个开发者多任务并行开发，也不利于多成员间协作开发

功能开发工作流

功能分支工作流以集中式工作流为基础，这种工作流关注功能开发,不同的是为各个新功能分配一个专门的分支来开发。这样可以在把新功能集成到正式项目前，用Pull Requests的方式讨论变更。这种工作流可以为每个功能做隔离，避免对中心仓库主干代码造成影响。

1. 开发者clone中央仓库到本地。
2. 在本地仓库的master分支创建出功能分支，并切换到该功能分支上进行开发、提交
3. 开发完毕后将功能分支推送到远程仓库，并发起Pull Requests
4. 代码经过review后合并到master上

好处

• 在不同的分支上开发不同的需求，利于并行开发多个需求
• 不直接合并到master分支，利于维护master的稳定性
• Pull Requests为团队成员间进行代码交流提供了可能
• 它对连续交付和持续集成非常友好

缺点

• master分支是唯一一个可以用来生产部署的分支，不适用于需要发布多个版本的场景
• master分支具有保持最新版本代码和上线部署的双重角色，所有合并到master的功能都将发布，包含暂时不需要发布的功能
• 测试线和正式环境的发布没有区分
• 对代码审查有较高要求

Gitflow工作流

Git Flow是此列表中最知名的工作流程。它由Vincent Driessen于2010年创建，它基于两个主要分支master和develop，具有无限的生命周期：

• master分支：可以被视为稳定的分支，一般不允许直接往master分支提交代码，只允许往这个分支发起merge request，只允许release分支和hotfix分支进行合并。master分支所有功能都经过了充分的测试，并且可以随时准备上线发布。

• develop分支：是相对稳定的分支，用于日常开发，包括代码优化、功能性开发。

在开发周期中，使用了各种支持分支：

• feature-* ：从develop分支拉取，功能开发会在其上进行，开发完毕合后并到develop分支。

• release-* ：从develop分支拉取，用于回归测试，完成后打tag并合入master和develop。

• hotfix-*：用于紧急修复上线版本的问题，修复后打tag并合入master和develop。

好处

• 在项目的生命周期中的任何给定时刻确保分支的清洁状态
• 分支命名遵循系统模式，使其更容易理解
• 它对大多数使用的git工具都有扩展和支持
• 当需要在生产中需要多个版本时，它是理想的

缺点

• Git的历史变得难以理解
• 需要长期维护master和develop分支，而两个分支大多数情况下是一致的
• 当需要在生产中维护单个版本时，不建议使用它

Forking工作流

这套流程是专门为开源软件量身打造的一套流程，最早的发明者是 Github，Github 是世界知名开源软件仓库。这个流程的最大特点就是，开发参与者可以不直接参与到项目中来，想贡献代码，只要 fork 目标项目后，就可以得到一个一模一样的自有项目，做完修改后，提交 Pull Request 给原项目，如原项目的维护者采纳了，即算贡献完成。

1. fork目标仓库到自己的远程仓库
2. clone自己远程仓库到本地
3. 在本地仓库的主分支上编辑文件和提交修改(git add 、git commit)
4. push最新代码到自己的远程仓库
5. 向原项目发起pull request
6. 原项目维护者review修改，拒绝或合入修改

好处

• 适用于开源项目
• 开发者有需要衍生出自己的衍生版的

缺点

• 不适用于私有项目
• 原项目与fork项目间同步需要额外操作
• 每个成员都fork原项目，占用了更多资源

最佳实践

git工作流的最佳实践是怎样的，或许没有一个标准的答案，能最大程度提高团队工作效率的工作流就是git workflow的最佳实践。一个团队决定采用哪个工作流取决于下面几个因素：

• 项目本身的特性，是开源的还是私有的，大型项目还是小型项目
• 项目的迭代周期和需求分解的粒度，上线发布的频率
• 开发团队的规模和偏好
• 团队开发人员对git和工作流的理解程度
• 项目开发管理的模式，是传统的管理模式还是敏捷的模式

小结

本文调研了四种主流的git workflow：集中式工作流、功能开发工作流、gitflow工作流、forkflow，分析了各自的开发协作流程和优缺点，并就这些工作流在实际开发中的应用做了简单的探讨。

参考

• Git Workflows That Work
• Comparing Workflows
• A successful Git branching model
• Understanding the Git Workflow
• Git Workflows for Pros: A Good Git Guide
• Git三大特色之WorkFlow
• Git workflow 选型分析
• Git 工作流程
• GitFlow被认为是有害的