1. 程式人生 > 其它 >crontab 日誌_計劃任務 cron和crontab

crontab 日誌_計劃任務 cron和crontab

技術標籤:gitgit

原連結:https://www.jianshu.com/p/ff1877c5864e


git merge的三種操作merge, squash merge, 和rebase merge

舉例來說:
假設在master分支的B點拉出一個新的分支dev,經過一段時間開發後:

  • master分支上有兩個新的提交M1和M2
  • dev分支上有三個提交D1,D2,和D3

如下圖所示:

image.png

現在我們完成了dev分支的開發測試工作,需要把dev分支合併回master分支。

  1. merge

這是最基本的merge,就是把提交歷史原封不動的拷貝過來,包含完整的提交歷史記錄。

$ git checkout master
$ git merge dev

image.png

此時還會生產一個merge commit (D4'),這個merge commit不包含任何程式碼改動,而包含在dev分支上的幾個commit列表(D1, D2和D3)。檢視git的提交歷史(git log)可以看到所有的這些提交歷史記錄。

  1. squash merge:

根據字面意思,這個操作完成的是壓縮的提交;解決的是什麼問題呢,由於在dev分支上執行的是開發工作,有一些很小的提交,或者是糾正前面的錯誤的提交,對於這類提交對整個工程來說不需要單獨顯示出來一次提交,不然導致專案的提交歷史過於複雜;所以基於這種原因,我們可以把dev上的所有提交都合併成一個提交;然後提交到主幹。

$ git checkout master
$ git merge --squash dev

image.png

在這個例子中,我們把D1,D2和D3的改動合併成了一個D。

注意,squash merge並不會替你產生提交,它只是把所有的改動合併,然後放在本地檔案,需要你再次手動執行git commit操作;此時又要注意了,因為你要你手動commit,也就是說這個commit是你產生的,不是有原來dev分支上的開發人員產生的,提交者本身發生了變化。也可以這麼理解,就是你把dev分支上的所有程式碼改動一次性porting到master分支上而已。

  1. rebase merge

由於squash merge會變更提交者作者資訊,這是一個很大的問題,後期問題追溯不好處理(當然也可以由分支dev的所有者來執行squash merge操作,以解決部分問題),rebase merge可以保留提交的作者資訊,同時可以合併commit歷史,完美的解決了上面的問題。

$ git checkout dev
$ git rebase -i master
$ git checkout master
$ git merge dev

rebase merge分兩步完成:
第一步:執行rebase操作,結果是看起來dev分支是從M2拉出來的,而不是從B拉出來的,然後使用-i引數手動調整commit歷史,是否合併如何合併。例如下rebase -i命令會彈出文字編輯框:

pick <D1> Message for commit #1
pick <D2> Message for commit #2
pick <D3> Message for commit #3

假設D2是對D1的一個拼寫錯誤修正,因此可以不需要顯式的指出來,我們把D2修改為fixup:

pick <D1> Message for commit #1
fixup <D2> Message for commit #2
pick <D3> Message for commit #3

rebase之後的狀態變為:

image.png

D1'是D1和D2的合併。

第二步:再執行merge操作,把dev分支合併到master分支:

image.png

注意:在執行rebase的時候可能會出現衝突的問題,此時需要手工解決衝突的問題,然後執行(git add)命令;所有衝突解決完之後,這時不需要執行(git commit)命令,而是執行(git rebase --continue)命令,一直到rebase完成;如果中途想放棄rebase操作,可以執行(git rebase --abort)命令回到rebase之前的狀態。