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 的場景(命令行和互動式)。

視頻封面

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 合併

推薦閱讀:

相关文章