基础·Gitlab Flow 工作流程
很多公司都使用 Gitlab 来进行团队的代码管理。Gitlab 是一个基于 git 实现的在线代码仓库软件，一般用于在企业、学校等内部网络搭建一个类似 Github 的网站。在这上面进行多人协作开发就使用 Gitlab flow 工作流程，与 Github flow 有许多相似的地方。
一个典型的开发过程是这样的（假设项目名称为 a，程序员的名字叫 xyz）：
「第 1 步」
在 Gitlab 上找到项目主仓库，假设为 fe / a，将其 fork 到自己的空间，变成 xyz / a，然后 clone 到本地进行开发，命令为：
git clone git@git.yourcompanyname.com:xyz/a.git
（ fork 到自己空间的仓库可以随意修改，除非向项目主仓库提交 MR 并合并，不然不会影响主仓库）
「第 2 步」
新建分支，在该分支上进行新功能开发，命令为：
git branch feat-xxx
git checkout feat-xxx
「第 3 步」
开发自测结束后，将修改提交至本地仓库， 命令为：
git add .
git commit -m “feat: 增加xxx新功能”
（ Commit Message 的规范可以是：新增功能以「feat:」开头，修复 bug 以「fix:」开头，重构以「refactor:」开头）
「第 4 步」
检查上游版本是否有改动，命令为：
git remote add upstream git@git.yourcompanyname.com:fe/a.git
git pull upstream master --rebase
（add upstream 是添加上游地址，即主仓库地址，仅第一次需要；使用 --rebase 便不会产生 merge commit，使 commit 干净清爽）
——若存在代码冲突，则进入「第 a 步」，否则跳过该步。
「第 a 步」
手动解决冲突后，执行命令：
git add .
git rebase --continue
「第 5 步」
检查 git log 无误，将分支推送至 origin，命令为：
git push origin feat-xxx
完成后在 Gitlab 上向主仓库发起 Merge Request（MR），请同事进行 code review。
——若同事对 MR 提出修改意见，则进入「第 b 步」，否则跳过该步。
「第 b 步」
按照修改意见修改后，执行命令：
git add .
git commit --amend --no-edit
git pull upstream master --rebase
git push origin feat-xxx -f
（使用 --amend 将这次 commit 与上次 commit 合并，只留下一条 commit 记录。如果要修改上一条的 message，则使用 git commit --amend -m “xxx”; push 的时候使用 -f 是因为修改了分支，需要强制合并）
「第 6 步」
MR 被通过后，在 Gitlab 上点击 merge，代码会被合并到主仓库。此时可删除本地分支了，命令为：
git checkout master
git branch -D feat-xxx
git push origin :feat-xxx
「第 7 步」
更新本地代码和 origin 代码为最新，命令为：
git pull upstream master --rebase
git push origin master
再次开发则从「第 2 步」开始即可。
