选择工作流和协作方式

集中式工作流：Gerrit / SVN，只依托于主干分支进行开发，没有其他分支，只有 master 分支。工作过程为拉取远端 master，合并 rebase，解决冲突，提交到 master
分支式工作流：github / gitlab

分支管理工作流

git flow：较早期的分支管理策略，分支类型丰富，规范严格但复杂，比较难以执行
Github flow：只有一个主干分支和一些开发分支，规则简单
Gitlab flow：在主干分支和开发分支之上构建环境分支，版本分支，满足不同发布 or 环境的需要

团队合作的方式

其他用户通过 fork 的方式来创建自己的仓库，并在 fork 的仓库上进行开发，最后提供 PR 给仓库
Owner 统一给团队内成员分配权限，直接在同一个仓库内进行开发

合并方式

Fast-forward

不会产生一个 merge 节点，合并后保持一个线性历史，如果 target 分支有了更新，则需要通过 source branch 后才可以合入。在 main 分支中使用这种形式合并 test 分支：git merge test --ff-only

三方合并 Three-Way Merge

产生一个新的 merge 节点。在 main 分支中使用这种形式合并 test 分支： git merge test --no-ff

Github 仓库操作

创建新仓库和主分支

在 github 上创建一个新仓库(private 仓库功能不全要开会员)，克隆到本地处理
提交，远端操作 push main 创建主分支

git clone git@.../demo.git
cd demo
tree .git
#此时仓库的文件结构为
#.git下有HEAD config hooks(下有commit-msg) objects(下有info pack) refs(下有heads tags)
vim readme
git add .
git commit -m "add readme"
git push origin main
#*[new branch]  main -> main 主分支已被创建

创建一个新开发分支 & pull request

在本地创建新分支，做出修改，push 分支名
之后有两种方法可以 pull request，一是直接在 push 结果中点进链接，一是点进 github 分支页面找 pull request 按钮
pull request 后可以看到一些合入前要做的事情

Code Review：人工检查代码，在 request 中可以看到原代码和这份代码的区别。CI：通过一些定制化的脚本来进行一些检验

#创建新分支
git checkout -b feature
git add .
git commit -m "新分支"
git push origin feature
#remote: Create a pull request for 'feature on github by visiting:
#remote: http://github.com/.../pull/new/feature
#点进这个链接即可 pull request, 检查然后合并
#合并之后就重新获取 main 分支继续开发
git pull origin main

设置保护分支

Branches -> branch protection rule -> 对分支（比如 main）的保护策略

比较常用的策略比如说

必须要通过 pull request 才能合并，require approval 更进一步要求第二个人检验确认 request 才能合并
Conversation 解决才能合并
线性历史，不产生 merge commit 节点
Include administrator 此权限限制也对管理员生效

小结

git 对团队写作至关重要。对于青训营项目这样的小型团队合作来说，使用 github 工作流即可，主干分支尽量保持简洁，使用 fast-forward 合入方式

Git 的正确使用姿势与最佳实践 | 青训营