git分支的衍合
?
把一個分支中的修改整合到另一個分支的辦法有兩種:merge和rebase,
當開發進程分叉到兩個不同的分支,又各自提交了更新。
最容易的整合分支的方法是merge, 它會把兩個分支最新的快照以及兩者的共同祖先進行三方合并,合并的結果是產生一個新的提交對象。
其實還有另外一個選擇,可以在一個分支里發生的變化補丁在另一個分支重新打一遍,這種操作叫做衍合,
rebase的作用就是把在一個分支里提交的改變放到另一個分支里重放一遍。
$ git checkout experiment $ git rebase master它的原理是回到兩個分支最近的共同祖先,根據當前分支(也就是要進行衍合的分支experiment)后續的歷次提交對象,生成一系列文件補丁,然后以基線分支(也就是主干分支master)最后一個提交對象為新的出發點,逐個應用之前準備好的補丁文件,最后會生成一個新的合并提交對象,從而改寫experiment的提交歷史,使它成為master分支的直接下游。
?
衍合最后生成的快照,其實和普通的三方合并的快照內容一模一樣。雖然最后整合得到的結果沒有任何區別,
但是衍合能產生一個更為整潔的提交歷史。如果觀察一個衍合過的分支的歷史記錄,看起來會更清楚:仿佛所有修改都是在一跟線上先后進行的,盡管實際上他們原本是同時并行發生的。
一般我們使用衍合的目的,是想要得到一個能在遠程分支上干凈應用的補丁,比如某些項目你不是維護者,但是想幫點忙的話,最好使用衍合:先在自己的一個分支里進行開發,當準備向主項目提交補丁的時候,根據最新的origin/master進行一次衍合操作然后再提交,這樣維護者就不需要做任何工作(實際上是把解決分支補丁同最新主干代碼之間沖突的責任,轉化為由提交補丁的人來解決),維護者只需要根據你提供的倉庫地址進行一次快進合并,或者直接采納你提交的補丁。
======== 衍合的風險=========
一旦分支的提交對象發布到公共倉庫,就千萬不要對該分支進行衍合操作。
進行衍合的時候,實際上拋棄了一些顯存的提交對象而創造了一些類似但不同的新的提交對象,
如果你把原來分支中的提交對象發布出去,并且其他人更新下載后在其基礎上開展工作,而稍后你又用git rebase
拋棄這些提交對象,把新的重演后的提交對象發布出去的話,你的合作者就不得不重新合并他們的工作,這樣當你再次從他們那里獲取內容的時候,提交歷史就會變得一團糟。
?https://git-scm.com/book/zh/v1/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E8%A1%8D%E5%90%88
?
/workspace/xxx-xx-cms:the-channel-sort$ git push origin the-channel-sort To git@bitbucket.org:xxx-xxx-cms/xxx-xx-cms.git! [rejected] the-channel-sort -> the-channel-sort (non-fast-forward) error: failed to push some refs to 'git@bitbucket.org:xxx-xxx-cms/xxx-xx-cms.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. /workspace/xxx-xx-cms:the-channel-sort$ git fetch remote: Counting objects: 13, done. remote: Compressing objects: 100% (13/13), done. remote: Total 13 (delta 9), reused 0 (delta 0) Unpacking objects: 100% (13/13), done. From bitbucket.org:xxx-xxx-xxx/xxx-xx-cms* [new branch] production-deployment -> origin/production-deployment* [new branch] staging -> origin/staging /workspace/xxx-xx-cms:the-channel-sort$ git rebase origin/the-channel-sort First, rewinding head to replay your work on top of it... Applying: 重構代碼 /workspace/xxx-xx-cms:the-channel-sort$ gitg /workspace/xxx-xx-cms:the-channel-sort$ git push Counting objects: 35, done. Delta compression using up to 4 threads. Compressing objects: 100% (18/18), done. Writing objects: 100% (18/18), 2.29 KiB, done. Total 18 (delta 14), reused 0 (delta 0) remote: remote: View pull request for the-channel-sort => master: remote: https://bitbucket.org/xxx-xxx-cms/xxx-xx-cms/pull-requests/21?t=1 remote: To git@bitbucket.org:xxx-xxx-cms/xxx-xx-cms.git841dda2..95cdf0d the-channel-sort -> the-channel-sort?
轉載于:https://www.cnblogs.com/iwangzheng/p/4691779.html
總結
- 上一篇: Java排序算法之——希尔排序
- 下一篇: linux中offsetof与conta