Git 工作流
例如：
- GitFlow 模型
- GitHubFlow 模型
简述一下 GitFlow 工作流 (Git Branching Model)
- 原则 1： 主分支永远是可以立马执行得到结果的：
main分支保持 Production Ready（生产环境可用） 。 - 原则 2： 开发新功能就创建一个新分支，开发完合并回去：Feature Branch（功能分支）开发模式。此外，用这样的命名法：
feature/add-kalman-filter（开发卡尔曼滤波新功能）或feature/auto-script。在这个分支上代码怎么乱、怎么崩溃都没关系，完全不污染main。 - 原则 3： 维护一个专门用于修复 bug 的分支，修复完合并：Hotfix Branch（热修复分支） 。如果突然发现一个数据越界 Bug。立马从
main拉出一个hotfix/fix-array-out-of-bound分支，修好测试没问题后，立刻merge回main。 - 合并分支的时候需要好好处理冲突：Resolve Merge Conflicts。
细节补充：什么时候用 merge 什么时候用 rebase？
Rebase 最经典的用途：“让我的功能分支基于最新的主分支开发”。
假设这样一个场景，你在开发新功能(main 分支 和 featrue 分支)；
但是你的老板要你做一下演示，所以直接 switch 到 main：
git switch main # 切换到主分支
不过你在做演示的时候发现了一个 BUG，所以必须要解决，
于是你创建了一个 fixhot-bug-name 分支，并在在这个分支上修复 BUG：
git branch fixhot-bug-name # 新建分支
git switch fixhot-bug-name # 切换过去修 BUG
因为 BUG 会影响后续开发，所以必须优先解决，修复完成之后，
使用 merge 合并分支，并且记得需要解决冲突问题：
git switch main # 是别的分支合并过来，所以切到 main
git merge fixhot-bug-name # 合并 BUG 修复之后的分支
此时会面临冲突，需要手动修复，这里可以查看冲突；
git status # 查看哪些文件有冲突
git diff # 查看具体的冲突内容
手动解决冲突，然后继续合并(再次提交一次)：
git add . # 解决冲突时会修改内容所以要重新 add
git commit -m "修复-XX-BUG" # 提交成功才算合并完成
最后可以把这个 hotfix 分支删除：
git branch -d fixhot-bug-name # 删除这个分支
此时想起来，你的 feature 分支是基于有 BUG 的版本开发的，所以需要变基：
git switch featrue # 切换过来
git rebase main # 变基
因为这也是一次合并，所以也可能会有冲突，所以需要手动解决，然后：
git add . # 解决冲突时会修改内容所以要重新 add
git rebase --continue # 继续变基
然后就可以继续开发了！
（补充，如果你的分支在 rebase 之前已经 push 过一次，那么很遗憾，你下次 push 的时候必须使用强制推送：git push -f origin feature ）
最后补充一句：
“绝不要对已经 Push 到远程公共仓库（且有别人在用）的分支执行 Rebase！”
因为 Rebase 的本质是**“篡改历史”**。你在本地怎么篡改自己的 feature 分支都没人管，这叫“打扮干净再出门”。
但如果你把 main 分支 Rebase 了，还强制推送到云端，你实验室的其他同学一拉代码，会发现他们的整个时空线全乱了，这会导致灾难性的代码丢失。
所以你的直觉是对的：Rebase 永远只用在你自己本地还没合并的 feature 分支上，用来去同步 main 的最新代码。 只要遵守这一条，你在 Git 的世界里就可以横着走了。
