转载两篇之前学习开源的时候保存的两篇关于团队协作Git使用规范的文章,个人感觉很有用,第一篇Gitg工作流的作者我找不到了,第二篇是牛客的baize_大佬
1. Git 四种工作流
下面会讲解四种git工作流，无论是在校课题组还是公司内部，都可以以此为基础找到合适的git团队工作模式。
Centralized Workflow 集中式工作流
介绍
三个开发人员共同维护一份远程仓库的代码，工作方式如下：
- 每次工作前从
remote拉取master分支到本地的master分支，然后处理冲突（使用IDE自带的GUI图形用户界面处理冲突会比较方便，如图中的goland内置的git工具）
接着开始编码，编码完成后add修改的文件到缓冲区
commit缓冲区文件到自己local仓库，并且push本地仓库文件到remote仓库
评价
集中式工作流：这种工作方式简单粗暴，所有人只使用master分支维护项目，master永远是项目最新版本，编码比较快，立竿见影。但是所有开发者提交日志集中在一起呈单线延伸，难以定位问题，分工不明确，且容易发生冲突，处理冲突成本上升，但是单人开发很便利。
Feature Branch Workflow 功能分支工作流
介绍
功能分支工作流以集中式工作流为基础，在维护master分支的基础上，将项目的开发工作拆分为添加一个个的feature的形式，工作方式如下：
一旦需要开发新的功能，就在remote的master分支的基础上创建一个feature xxx分支
本地创建对应的feature xxx分支
每次开发前将remote库的feature xxx分支拉取到本地，处理冲突
然后在本地feature xxx分支上开发，然后push到remote的feature xxx分支
在项目主页上发起pull request（如果是gitlab则是merge request，作用相同），本意是提出将feature xxx分支合并入master分支的请求
- 然后你的代码会被review，没通过就本地改，改完之后继续
push到remote（两头都在feature xxx分支），然后负责人继续review你这个PR或者MR，通过之后会将feature xxx分支区别于master的改动合并入master，删除remote的feature xxx分支，代表这个功能开发完毕
评价
功能分支工作流：这种工作方式带来了code review的功能，使得推送的代码更符合规范，减少bug产生。并且因为主要还是在master分支基础上根据功能需求创建feature分支，使得开发工作十分灵活，且各个功能之间隔离，但是对于大型项目而言需要为不同分支分配更加具体的角色，只有feature分支是不够的。
Gitflow Workflow
介绍
Gitflow工作流是我目前尚在熟悉的一种工作流，也是目前非常成熟的git工作流方案。区别于功能分支工作流，Gitflow工作流划分分支更有约束性。主要包括：
主分支master：用于跟踪项目正式发布的版本（tag标签号）
开发分支dev：用于跟踪代码研发的提交历史
功能研发分支feature：每次有新的功能需要研发，以dev分支为基础，建立feature分支，开发完成后按上面feature branch工作流的方式提交PR/MR到remote的dev分支，完成之后删除对应feature分支
热修复分支hotfix：如上图所示，master分支出现bug（线上报bug了），需要马上从master拉取一个hotfix分支处理修复bug，并且将代码合并到master和dev（这两个分支需要保持bug修复的一致性），修复后给master当前提交打一个tag（v0.2）
发布分支release：在dev基础上建立release分支，处理一些问题、修复一些bug之后，将代码合并入master与dev，并给master打上tag（v1.0）表示发布完成
评价
约束性更强，发布迭代流程更规范，严谨，开发人员分工更明确，十分推荐学习使用。
Forking Workflow
介绍
这种工作流是开源项目维护的工作流，暂作了解即可，通过将他人的项目fork到自己的remote仓库，就可以将其作为自己拥有的一份副本进行开发，比如想增加一个功能或者修复一个bug。这里A与C都fork了B的仓库，在各自开发完成新功能之后可以提交PR给B仓库，B仓库的开发者负责review代码，并接受PR。
评价
具体还未尝试过提交PR给开源项目，但是相信在掌握了上述三个git工作流之后，以后要使用到forking工作流的问题也应该引刃而解。
结束
学习了四种git工作流之后，并不是要完全照搬某一个模式的所有使用流程，而是应该结合实际的项目规模和人员规模进行合理安排。比如对于校内课题组较小的项目我认为feature branch工作流应该足以胜任，或者使用只有master、dev、feature的简化版Gitflow工作流。
二. 开源工作中的 git
🌟 针对开源项目，一般都选择 fork 仓库的形式进行开发：
1.将开源仓库 fork 到自己的 remote hertz。
2.在自己本地克隆自己的 remote hertz。
3.从本地的 develop 分支（或者 main 分支），切换一个新的 feature 分支出来，针对你要开发的内容，比如要增加 /pkg/router 的单测，则执行命令：
复制代码
| 12 | # 分支命名没有绝对约束，但是希望见名知意checkout -b test_pkg_router |
| --- | --- |
4.开发完成之后，将本地 test_pkg_router 分支代码，提交到自己的 remote hertz 的 test_pkg_router 分支。 ⚠️注意：开发完成之后，不要急着提交，一般需要按照 CONTRIBUTING.md 的要求运行指定控制台命令进行单测运行与代码格式化等操作，确定没有问题后才能提交。
5.在自己的 remote hertz 仓库内，创建一个 pull request，将自己 remote hertz 仓库的 test_pkg_router 分支请求合并到 Hertz 官方仓库的开发分支上。提交 pr 的时候，需要描述自己的工作内容，以便 reviewers 快速明白你的意图，举个例子：
6.提交 pr 之后，一般都会触发 .github/workflows 目录下的各种 CI 流程，只有全部通过之后，reviewers 才能同意合入代码（code lint、test 等操作在这里也会执行，所以本地提前执行一次是未雨绸缪）：
