如果你不能很好的應用 Git,那么這里為你提供一個非常棒的 Git 在線練習工具 Git Online ,你可以更直觀的看到你所使用的命令會產(chǎn)生什么效果
另外,你在使用 Git 合并分支時只會使用 git merge
嗎?有時使用 git rebase
可以比 git merge
做出更優(yōu)雅的操作
不知怎么,git rebase
命令被賦予了一個神奇的污毒聲譽,初學者應該遠離它,但它實際上可以讓開發(fā)團隊在使用時更加輕松。
你可以將它理解成「七傷拳」,「七傷拳」并不是不能練,只是練「七傷拳」有一個先訣條件,那就是內(nèi)功境界一定要非常高,即你要充分理解
git rebase
命令
在本文中,我們將 git rebase
與 git merge
命令進行比較。在 Git 工作流中,說明所有可以使用 rebase 的場景
關于 git rebase
,首先要理解的是它解決了和 git merge
同樣的問題。這兩個命令都旨在將更改從一個分支合并到另一個分支,但二者的合并方式卻有很大的不同。
當你在專用分支上開發(fā)新 feature 時,然后另一個團隊成員在 master
分支提交了新的 commits,這會發(fā)生什么?這會導致分叉的歷史記錄,對于這個問題,使用 Git 作為協(xié)作工具的任何人來說都應該很熟悉。
現(xiàn)在,假設在 master
分支上的新提交與你正在開發(fā)的 feature 相關。需要將新提×××并到你的 feature
分支中,你可以有兩個選擇:merge 或者 rebase。
最簡單的方式是通過以下命令將 master
分支合并到 feature
分支中:
git checkout feature
git merge master
或者,你可以將其濃縮為一行命令:
git merge feature master
這會在 feature
分支中創(chuàng)建一個新的 merge commit,它將兩個分支的歷史聯(lián)系在一起,請看如下所示的分支結構:
使用 merge 是很好的方式,因為它是一種 非破壞性的 操作?,F(xiàn)有分支不會以任何方式被更改。這避免了 rebase 操作所產(chǎn)生的潛在缺陷(下面討論)。
另一方面,這也意味著 feature
分支每次需要合并上游更改時,它都將產(chǎn)生一個額外的合并提交。如果master
提交非?;钴S,這可能會嚴重污染你的 feature 分支歷史記錄。盡管可以使用高級選項 git log
緩解此問題,但它可能使其他開發(fā)人員難以理解項目的歷史記錄
作為 merge 的替代方法,你可以使用以下命令將 master
分支合并到 feature
分支上:
git checkout feature
git rebase master
這會將整個 feature
分支移動到 master
分支的頂端,從而有效地整合了所有 master
分支上的提交。但是,與 merge 提交方式不同,rebase 通過為原始分支中的每個提交創(chuàng)建全新的 commits 來 重寫 項目歷史記錄。
rebase 的主要好處是可以獲得更清晰的項目歷史。首先,它消除了 git merge
所需的不必要的合并提交;其次,正如你在上圖中所看到的,rebase 會產(chǎn)生完美線性的項目歷史記錄,你可以在 feature
分支上沒有任何分叉的情況下一直追尋到項目的初始提交。這樣可以通過命令 git log
,git bisect
和 gitk
更容易導航查看項目。
但是,針對這樣的提交歷史我們需要權衡其「安全性」和「可追溯性」。如果你不遵循 [Rebase 的黃金法則](## Rebase 的黃金法則),重寫項目歷史記錄可能會對你的協(xié)作工作流程造成災難性后果。而且,rebase 會丟失合并提交的上下文, 你也就無法看到上游更改是何時合并到 feature 中的。
交互式 rebase 使你有機會在將 commits 移動到新分支時更改這些 commits。這比自動 rebase 更強大,因為它提供了對分支提交歷史的完全控制。通常,這用于在合并 feature 分支到 master
之前清理其雜亂的歷史記錄。
要使用交互式 rebase,需要使用 git rebase
和 -i
選項:
git checkout feature
git rebase -i master
這將打開一個文本編輯器,列出即將移動的所有提交:
pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
此列表準確定義了執(zhí)行 rebase 后分支的外觀。通過更改 pick
命令或重新排序條目,你可以使分支的歷史記錄看起來像你想要的任何內(nèi)容。例如,如果第二次提交 fix 了第一次提交中的一個小問題,您可以使用以下 fixup
命令將它們濃縮為一個提交:
pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
保存并關閉文件時,Git將根據(jù)您的指示執(zhí)行 rebase,從而產(chǎn)生如下所示的項目歷史記錄:
消除這種無意義的提交使你的功能歷史更容易理解。這是 git merge
根本無法做到的事情。至于 commits 條目前的 pick
、fixup
、squash
等命令,在 git 目錄執(zhí)行 git rebase -i
即可查看到,大家按需重排或合并提交即可,注釋說明非常清晰,在此不做過多說明:
一旦你理解了什么是 rebase,最重要的是要學習什么時候不能使用它。git rebase
的黃金法則是永遠不要在公共分支上使用它。
例如,想想如果你 rebase master
分支到 feature
分支之上會發(fā)生什么:
rebase 將所有 master
分支上的提交移動 feature
分支的頂端。問題是這只發(fā)生在 你自己 的存儲庫中。所有其他開發(fā)人員仍在使用原始版本的 master
。由于 rebase 導致全新 commit,Git 會認為你的 master
分支歷史與其他人的歷史不同。
此時,同步兩個 master
分支的唯一方法是將它們合并在一起,但是這樣會產(chǎn)生額外的合并提交和兩組包含相同更改的提交(原始提交和通過 rebase 更改的分支提交)。不用說,這是一個令人非常困惑的情況。
因此,在你運行 git rebase
命令之前,總是問自己,還有其他人在用這個分支嗎? 如果答案是肯定的,那就把你的手從鍵盤上移開,開始考慮采用非破壞性的方式進行改變(例如,git revert
命令)。否則,你可以隨心所欲地重寫歷史記錄。
如果你嘗試將 rebase 了的 master
分支推送回 remote repository,Git 將阻止你這樣做,因為它會與遠程master
分支沖突。但是,你可以通過傳遞 --force
標志來強制推送,如下所示:
# Be very careful with this command!
git push --force
這樣你自己 repository 的內(nèi)容將覆蓋遠程 master
分支的內(nèi)容,但這會使團隊的其他成員感到困惑。因此,只有在確切知道自己在做什么時才要非常小心地使用此命令。
如果沒有人在 feature branch 上作出更改,你可以使用 force push 將本地內(nèi)容推送到 remote repository 做清理工作
rebase 可以根據(jù)你所在團隊的需要方便的整合到現(xiàn)有的 Git 工作流程中。在本節(jié)中,我們將了解 rebase 在功能開發(fā)的各個階段可以提供的好處。
在任何工作流程中,利用 git rebase
是為每個功能創(chuàng)建專用分支。這為你提供了必要的分支,以安全地利用 rebase:
將 rebase 納入工作流程的最佳方法之一是清理本地正在進行的功能。通過定期執(zhí)行交互式 rebase,你可以確保功能中的每個提交都具有針對性和意義。這可以使你在編寫代碼時無需擔心將其分解為隔離的提交(多個提交),你可以在事后修復整合它。
使用 git rebase
時,有兩種情況:feature 父分支(例如 master
)的提交,或在 feature 中的早期提交。我們在 交互式 Rebase 部分已經(jīng)介紹了第一種情況的示例。我們來看后一種情況,當你只需要修復最后幾次提交時,以下命令僅做最后 3 次提交的交互式 rebase。
git checkout feature
git rebase -i HEAD~3
通過指定 HEAD~3
,你實際上并沒有移動分支,你只是交互式地重寫其后的3個提交。請注意,這不會將上游更改合并到 feature
分支中。
如果要使用此方法重寫整個功能,git merge-base
命令可用于查找 feature
分支的原始 base。以下內(nèi)容返回原始 base 的提交ID,然后你可以將其傳遞給 git rebase
:
git merge-base feature master
交互式 rebase 的使用是引入git rebase
工作流的好方法,因為它只影響本地分支。其他開發(fā)人員唯一能看到的就是你提交的最終版,這應該是一個簡潔易懂易跟蹤的分支歷史記錄。
但同樣,這僅適用于 私有 feature分支。如果你通過相同的功能分支(公共分支)與其他開發(fā)人員協(xié)作,那么你是 不被允許 重寫其歷史記錄的。
在 概念概述 部分中,我們了解了 feature 分支可以使用 git merge
或 git rebase
合并 master 分支的上游更改 。merge 是一個安全的方式,可以保留存 git repository 的整個歷史記錄,而 rebase 則是通過將 feature 分支移動到 master
頂端來創(chuàng)建線性歷史記錄。
這種使用 git rebase
類似于本地清理,但在此過程中它包含了那些來自 master
上游提交。
請記住,將當前提交 rebase 到遠程 branch(非 master 分支)一樣是合法的。當與另一個開發(fā)人員協(xié)作使用相同的功能并且你需要將他們的更改合并到你的 repository 時,就會發(fā)生這種情況。
例如,如果你和另一個名為 John 的開發(fā)人員添加了對 feature
分支的提交,在你 fetch (注意 fetch 并不會自動 merge )來自 John 的遠程 feature
分支后,你的 repository 可能如下所示:
你可以整合上來自上游的分叉:要么用 john/feature
merge 本地 feature
,要么 rebase 本地feature
到john/feature
的頂部。
請注意,此 rebase 不違反 Rebase 黃金規(guī)則,因為只有你的本地 feature
提交被移動, 之前的所有內(nèi)容都不會受到影響。這就像是說 "將我的更改添加到 John 已經(jīng)完成的工作中"。在大多數(shù)情況下,這比通過合并提交與遠程分支同步更直觀。
默認情況下,使用 git pull
命令執(zhí)行合并,但你可以通過向其傳遞 --rebase
選項來強制它將遠程分支 以 rebase 方式集成。
git pull --rebase
如果你在代碼審查過程中使用 pull 請求,在使用了 pull 請求之后你應該避免使用 git rebase
。一旦你發(fā)出 pull 請求,其他開發(fā)人員就會查看你的提交,這意味著它是一個 公共 分支。重寫其歷史記錄將使 Git 和你的隊友無法跟蹤添加到該功能的任何后續(xù)提交。
其他開發(fā)人員的任何更改都需要合并 git merge
而不是 git rebase
。
因此,在提交拉取請求之前,通常使用交互式 rebase 清理代碼通常是個好的辦法。注意使用順序
在你的團隊批準某項 feature 后,你可以選擇將該功能 rebase 到 master
分支的頂端,然后git merge
再將該功能集成到主代碼庫中。
這與將上游更改合并到 feature 分支中的情況類似,但由于你不允許在 master
分支中重寫提交,因此你必須最終使用 git merge
該功能進行集成。但是,通過在 merge 之前執(zhí)行 rebase,你可以確保會以 fast-forward 方式 merge,從而產(chǎn)生完美的線性歷史記錄。
如果您不熟悉 git rebase
,可以隨時在臨時分支中執(zhí)行 rebase。這樣,如果你不小心弄亂了功能的歷史記錄,可以查看原始分支,然后重試。例如:
git checkout feature
git checkout -b temporary-branch
git rebase -i master
# [Clean up the history]
git checkout master
git merge temporary-branch
如果你更喜歡沒有不必要的干凈的合并提交,線性歷史記錄,你就需要開始了解使用 rebase 功能。同時你應該會使用 git rebase
而不是 git merge
集成來自另一個分支的更改。
另一方面,如果你想保留項目的完整歷史記錄并避免重寫公共提交的風險,你可以堅持下去git merge
。這兩種選擇都是完全有效的,但至少現(xiàn)在你可以選擇利用 git rebase
的好處 。
git rebase
嗎?這樣清晰的線形歷史是不是可以嘗試一下呢?git pull -rebase
?帶著疑問去思考,然后串聯(lián),進而歸納總結,不斷追問自己,進行自我辯證,像偵查嫌疑案件一樣看待技術問題,漆黑的街道,你我一起尋找線索,你就是技術界大偵探福爾摩斯
輕松高效玩轉(zhuǎn)DTO(Data Transfer Object)
歡迎持續(xù)關注公眾號:「日拱一兵」
- 前沿 Java 技術干貨分享
- 高效工具匯總
- 面試問題分析與解答
- 技術資料領取
持續(xù)關注,帶你像讀偵探小說一樣輕松趣味學習 Java 技術棧相關知識
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn,海內(nèi)外云服務器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應用場景需求。
本文標題:gitrebaseVSgitmerge?更優(yōu)雅的git合并方式值得擁有-創(chuàng)新互聯(lián)
網(wǎng)頁路徑:http://m.rwnh.cn/article20/djhjjo.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供搜索引擎優(yōu)化、網(wǎng)站收錄、企業(yè)網(wǎng)站制作、靜態(tài)網(wǎng)站、微信小程序、軟件開發(fā)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容