Hello，各位朋友好！我是 Brian，一名拥有 15 年互联网后端工作经验的架构师。我毕业于上海交通大学的软件工程专业，曾经在多家世界 500 强企业出任架构师以及技术经理的职位。开设这个专栏，其主要目的在于将我过去这十几年所积累的部分内容，与大家进行一番小小的分享。期望大家在看完这个专栏之后，能够在秋招当中有卓越的表现，成功斩获令自己心满意足的 offer。
这个专栏区别于其他专栏，不会去罗列一些比较基础的面试题（俗称八股文），更多地会专注于工作中遇到的一些实际的场景题，通过这些场景题教会大家如何去处理工作中实际的问题。当然我一个人的能力还是相对比较有限的，如果读者们在学习过程中有疑惑或者质疑，请在留言区多多交流。
1.1 如何进行有效的分支管理？
使用git之后，如何在团队中根据项目去管理分支呢？业界比较常用的git分支管理方法有两种:
-
gitflow gitflow有一个比较复杂的管理模型，它的优点是权限管理比较严格，并不是所有人都能在所有分支上进行代码的合并，比较适用于成熟或者开源的项目。
-
trunk 基于主干的分支管理方法，相比较gitflow，这种方式的主干数量相对比较少。比较适合刚起步的项目。
接下来简单介绍一下这两种模型：
- gitflow
上图是流程图，
master是发布版本的分支，所有合并到master分支的操作都需要进行审核。develop是开发分支，用于将开发完的需求进行合并。feature是特性分支，用来开发需求。本次迭代开发完成之后，从develop拉出release分支进行测试以及bug的修正，最后合并到master进行发版。
适用场景
-
当你运行一个开源项目时。
开源社区对合并请求的审核比较严格 -
初级开发人员较多
如果你主要与初级开发人员合作，那么你需要一种方法来密切检查他们的工作。你可以给他们提供多种提示，让他们更有效地完成工作，并帮助他们更快地提高技能。接受拉取请求的人对重复的更改有严格的控制，这样他们就可以防止代码质量下降。 -
成熟的产品
这种风格在已经拥有成功的产品时似乎也适用。在这种情况下，重点通常放在应用程序性能和负载能力上。这种优化需要非常精确的更改。通常，时间不是限制，所以这种风格在这里很有效。此外，大型企业非常适合这种风格。 -
trunk 基于主干的分支管理
所有feature都可以直接合并到master，但是master不用来发版，最后需要拉出来release分支进行测试并完成发版动作。
适用场景
由于这种模式较为简单，所以适合以下几种场景：
- 当你刚刚起步时。
- 快速迭代
- 高级开发人员较多
总结
同学们从上述的两种管理模式中，选择一种更适合自己团队的即可，trunk更适合初创、中小型团队。
1.2 如何进行分支的回滚？
git中回滚可以使用两个命令git revert和git reset来完成，要注意他们之间的区别：
什么是 Git Revert？🔄
Git Revert 用于撤消更改。此操作会创建一个新的提交，通过撤消更改来撤消更改。与其他开发人员合作时，Revert 是一种更安全的选择，因为它会保留提交历史记录并且不会影响其他人的工作。
要执行恢复操作，请使用以下命令：
git revert <提交哈希>
运行此命令后，将创建一个包含恢复的更改的新提交，并更新提交历史记录。
可以看到
revert之后多出来一次提交记录，是将之前的代码进行还原。
什么是 Git Reset？🔙
Git Reset 用于通过重写提交历史记录来撤消操作。此操作将删除当前 HEAD 和指定提交之间的所有提交，并将工作目录中的文件恢复到指定提交的状态。与其他开发人员合作时，Reset 可能会导致问题，因此应谨慎使用。
要执行重置操作，请使用以下命令：
git reset --hard <提交哈希>
运行此命令后，返回到指定的提交，并且提交历史记录被更新。
使用场景：Revert 可用于撤消意外更改或更正与他人合作时所做的更改。Reset 更适合编辑本地更改并清理提交历史记录。
1.3 merge和rebase的区别
git rebase它解决的问题与git merge 相同。这两个命令都是为将一个分支的更改集成到另一个分支而设计的 , 只是它们实现的方式不同。git rebase主要解决这类问题：
如果A在feature分支上开发，希望将main（公用）分支上别人提交的内容合并到自己分支使用，如果使用git merge会产生一次从main到feature的合并动作，这应该不是我们想看到的：
我们更想看到的应该是从feature到main的合并，这种场景下就可以使用rebasse：
rebase只是将main上的改动嫁接到了当前分支，保证了此次合并不会产生多余的merge记录。但是千万不要将rebase用于合并到公用分支比如main上，这样会导致合并记录丢失。
