git workflow

Git与SVN的比较

原理上

• Git直接记录文件快照，SVN每次提交记录哪些文件更新更新了哪些行
• Git有本地仓库，SVN没有本地仓库
• Git大多数是本地操作，SVN大多数操作需要联网

操作上

• Git先提交到本地仓库然后推送到远程仓库，SVN直接推送到远程仓库
• Git有各种”反悔”指令，SVN没有
• Git有真正的branch，而SVN只是工作空间的副本

Gitflow工作流

Gitflow为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。

历史分支

develop和master是两个常驻分支，master分支记录了正式发布的历史，而develop分支作为功能的集成分支。因此，master分支的每次提交都应分配一个版本号。

功能分支

新的功能分支应该从develop分支迁出一个feature分支，新功能开发完成之后再合并回develop分支，常用命令：

1. 开发功能a

git checkout -b feature-a develop

1. 开发完成后合并回develop分支

git checkout develop
git merge --no-ff feature-a
git push
git branch -d feature-a

广州vi设计公司http://www.maiqicn.com 办公资源网站大全 https://www.wode007.com

发布分支

1. 当开发完成时，直接从develop分支checkout出release分支

 git checkout -b release-0.1 develop

1. release分支用于发布，发布完成后将release分支合并到master分支并且打标签，方便后续跟踪每次发布。

git checkout master
git merge --no-ff release-0.1
git push

git tag -a 0.1 -m "release 0.1 publish" master
git push --tags

维护分支/热修复

1. 从master分支拉出一个hotfix分支维护分支用于bug修复、快速给发布版本打补丁

git checkout -b hotfix master

1. bug修复完成立即合回master分支和develop分支，完成维护后删除hotfix分支

git checkout master
git merge --no-ff hotfix
git push

git checkout develop
git merge --no-ff hotfix
git push 

git branch -d hotfix

1. master上打新tag

git tag -a 0.2 -m "release 0.2 publish" master
git push --tags

优点

• 单个功能独立开发，并行开发互不干扰
• master和develop分支分别记录发布和功能开发的历史
• 由于有发布分支，其他暂不发布的功能的开发不受发布的影响，可以继续提交
• 维护分支能快速打补丁，不影响正在开发的功能

缺点

• 复杂，分支繁多
• Git GUI不支持，纯命令行
• 对开发者要求高（理解工作流，熟悉Git命令）
• 所有功能分支基于不稳定的develop
• 需要维护两个长期分支master和develop

GitHub Flow

• 所有在master上的东西都是可发布的（已发布或马上发布）
• 开发新功能时，从master拉一个名称清晰的新分支
• 在本地提交到这个分支的同时把它push到远程仓库
• 当你需要得到反馈或帮助，或者该分支准备merge时，打开一个pull request
• 该分支被review且同意合并后，合并到master
• push到master后，应该立即发布

优点

• 操作简单
• 主干的代码有质量保证

缺点

• 测试线和正式环境的发布没有区分

Git-Develop

Git-Develop模式将develop分支作为固定的持续集成和发布分支

• 每一个功能都从master拉一个功能分支。
• 在这个功能分支上开发，功能完成到发布时，提交code review，通过后自动合并到develop。
• 待所有计划发布的变更分支代码都合并到develop后，rebase master到develop，完成发布。
• 应用发布成功后打一个tag。
• develop分支的发布版本合并回master。

优点

• 操作相对简单
• 流程稍作改动，即可区分测试线和正式环境
• 每次开发都基于正式版本最新的代码（master)，和当前开发的其他分支不产生依赖关系
• master始终是已发布状态

Pull Requests

Pull requests不是一种工作流，而是一个能让开发者更方便地进行协作的功能，可以在提议的修改合并到正式项目之前对修改进行讨论。

• 开发者在本地仓库新建一个功能分支。
• 功能完成后，开发者push分支修改到远程仓库中。
• 开发者发起Pull requests。
• 团队成员收到通知，进行code review，讨论和修改。
• 项目维护者合并功能到仓库中并关闭Pull Requests。