简单介绍TBD
基于rebase的工作流
引入feature功能分支开发模式
- 拉新分支
- 在功能分支提commit
- 每天git rebase master, 解冲突，git push -f
- 通知项目其他成员拉最新代码
- 独立部署功能分支，完成CI/CD
- 合master git merge feature/xxx –no-ff
- 回测
分支创建和切换
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：
master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
dev指针，改改HEAD的指向，工作区的文件都没有任何变化！dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
一般合并和快速合并
git pull
一般合并：
本地和远端有新的提交C3、 C4, git pull ,本地和远端分支合并生成C5
快速合并：
本地分支的提交都被包含在了远程分支的提交
Rebase分支合并
rebase是能够将我们对代码的更改从一个分支集成到另一个分支中的git命令之一（另一个命令是Merge）。使用rebase的一个风险在于，它会改写commit历史，如果操作不当那么会是一种破坏性的操作。
风险总是与利益并存的，使用rebase也好处良多，体现在于：
- 能够保持提交记录的清爽，不带来额外的提交历史（而使用
merge会生成一条merge的commit） - 能够保持commit线的线性，保持成一条直线，从而能够容易地看出代码是如何推进的
git:(master) git checkout -b feature1
master 分支的改动，如果用mergegit:(feature1) git merge master
就会在记录里发现一些 merge 的信息，但是我们觉得这样污染了 commit 记录，想要保持一份干净的 commit，怎么办呢？这时候，git rebase 就派上用场了。
rebase 的过程中，也许会出现冲突 conflict。在这种情况，git 会停止 rebase 并会让你去解决冲突。在解决完冲突后，用 git add 命令去更新这些内容。git rebase --continue
git 会继续应用余下的 patch 补丁文件。--abort 参数来终止 rebase 的行动，并且分支会回到 rebase 开始前的状态。git rebase —abort
--no-ff指的是强行关闭fast-forward方式。
fast-forward方式就是当条件允许的时候，git直接把HEAD指针指向合并分支的头，完成合并。属于“快进方式”，不过这种情况如果删除分支，则会丢失分支信息。因为在这个过程中没有创建commit
git merge --squash 是用来把一些不必要commit进行压缩，比如说，你的feature在开发的时候写的commit很乱，那么我们合并的时候不希望把这些历史commit带过来，于是使用--squash进行合并，此时文件已经同合并后一样了，但不移动HEAD，不提交。需要进行一次额外的commit来“总结”一下，然后完成最终的合并。