幾個讓你對Git頓悟的例子

在gitlab QQ群,時常見到的問題就是git初學者以SVN為基準來問問題,為什麼git不支持XXX,svn都支持了。這個功能git應該怎麼做?而最基本的git命令都懶得看。每當這時候,蟲蟲都會很不耐煩好氣地告訴他:"直接用SVN好了,git不支持"。很多人來git只是為了因為git流行熱門,或者他的領導讓他來用git。他自己對git知之甚少,他最常做的事情就是要給領導出一個實時備份、高可用的gitlab架構等問題。

關於git基礎相關,蟲蟲也寫了《Git初步,理清基本的git(github)流程》,《git分支概念和分支相關操作》,《Git鮮為人知的四個命令:bisect,blame,reflog和提交範圍》等文章,大家可以參考閱讀。本文蟲蟲以六個例子,讓你頓悟,說明下git的真正的做事的方式—— "Thinking in Git",糾正一下長期svn使用後遺留下的思維方式,和git完全不一樣的方式。

1. 本地和遠程倉更改不需要有關係。

幾個讓你對Git頓悟的例子

在使用svn的時候,很多人習慣使用"svn status -u"來查看如果我運行svn update會發生什麼變化。很多人以為git也是這樣,想知道git中對應的操作。你告訴他使用"git status" 。這個命令會列出,你最近一次Pull操作之後本地的變化。要查看服務器上的更改,我們首先需要執行"git fetch"。

對git來說本地倉和遠程倉實際上是兩套獨立變化的,本地變化和服務器上的變化(可以被其他人push變化),要分開看,你無需考慮太多他們之間的差異,你只需Pull合併遠方變化,並把本地變化push就ok。

2.合併版本是讓老的commit可用。

幾個讓你對Git頓悟的例子

我們這兒說合並只是讓某些代碼變化(commit)可用。很多人認為,合併不過是把分支的變動變為主分支的commit,這個認識是片面的有問題的,實際上合併是讓某分支的commit被其分支可見(用)。例如,通過git log查看一個文件的變化,可以顯示交錯的兩個不同分支的提交,兩個提交之間的差異(時間上相鄰,但在兩個不同的分支上),可能變化非常大。

3.合併提交的含義

對於初學者git合併可能很難理解,他們時常關注到合併的細枝末節,比如為什麼要三方合併?。在理解git合併時候不能用 "這個commit文件變化差異",從文件差異,代碼變化來看,合併提交併沒有任何的變化。而要記住git合併提交是為了獲得其他分支提交的內容,這些內容(分支commit)是通過合併來變得可讀(用)。

4.合併是雙向的

如果有一個長期運行的分支Dev,你最終會想將它合併到master中,則你可以通過定期將master合併到Dev中(並修復其中的衝突)來一次解決合併衝突問題。最終目的是將Dev中的所有更改合併到master中,但這隻能在Dev按預期完成時才行。如果一直獨立Dev分支的話,可能會導致其嚴重落後於主分支,這樣最終合併時候將會是個噩夢。由於合併是雙向的,我們不必等到Dev完成之後才最終合併。而通過定期將master合併到Dev,這樣最終從Dev併到主分支時,衝突已經沒有多少了。

5.如果合併失敗,你可以重新開始。

幾個讓你對Git頓悟的例子

在svn中,很多人經常要使用"-dry-run"來查看執行某個操作會發生什麼(但實際上沒有這樣做)。在git中,所以轉到git後他們也想要git也這樣做,但是我告訴他們這實際一點意義都沒有,git也沒有這樣的操作。但是git特性,使得所有操作根本無需考慮後果,反正總能找回來。例如,要合併了一些更改,但是合併時你搞亂了,怎麼辦?No problem!,reset反悔一下就行。執行"

git reset -hard HEAD~",就反悔了。現在你可以繼續合併,你可以這樣隨便做,就像vim中的對編輯redo一樣,無任何限制,直到你搞好,期間你不怕搞亂,不怕搞錯。

6.提交的更改可以重新設置為本地更改。

有時候我們正在一個分支做修改(比如Temp分支),但是需要跳轉到另一個分支並對其做修改。有些人習慣於用stash暫存當前變化。但是更好的做法是提交一個commit,並註明其代碼狀態。只是,不要將其push到遠程倉。當我們回到分支Temp時,只需"git reset HEAD ~"來重新獲到之前提交的變化,這樣我們就能迅速的回到之前的工作狀態(代碼行)。

Think in Git

幾個讓你對Git頓悟的例子

不管理你閱讀了多少git使用的教程,以及如何組織git方法。但是如果你不能迅速轉化到git 思維方式的話,那你永遠體會不到git真正的好處在哪裡,也不能讓git的這些優勢給你帶來生產力的提高。我還是我在群裡給新手建議的觀點,如果你不能做到"Think in git"的話,一定不要與svn做對比,按照svn思維的話,那你還是用svn好了!如果你的領導不能理解"Think in git",你也不要給他推薦git,因為他會給你提出很多svn思維式的,你用git更本無法滿足的問題。(實際上git中根本不用考慮這些問題,所以也就不必要滿足)。

在本文中蟲蟲舉了幾個例子幫你頓悟git,think in git,我堅信git可以給代理生產力的飛速提高,但是首先你要"Think in git"。


分享到:


相關文章: