骚年，听说你写代码从来不用 git rebase [视频]
git rebase 介绍
git 是一个强大、复杂同时也是一个危险的工具，如果你使用不当可能会有灾难事件。 学 git 很长的一段时间，我都从来没有用过 git rebase 命令，工作之后基本公司也都没有制定 git 工作流，所以也都是按照自己喜好来。直到最近有团队才开始总结 git 工作流文档供大家参考实践。
合并分之通常有两种选择，直接使用 git merge 或者 git rebase 后再合并。 直接 git merge 有一个缺点就是每次合并上游更改时 feature 分支都会引入一个外来的合并提交，导致提交历史分叉。 使用 git rebase 可以解决这个问题，当然 git rebase 也有危险之处，不过只要遵循『rebase 黄金法则』一般不会有危险。 视频中会演示下 git merge 和 git rebase 的区别，以及使用 git rebase 的场景（命令行和互动式）。
如果你想把 rebase 之后的 master 分支推送到远程仓库，Git 会阻止你这么做，因为两个分支包含冲突。但你可以传入 --force 标记来强行推送。
# 小心使用这个命令！
git push --force
它会重写远程的 master 分支来匹配你仓库中 rebase 之后的 master 分支，对于团队中其他成员来说这看上去很诡异。所以，务必小心这个命令，只有当你知道你在做什么的时候再使用。 不过因为我们的开发流程是你必须先 fork 到你自己的仓库，在你自己仓库的分支上开发之后提一个 MR (Merge Request)合并到主仓库，所以一般没有危险。
一个简单的工作流程
简单地说我个人习惯这种方式（可能有些地方不合理，欢迎指正）:
# 假设主仓库地址是 https://github.com/zhihu/test_git
# 先 fork 一份到你自己的仓库，然后 clone 到本地
git clone https://github.com/PegasusWang/test_git
然后修改 git 配置文件，vim .git/config ，增加远程主仓库的配置。
[remote "origin"]
url = [email protected]:PegasusWang/test_git.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "zhihu"]
url = [email protected]:zhihu/test_git.git
fetch = +refs/heads/*:refs/remotes/origin/*
这样我就可以直接用 git pull zhihu master 来拉取 zhihu 的代码并且让我的 master 始终和 zhihu master 一致。
git 提倡多用分之，开发的时候你可以根据 bug fix 或者 new feature 前缀命名分之。
# 新建分之并切过去开搞(一般我在 zsh 里映射了很多 git 快捷命令)
git checkout -b bugfix
# ... 在你搞完了之后执行 add 和 commit （当然中间可以用 rabase -i 合并一些无用提交信息）
git add .
git commit -m "fix a bug balabala"
注意这个时候可能有其他人已经把它的代码合并到了 zhihu 的 master 上了，你本地的 master 已经落后了。这个时候可以用 git rebase 了。
git checkout master # 切换自己的 master
git pull zhihu master # 拉取 zhihu 主仓库 master 保持本地 master 最新
git checkout bugfix
git rebase master # 切到刚才的分支并且 rebase master。中间有冲突解决后 git add add 然后 git rebase --contiune
# 这个时候就可以提个 MR 了。 上边也可以用 git pull --rebase zhihu master 来简化，一般我都是用 git 简化命令，操作起来很快
Rebase 黄金法则
最后必须要提到一条 rebase 黄金法则：绝不要在公共的分支上使用它。 git rebase 会重写历史，一定只能在你自己的分支上使用它, 否则你的队友们可能会暴打你一顿。
参考
Why you should stop using Git rebase
代码合并：Merge、Rebase 的选择
猴子都能懂的 GIT 入门 - 用 rebase 合并
推荐阅读：
