从项目实践中总结Git的使用

拉取远程更新同步本地Fork

• 主要用于同步NotionNext上游更新

一次性

• 设置上游仓库地址

• 查看当前已经设置的远程仓库

重复用

• 拉取上游代码库更新（fetch只拉取更新，不直接修改本地分支，pull会直接进行本地文件修改）

• （可选）切换到待push分支，以main为例

Rebase方案

• Rebase如同字面意思，是将当前项目相对于上游旧基点所做的所有更改逐个重新应用到新的项目基点上，比如此处从“修复音乐组件”开始的修改commit实际早于“Merge pull request #3568”，现在将所有的修改全部移动到基于“#3568”这个位置重做所有修改。

• 选择基点进行rebase

• git会暂停rebase，需要自行重复以下步骤：

• 解决冲突，可以使用IDE可视化选择左右任一份或混合二者

• 添加修改文件（自行指定，一般在.gitignore写完筛出的文件后可以方便地使用.，应检查保证包含密钥等的环境文件均为灰色）

• 继续rebase

• 注意提交的目的分支是origin自己的分支，因为rebase打乱了原本的commit历史（比如在v1时做的更新commit，rebase后成了v4时做的更新commit），需要force提交，覆盖历史

Merge方案

• 使用merge，指明上游分支

• 解决冲突

• commit提交变更

• 正常push

git提交后发现有误的回退

revert方案

• 如果修改不是相邻的，而是隔了比较多的commits比较适合

• revert如同字面意义，可以理解为一次通常的commit，只不过这次commit的内容是反转以前的某次提交修改

• 如下为示例

• -n 表示no-commit，不用的话会直接commit，后接commit hash值

reset方案

• 适合直接丢弃最近的无效提交，回退到一个有意义的更新点

• reset也是字面意思，重置到对应的提交节点，之后的更新全部丢弃

• 参数接commit哈希值

合并master与github未合并的pr

pull方案

• pull可以理解为直接fetch后马上进行merge，二合一，除非明确只有追加新文件不然不推荐

• 先clone下来master分支

• git pull拉取的对应pr

• pull之后直接触发merge，填写merge的commit信息然后按照vim方式退出即可（a进入insert填写完信息后esc切回，：进入命令，输入wq回车保存退出即完成提交）

• 提交完成，可以看到左下的历史

fetch后merge方案

• 先把演示过pull的效果回退到pull之前

• 回到原本的状态

• git fetch，：后跟需要创建的分支名，拉取的内容会放在对应分支里，不影响当前分支

• git branch检查分支状况

• git checkout切换到作为合并后的分支（演示中目的为将主分支合并到pr-214上）

• git merge，填写commit信息提交完成合并

• 从更完整的历史可以看到主分支（jingyaogong）历史被合并进当前分支（mingkun）的历史

• 这样不会影响到原本的主分支使用，可以随时checkout回去

• 检查不会有notebook文件夹（pr分支内容）

• 切回pr-214，带有notebook文件夹