摘要:合并到多個目標分支或其他人正在使用當前分支這是應該使用因為你執行時當前分支原先的會被刪除會影響他人,形成新的連接在目標分支最新之后。
閱讀原文:合并分支使用Merge還是Rebase?
作為一個有追求的開發者,我一定會選擇更好的版本管理工具(Git), 使用中我們難免會在 Merge 和 Rebase 中選擇其一用于合并分支。
Rebase 和 merge 都是被設計用于集成你所做的改變從一個分支到另一個分支,只是通過不同的方式。雖然目的相同,但不同的方式有不同的優缺點。
區別例如:我們有下面的幾個commit,merge會將一些commit的組合作為一個結果,而rebase會將所有commit添加到目標分支的最近一次提交之后。
通過上圖我們可以看到,merge 會存在合并的歷史記錄,而rebase沒有了歷史記錄且成一條直線。
Merge簡單易理解
源分支和目標分支相互分離
保留功能分支的提交歷史和分支圖形
分支一旦較多顯示比較混亂
Rebase簡化復雜的記錄且線性可讀
沒有合并的記錄
多個commit沖突時必須一個個提交去修改
對遠程分支rebase需要force push
什么時候使用rebase?什么時候使用merge ?獨立開發
如果你不是團隊合作開發,那么你可以優先選擇使用rebase來保持你整潔的提交歷史。
準備code review
你需要在合并的時候有人來給你review,此時你需要提交一個 merge/pull request,此時別人可review你的代碼后會執行merge,這將保存你此次的請求合并的記錄,已備將來追溯。
合并到多個目標分支或其他人正在使用當前分支
這是應該使用merge,因為你執行rebase時,當前分支原先的commit會被刪除(會影響他人),形成新的commit連接在目標分支最新commit之后。所以在這個條件不成立的時候你可以使用rebase來合并分支。
推薦在不符合上面第三點時(合并到多個目標分支或其他人正在使用當前分支),個人分支(feature/bugfix/……)中使用rebase來更新主分支(個人分支的來源)上的變動,確保當前分支是最新的,然后提交merge/pull request,由其他人來負責對你的代碼進行review并確定是否通過請求,這樣可以看到每個人開發合并的歷史記錄。
不知道你是如何的呢?
往期文章一覽把「策略模式」應用到實際項目中
造個輪子,我學到了什么
技術面試中的軟技能
不同時重寫equals和hashCode又怎樣!
關注微信公眾號「碼上實戰」 回復 :面試視頻 和 架構師 送你非常不錯的資料。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/74555.html
摘要:請注意,此不違反黃金規則,因為只有你的本地提交被移動,之前的所有內容都不會受到影響。在大多數情況下,這比通過合并提交與遠程分支同步更直觀。 寫在前面 如果你不能很好的應用 Git,那么這里為你提供一個非常棒的 Git 在線練習工具 Git Online ,你可以更直觀的看到你所使用的命令會產生什么效果showImg(https://segmentfault.com/img/remote...
摘要:分支的創建合并與刪除創建分支與切換分支或者命令加上參數表示創建并切換。或者后面不跟分支名時指列出所有分支,當前分支前面加。刪除分支刪除本地分支,不能在當前分支執行刪除當前分支的操作。 分支的創建、合并與刪除 創建分支與切換分支 $ git branch develop$ git checkout develop 或者 $ git checkout -b develop git che...
摘要:背景背景大家都有學習如何規范簡潔的編寫代碼,但卻很少學習如何規范簡潔的提交代碼。背景 大家都有學習如何規范簡潔的編寫代碼,但卻很少學習如何規范簡潔的提交代碼。現在大家基本上都用 Git 作為源碼管理的工具,Git 提供了極大的靈活性,我們按照各種 workflow 來提交/合并 code,這種靈活性把控不好,也會帶來很多問題 最常見的問題就是亂成一團的 git log histo...
閱讀 2872·2021-08-20 09:37
閱讀 1612·2019-08-30 12:47
閱讀 1095·2019-08-29 13:27
閱讀 1691·2019-08-28 18:02
閱讀 754·2019-08-23 18:15
閱讀 3090·2019-08-23 16:51
閱讀 935·2019-08-23 14:13
閱讀 2137·2019-08-23 13:05