Git 操作文档

merge原理

git merge接受两个commit指针，通常是两个分支的顶部commit，然后向前追溯到这两个分支最近的一个共同提交。一旦找到这个共同提交，Git就会创建一个新的"merge commit"，用来合并两个分支上各自的提交序列。

合并commit与普通commit不一样，因为合并commit会有两个父提交。创建一个合并commit时Git会尝试自动将两个独立的提交历史合并为一个。不过当Git发现某一块数据在两边的提交历史中都含有变更，它将无法自动对其进行合并。这种情况被称为版本冲突，此时Git需要人为介入调整才能继续进行合并。

确认接收合并的分支

执行git status命令查看当前分支的状态，确保HEAD指正指向的是正确的接收合并的分支。如果不是，执行git checkout命令切换到正确的分支。执行git checkout

。

获取最新的远程提交

确保合并操作涉及的两个分支都更新到远程仓库的最新状态。执行git fetch拉取远程仓库的最新提交。一旦fetch操作完成，为了保证main分支与远程分支同步，还需执行git pull命令。

合并

当上面提及的准备工作都已完备，合并就可以正式开始了。执行git merge 命令，其中branch为需要合并到当前分支的目标分支名称，如feature。

rebase原理

main有一个新提交M

feature有两个新提交C,D

现在我想在feature分支上拉取main分支

这两条命令等价于git rebase master feature

git checkout feature

git rebase master

当在feature分支上执行git rebase master时，git会从master和featuer的共同祖先B开始提取feature分支上的修改，也就是C和D两个提交，先提取到。然后将feature分支指向master分支的最新提交上，也就是M。最后把提取的C和D接到M后面，注意这里的接法，官方没说清楚，实际是会依次拿M和C、D内容分别比较，处理冲突后生成新的C’和D’。一定注意，这里新C’、D’和之前的C、D已经不一样了，是我们处理冲突后的新内容，feature指针自然最后也是指向D’

通俗解释（重要！！）：rebase，变基，可以直接理解为改变基底。feature分支是基于master分支的B拉出来的分支，feature的基底是B。而master在B之后有新的提交，就相当于此时要用master上新的提交来作为feature分支的新基底。实际操作为把B之后feature的提交先暂存下来，然后删掉原来这些提交，再找到master的最新提交位置，把存下来的提交再接上去（接上去是逐个和新基底处理冲突的过程），如此feature分支的基底就相当于变成了M而不是原来的B了。（注意，如果master上在B以后没有新提交，那么就还是用原来的B作为基，rebase操作相当于无效，此时和git merge就基本没区别了，差异只在于git merge会多一条记录Merge操作的提交记录）

rebase黄金法则：不要对已经提交到共享仓库（如远程仓库）的提交执行 rebase

提交规范

feat 增加新功能

fix 修复问题/BUG

style 代码风格相关无影响运行结果的

perf 优化/性能提升

refactor 重构

revert 撤销修改

test 测试相关

docs 文档/注释

chore 依赖更新/脚手架配置修改等

workflow 工作流改进

ci 持续集成

types 类型定义文件更改

wip 开发中

企业Git开发流程 Git flow