大致记录一下
- 一般 不管是 rebase 还是 merge 都需要先 把 master 本地的和远端同步一下，如果你没有操作篡改 master代码，只需要git checkout master 并做git pull 然后再checkout 你的分支上
- Rebase 一般在你的现有分支上操作，比如 muller_dev,不要在master 上操作
- git rebase 分支 是为了向 master 提 merge request 做准备
- git rebase 分支是为了方便merge request 的审核人 更清晰查看从上一次merge request到这一次merge request的代码更改全量，两次merge request 间隔 肯定会有多次commit ，如果不rebase 的话，审核人只能看到最近一次commit的更改 ，而无法查看全部更改
- git rebase -i HEAD~N N 的数字必须是明确的，不可以多，否则会出问题
- git rebase -I HEAD~n 把之前的多次commit 合并成一次 commit ，是会有一次新的commit在本地，需要 在 force push 更新到远端 git push -f origin muller_dev ,force push尽量不要出现在master上
- git rebase 作为一次新的commit 你可以书写新的 commit message ，在你 操作完 pick 修改为s 后 出现的交互shell中 ，git rebase 其实主要是把之前的commit 从pick 状态修改为squash ，squash 本意是压扁 拉平，相当于 flatten，等于把要 squash的commit，算作没有被修改 还是pick 状态的commit了
- 通过git log 查看到底你需要squash 多少个commit
- 如果你 rebase 不小心 污染了这个分支的代码 但是还没有push，可以使用 git rebase --abort 丢弃上次的rebase，当然 如果你是 git merge master 污染了 这个分支，使用git merge --abort 或者 删除本地这个分支 git branch -D muller_dev,然后再从远端拉取这个分支下来 git fetch origin muller_dev
- 在你 git rebase -i HEAD~N 你的本地分支时 ，一般需要先 git rebase master ,把已经和远端同步过的本地master 衍合到这个当前本地分支，这样 操作 是为了master更干净整洁 ，如果合并master有冲突，那这个冲突就在你的这个本地分支解决就可以了，然后再更新到远端的这个分支作为merge request 的源，防止master在解决冲突后导致另外的分支出现更多的冲突，保证master 只有code reviewer 有权限merge ，无人篡改，切记 一定要把本地的master 先与远端的master 同步更新了！！！
- 所以一般在 做 merge request 时你的必要操作流程，大概是这样的
git checkout mastergit pullgit checkout muller_dev
git rebase master
git log /status
git rebase -i HEAD~n —>pick—>s[squash]
git push -f origin muller_dev
# Create merger reqeust from muller_Dev to master
# code reviewer check
