git config –system –unset credential.helper

2020.9.13 星期日 22：58

Git 工作流程

本文介绍三种广泛使用的工作流程：
Git flow, Github flow, Gitlab flow
有一个共同点：都采用”功能驱动式开发”（Feature-driven development，简称FDD）。
它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。

Git flow

1) 首先，项目存在两个长期分支。
主分支master
开发分支develop

2) 其次，项目存在三种短期分支。一旦完成开发，它们就会被合并进develop或master，然后被删除。
功能分支（feature branch）
补丁分支（hotfix branch）
预发分支（release branch）

3.2 评价

Github flow

它只有一个长期分支，就是master，因此用起来非常简单。

第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。
第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。
第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。
第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）

3.2 评价

问题在于它的假设：master分支的更新与产品的发布是一致的。也就是说，master分支的最新代码，默认就是当前的线上代码。

Gitlab flow

Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。

### 4.1 上游优先
Gitlab flow 的最大原则叫做”上游优先”（upsteam first），
即只存在一个主分支master，它是所有其他分支的”上游”。只有上游分支采纳的代码变化，才能应用到其他分支。

Chromium项目就是一个例子，它明确规定，上游分支依次为：
Linus Torvalds的分支, 子系统（比如netdev）的分支, 设备厂商（比如三星）的分支

### 4.2 持续发布
Gitlab flow 分成两种情况，适应不同的开发流程。

对于”持续发布”的项目，它建议在master分支以外，再建立不同的环境分支。比如，”开发环境”的分支是master，”预发环境”的分支是pre-production，”生产环境”的分支是production。

只有紧急情况，才允许跳过上游，直接合并到下游分支。

### 4.3 版本发布
对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。
以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。

五、一些小技巧

5.1 Pull Request

5.2 Protected branch

5.3 Issue

开发完成后，在提交说明里面，可以写上”fixes #14”或者”closes #67”。Github规定，只要commit message里面有下面这些动词 + 编号，就会关闭对应的issue。

5.4 Merge节点

Git有两种合并：一种是”直进式合并”（fast forward），不生成单独的合并节点；
另一种是”非直进式合并”（none fast-forword），会生成单独节点。

前者不利于保持commit信息的清晰，也不利于以后的回滚，建议总是采用后者（即使用–no-ff参数）。
只要发生合并，就要有一个单独的合并节点。

1
2
3

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

5.5 Squash 多个commit

为了便于他人阅读你的提交，也便于cherry-pick或撤销代码变化，在发起Pull Request之前，应该把多个commit合并成一个。
（前提是，该分支只有你一个人开发，且没有跟master合并过。）

这可以采用rebase命令附带的squash操作，具体方法请参考我写的《Git 使用规范流程》。

总结

3种。
git flow：原始/简单；两个分支master，develop
github flow: github 社区方式；每个人都可以fork/checkout 分支，提PR，然后merge。最后部署，或和删除
gitlab flow: 工作中多环境，多分支/开发/需求。上线流程

实践

master：主分支，和线上保持一致
release：可以是测试分支
stage/gray: 灰度环境
develop：其余分支；多开发人员；不同feature分支；
比如：dev/xxxxx/20200919;
dev/mall/xxxxx/20200919-feat;
dev_feature_xxxxx_20200908_inviteNew_3.2.2
0) 多个feature 分支，也可以合并到一个develop分支。再从这一个develop分支push
1） release 也可以有个人/自己的分支，然后合并到唯一的release中发布测试
2） state/gray 可以没有。直接合并master 打tag（方便回滚等）发布灰度
3）最后master 可以直接发布到线上

开发新feature分支都需要从master拉取最新线上代码

切勿把release（不是自己提交的ci）带到线上
（有时别人提交了测试导致当前分支落后于release，merge时有冲突，解决冲突时污染了自己的开发分支）可以 checkout一个新分支提交release

可以通过merge把开发分支合并到master分支，或者 rebase保持提交信息单一
同理把最新的master同步到当前的开发分支也一样
使用rebase注意，一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作；

进阶

cherry-pick
rebase命令附带的squash操作

git-flow

git-flow 是一个 git 扩展集，按 Vincent Driessen 的分支模型提供高层次的库操作。