github: reset 与 rebase, pull 与 fetch 的区别

reset 与 rebase

完全不同的两个命令.reset的意思是回退你的代码到某一个具体的版本，rebase是指回退你个commit到某一次commit. git-reset 会修改 .git/refs 目录和 .git/index 文件. 但它不会修改任何和你的 commit 相关的东西. git-rebase 则会试图去修改你已经 commit 的东西, 比如想要覆盖你的 commit 历史之类的. 但是千万不要用 rebase 来修改已经 push 过的内容, 否则可能导致 rebase 修改过的内容和原先的内容完全不兼容, 然后影响到别人的代码.

也就是说你可以用这个工具: interactive rebasing. 在终端输入 git rebase -i 262d1f7看到输出如下:

pick 262d1f7 Added HTML header (v1)
pick a006669 Oops, we didn't want this commit
pick a6faf60 Revert "Oops, we didn't want this commit"
pick b7b5fce This reverts commit a6faf60631b5fbc6ee79b52a1bdac4c971b69ef8.
pick cdb39b0 Commit p tags with text (v1.1)
pick 9b2f3ce Added an author comment
pick 55649c3 Add an author/email comment
pick 0b1dd4c Moved hello.html to lib
pick 5854339 Added index.html
pick 801e13e Added README
pick a6792e4 Added css stylesheet
pick 17a64df Hello uses style.css (HEAD, origin/style, master),

这样你不想要的 commit 就被删掉了. 但是如果你已经 push 过这些 commit, 那就不要再跑 rebase 了. 其实有这些行在 commit 记录里面也无所谓.

rebase 还有一个功能是解决内容冲突的. 就是说你当前的 working directory 里面的内容它不是最新的, 有人修改了一个文件, 放到 remote 上面去, 好死不死的你也改了这个文件的同一个地方. 这时候你发现有个 pull 更新, 你要从 remote 上面把这个更新 pull 下来. 那 pull 是有自动 merge 的功能的, 问题在于现在 merge 是肯定要失败的, 因为别人和你修改了同一个文件的同一块代码. 这时候, 你需要把自己的 working directory rebase 到服务器上的最新版本, 然后修改冲突, 再把你自己的修改 push 上去. 

从日常的用法来说呢， 如果你碰到了某个 PROD issue， 这个 issue 很可能只有 PROD 那个版本有， 那么你想退回到那个版本，你就用reset命令来做。他会回退你的本地代码到某一个指定的版本，但是你的commit历史完全不会被影响的。

那另外一种情况就是，你从master签出了一个branch， 然后自己很开心的在那修改。这时候别的人会把他的修改merge到master里面啊，那意味着你现在这个branch的版本后落后于master，这时候你肯定不想重新从master签出一个branch进行开发吧，你更愿意把自己的branch刷新到master的最新版本上去，这时候就可以用rebase命令来做了。

pull 与 fetch

简单说来, git pull = git fetch + git merge. 事实上, git pull 是 git fetch; git merge FETCH_HEAD 两个命令合并后的简写方式, 类似语法糖的东西.

你可以在任意时刻用 git fetch 更新对于服务器上的分支的版本的跟踪信息: .git/refs/remotes/<remote>/. 它不会修改你本地的任何分支的内容refs/heads, 所以也不会改动你 working directory 里面的东西. 

git pull 会更新你本地代码到服务器上对应分支的最新版本, 当然也会更新跟踪信息: .git/refs/remotes/<remote>/.

Git 文档: git pull