为什么去学习 gitflow 与 code review？
我对于 gitflow 和 code review 的概念是在去年十月参加的阿里巴巴终端练习生的训练营里的结项要求中了解到的。
- 当时只是去粗略了解了gitflow的工作流程，然后使用 sourcetree 进行操作，看了一个视频跟着就做了，实际上和没有 gitflow 没有区别。
- 其次是 code review，在项目实现阶段可以向指导老师请求指导，一共请求了两次，老师当时多次强调 code review 的重要性。自己也去网上了解了 code review ，对于它的好处看了很多了，怎么去 code review 却还是一知半解。最后因为要结项了，就成员内部互相查看代码点评并且进行调整，这样我们就当作是进行了code review 了
因为并没有成功操作过 gitflow 以及 review 代码，以至于在以后的开发中涉及到这一块知识，都只是模糊的概念，细问之下，什么都不懂。于是我打算不再回避，至少得成功实现 gitflow 以及 review！
学习成果
自己现在的管理分支模式（流程）：
Tips：该流程大部分参照于此文章[：](GIT工作流指南系列--gitFlow工作流 - 掘金 (juejin.cn)) 如有侵权或其他意见请联系本人（卑微）
- 使用
git flow init初始化自己的仓库 - 使用
git flow feature start 分支名在本地仓库新建一个功能分支 - 使用
git flow feature publish 分支名在远程仓库也新建一个功能分支，并且将本地的功能分支完全复制进去 - 进行相应的开发以及使用 git push origin feature/分支名 更新代码（就像正常开发推送分支一样）
- 当功能开发完毕，不急着推送代码。因为我将远程develop分支设置为保护分支了，用户只能拉取不能推送，只能通过提交PR合并代码（这一步也是为了 code review 做准备）
- 在仓库中点击 open pull request 提交 PR，具体操作可以自行百度了解 tips：PR是github中的叫法，MR是gitlab中的叫法
- 提交了 PR 后得有一个人来审查代码，并且确认通过后就可以点击 merge request ，将当前分支的代码合并到目标分支
- 功能开发完毕之后，使用
git flow feature finish 分支名将本地功能分支合并到develop，并且将该本地功能分支以及远程功能分支删除
总结：
- 此次流程只是我根据大佬的这篇掘金流程模仿实现的，中间也产生了很多疑惑，一点点搜索、了解、尝试慢慢排查完疑惑最终形成了以上的协作模式。一开始甚至连‘PR’、‘MR’都不懂，只是根据网上描述的 code review 是需要被审核人通过才能合并代码这种理想的合作模式钻研下去才懂的。
- 这个流程仍然存在很多的不足，因为我对于其他公司中的协作以及主流的git模式仍然模式
-
- 比如对于 PR 的提交能不能指定特定的用户进行审核，并且给对方发送邮件，而不是只发给仓库建立者本人
-
- 比如对于 develop 分支有没有必要设置为保护分支，并且标记必须得通过审核才允许合并？
-
- 比如在 通过 PR 之后的合并工作中，直接点击 merge request 按钮产生冲突怎么办？
-
- 如果要使用 git 的方式 merge 代码，那么流程是怎么样的？ develop 分支设置为了保护，在github上通过 review 了可以使用代码直接 merge 吗？
-
- 等等问题还需要我继续钻研进行学习，同时也期待掘金中的大佬们为我提一些意见，实在是知识面狭窄不太了解整个流程
此次学习参考的学习文章
[掘金的文章，给我提供了很大的帮助](GIT工作流指南系列--gitFlow工作流 - 掘金 (juejin.cn))
这个文章为我对掌握 gitflow 概念中提供了很大的帮助，特别是 主分支 和 辅助分支 的概念
学习过程
学习过程中经历坎坷，gitflow 尝试完后为了测试 code review 还专门开了一个 github 小号拉进仓库进行 review 哈哈哈哈
