最近疯狂写小程序项目，像类似于app.json公共配置文件老是存在冲突，给爷整哭了。这就说明在使用Git的过程中要有清晰的流程和规划，为了每个人能够写的都和谐，减少冲突。

这些流程应被视作为指导方针而非“铁律”。人家只是想告诉你可能的做法。如果有必要的话你可以组合使用不同的流程。像我现在做的小项目完全用不到这么严谨的流程，最多打个分支即可。

Git Flow的一些介绍

网上说Vincent Driessen写过一篇博文，题为“A successful Git branching model”（一个成功的Git分支模型。Gitflow工作流程就是从这篇文章里借鉴来的，这个英文我也看不懂，就单纯做个引入。
Gitflow流程仍然使用一个中央代码仓库，它是所有开发者的信息交流中心。开发者在本地完成开发，然后再将分支代码推送到中央仓库。唯一不同的是项目中分支的结构。

Gitflow工作流

关于Git Flow 的分支说明

Master 分支

Gitflow使用两个分支来记录项目开发的历史：

  1. master只是用于保存官方的发布历史；所有在Master分支上的Commit应该打上Tag，一般情况下Master不存在Commit，Devlop分支基于Master分支创建;
  2. develop分支才是用于集成各种功能开发的分支。在创建新的功能开发分支时，父分支应该选择develop（而不是master）。当功能开发完成时，改动的代码应该被合并（merge）到develop分支。功能开发永远不应该直接牵扯到master。
    Gitflow工作流
Develop 分支

这个分支是我们是我们的主开发分支，包含所有要发布到下一个版本（Release）的代码，这个主要合并别人创建的Feature分支。
我这里创建一个空的develop分支，推送到服务器代码仓库。

1
2
3
git branch develop  

git push -u origin develop

接下来，我们团队其他开发人员开始迁出代码，并且切换到develop分支，以后基于这个分支再创建其他（Feature）分支。

1
2
3
git clone git@git.wisder.net:wisder/smile-shop-miniprogram.git

git checkout -b develop origin/develop
Feature 分支

这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release;
Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，毕竟保留下来意义也不大。
Gitflow工作流

作为团队的成员，通过下面命令创建基于develop的分支开始工作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 通过develop新建feaeure分支
git checkout -b some-feature develop

# 如果需要可推送至远程服务器:
git push -u origin some-feature  

# 上传自己的文件   
git status
git add .
git commit    

# 推送到develop分支
git pull origin develop
git checkout develop

#--no-ff：不使用fast-forward方式合并，保留分支的commit历史
#--squash：使用squash方式合并，把多次分支commit历史压缩为一次
git merge --no-ff some-feature -m '合并分支'
git push origin develop
# 删除这个分支
git branch -d some-feature
# 如果需要删除远程feature分支:
git push origin --delete some-feature
Release分支

当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后我们合并到Master和Develop分支;
Release分支基于Develop分支创建，打完Release分支之后，我们可以在这个Release分支上测试，修改Bug等。同时其它开发人员可以基于Develop分支新建Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。
Gitflow工作流

开始发版：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 这个分支专门用于发布前的准备，包括一些清理工作、全面的测试、文档的更新以及任何其他的准备工作。
git checkout -b release-0.1.0 develop

# 接下来要把发布分支合并入master和develop分支，然后再将发布分支删除
git checkout master
git merge --no-ff release-0.1.0 -m '合并发布分支'
git push

git checkout develop
git merge --no-ff release-0.1.0 -m '合并发布分支'
git push

# 删除分支
git branch -d release-0.1.0
# 如果需要，删除远程分支
git push origin --delete release-0.1.0   

# 发布分支扮演的角色是功能开发（develop）与官方发布（master）之间的一个缓冲，
# 无论什么时候把一些东西合并入master，都应该打上合适的标签
git tag -a v0.1.0 -m "Initial public release" master
git push --tags
Hotfix分支

当我们发布完后发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release。
hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag。
Gitflow工作流

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
git checkout -b hotfix-0.1.1 master

# 合并master
git checkout master
git merge --no-ff hotfix-0.1.1 -m '修复bug'
git push

# 合并develop
git checkout develop
git merge --no-ff hotfix-0.1.1 -m '修复bug'
git push

# 删除该分支
git branch -d hotfix-0.1.1
git push origin --delete  hotfix-0.1.1

# 打标签
git tag -a v0.1.1 master -m '修复bug后的新版本'
git push --tags