GitFlow 协同工作流

其实GitFlow并非什么技术，而是一种代码开发合并管理流程的思维模式或者是管理方法。大家一起开发的一种软约定。

GitFlow中分支角色们

gitflow.png

Master 分支： 稳定版本代码分支，用作发布环境，上面的每次提交都是可以发布的，这个分支只能从其他分支合并，不能在这个分支直接修改。

Developer 分支: 主开发分支，包含所有要发布到下一个Release的代码， 一旦Feture分支内功能开发完成就将Feture中的代码合并到Developer分支中，合并完成后，删除该功能分支。这个分支对应的是集成测试环境。

Feature 分支： 功能分支，用于开发新功能（需求），一旦开发完成，我们合并回Develop分支进入下一个Release。

Release 分支：预发分支，做发布前的准备工作，对应的是预发环境。这个分支可以确保我们开发继续向前，不会因为要发布而被停滞住，当你需要发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后。一旦Release分支达到了可发布的状态，我们需要把Release分支同时向Master，Developer分支上合并，保持代码的一致性，然后把Release分支删除。

Hotfix 分支： 线上bug修缮用的分支，每次修改线上代码的bug时都要用hotfix来维护，完成后向Developer和Master同时合并。所以Hotfix的改动会进入下一个Release，完成后删除分支。

Git Flow 命令示例

创建 Devlop

1
2
git branch develop  
git push -u origin develop

开始 Feature

1
2
3
4
5
6
7
8
9
# 通过develop新建feaeure分支
git checkout -b feature develop
# 或者, 推送至远程服务器:
git push -u origin feature    

# 修改md文件   
git status
git add .
git commit

完成 Feature

1
2
3
4
5
6
7
8
9
10
11
12
13
git pull origin develop
git checkout develop 

#--no-ff：不使用fast-forward方式合并，保留分支的commit历史
#--squash：使用squash方式合并，把多次分支commit历史压缩为一次

git merge --no-ff feature
git push origin develop

git branch -d some-feature

# 如果需要删除远程feature分支:
git push origin --delete feature

开始 Release

1
git checkout -b release-0.1.0 develop

完成 Release

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
git checkout master
git merge --no-ff release-0.1.0
git push

git checkout develop
git merge --no-ff release-0.1.0
git push


git branch -d release-0.1.0
git push origin --delete release-0.1.0   

# 合并master/devlop分支之后，打上tag 
git tag -a v0.1.0 master
git push --tags

开始 Hotfix

1
git checkout -b hotfix-0.1.1 master

完成 Hotfix

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
git checkout master
git merge --no-ff hotfix-0.1.1
git push


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

git branch -d hotfix-0.1.1
git push origin --delete  hotfix-0.1.1 


git tag -a v0.1.1 master
git push --tags

GitFlow的优点

  1. 适应场景多
  2. 不影响开发进度
  3. 分支使用相对有条理
  4. 确保线上的版本稳定

GitFlow的缺点

GitFlow并不是完美无缺的，这只是一种管理思维，以下是它的一些缺点。

1.因为分支态度，所以会出现git log混乱的局面：主要是因为git-flow使用git merge –no-ff来合并分支，在git-flow这种多分支的环境下会让整个项目的log变的非常混乱。

1661080330366.png

对于整个中情况我们可以：只有feature合并到developer分支时， 使用-no-ff参数，其他的合并都不使用–no-ff

什么是git merge –no-ff

1
2
3
4
5
6
7
8
9
10
11
--no-ff指的是强行关闭fast-forward方式。
fast-forward方式就是当条件允许的时候，git直接把HEAD指针指向合并分支的头，完成合并。属于“快进方式”，
不这种情况如果删除分支，则会丢失分支信息。因为在这个过程中没有创建commit
  
git merge --squash 是用来把一些不必要commit进行压缩，比如说，你的feature在开发的时候写的commit很乱，
那么我们合并的时候不希望把这些历史commit带过来，于是使用--squash进行合并，此时文件已经同合并后一样了,
但不移动HEAD，不提交。需要进行一次额外的commit来“总结”一下，然后完成最终的合并。

总结：
--no-ff：不使用fast-forward方式合并，保留分支的commit历史
--squash：使用squash方式合并，把多次分支commit历史压缩为一次

2.同时维护Master和Developer两个分支很多时候是没必要的，因为在很多场景下Master中的内容和Developer中的内容是差不多的。尤其当你想回滚某些人的提交时，你就会发现这事似乎有点儿不好干了。而且在工作过程中，你会来来回回地切换工作的分支，有时候一不小心没有切换，就提交到了不正确的分支上，你还要回滚和重新提交，等等。