拉取远程更新同步本地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文件夹

主分支做了变更，希望将变更移动到新分支中，主分支维持稳定版本不动

• 比如此处已经在master分支上做了修改，但考虑现有修改不一定保留（比如网络创新效果有可能比之前的差，需要保留一个稳定版本）

• 可以先打tag标记重要版本（仅标记已经提交的版本），此处标记目前实现的四个创新点

• git checkout -b 新分支（-b创建新分支）

• 在新分支：
• git add .
• git commit -m

• 可以给新的打个tag

• 重新切回master，原本的变更自动复原（提交在了新分支上）

• 如果是已经commit的情景，可以git checkout -b，git checkout回来，git reset

• tag便于后续reset与checkout使用（在旧版上开新分支/查看旧版（不使用-b），重置reset到旧进度）