原創(chuàng)2017-07-24Martin HellerCocoa開發(fā)者社區(qū)

Git不僅是編程世界最流行的分布式版本控制系統(tǒng)，而且你還可以用它查找，分享以及優(yōu)化你的代碼。接下來就來看看怎樣讓Git和GitHub更好地為你服務(wù)吧。

盡管現(xiàn)在網(wǎng)上有很多Git的初學(xué)者教程，而且GitHub自己也提供相當(dāng)一部分教程，但是要找到有效提高開發(fā)者使用Git和GitHub使用效率的技巧還是不太容易的，所以我們就來教大家一些方法吧。

對(duì)Git或者GitHub不熟悉的人來說，接下來的幾段話會(huì)提供充分的背景知識(shí)使得您更好地理解使用技巧。在文章結(jié)尾我們會(huì)列出一些實(shí)用的資源。

Git是一個(gè)分布式版本控制系統(tǒng)，它由Linus Torvalds2005年在Linux內(nèi)核社區(qū)的幫助下創(chuàng)作完成。我并不是要向你吹噓Git，所以我就不向你不拉不拉它到底有多快多輕便多靈活多受歡迎了，但是，當(dāng)你復(fù)制Git儲(chǔ)存庫(kù)時(shí)，你應(yīng)該知道這些，你可以在本地電腦上獲得完整的歷史版本，而不是一次一個(gè)分支的快照。

Git起初是作為命令行使工具，為它的東家Linux內(nèi)核社區(qū)服務(wù)。你仍然可以使用Git 命令行，但這并不是必要的。特別是，如果你使用GitHub作為你的主機(jī)，你就可以在Windows 或者 Mac系統(tǒng)中免費(fèi)使用GitHub客戶端。從另一個(gè)角度看，Git命令行在任何主機(jī)上都適用，而且它在大多數(shù)Mac和Linux系統(tǒng)中都是預(yù)裝的。

只有你能決定命令行和具有圖形用戶界面（GUI）的原生客戶端到底哪個(gè)更好用。如果除了GitHub客戶端（Windows和Mac系統(tǒng)），你還喜歡GUI，你可以考慮看看SourceTree(Windows和Mac系統(tǒng)，免費(fèi))，TortoiseGit(Windows系統(tǒng)，免費(fèi))，以及Gitbox(Mac系統(tǒng), $14.99)?；蛘吣憧梢杂靡粋€(gè)支持內(nèi)部使用Git的編輯器或者IDE=（參見技巧11）。

Git/GitHub 小技巧1: 復(fù)制幾乎所有內(nèi)容

現(xiàn)在在GitHub以及其他開源的Git庫(kù)上都有很多有意思的項(xiàng)目是可以免費(fèi)復(fù)制到你的電腦上的。而你又為什么會(huì)想要這么做呢？原因之一是想學(xué)學(xué)別人的代碼風(fēng)格、實(shí)踐、以及感興趣的編碼語言工具，還包括提交日志評(píng)論的風(fēng)格吧（詳情看技巧4）。原因之二可能是想看看一個(gè)給定的項(xiàng)目是如何最終達(dá)到它的目標(biāo)的吧。原因之三，既然證書允許你這樣做并且這樣做對(duì)實(shí)現(xiàn)你的目標(biāo)是非常有意義的，那么把這些項(xiàng)目納入你的努力和產(chǎn)品之中也是非常合理的。順便多看一遍許可證，以防將來出現(xiàn)合法性問題的爭(zhēng)論。

手冊(cè)頁的git clone 定義：

復(fù)制一個(gè)庫(kù)到一個(gè)新建的目錄下，在復(fù)制的庫(kù)中為每一個(gè)分支創(chuàng)建一個(gè)遠(yuǎn)程跟蹤分支（可視化使用git branch），然后創(chuàng)建并檢查從復(fù)制庫(kù)中當(dāng)前激活的分支派生出的初始分支。

在復(fù)制之后，一個(gè)沒有獲取參數(shù)的 git fetch將更新所有遠(yuǎn)程跟蹤分支，此外 git pull還將把遠(yuǎn)程主分支合并到現(xiàn)有的主分支。

Git/GitHub 小技巧2: 盡量頻繁拖拽

用Git把自己弄得一團(tuán)糟的最簡(jiǎn)單的方法之一（在其他版本控制系統(tǒng)也適用）就是允許文件不同步。如果你經(jīng)常在git中進(jìn)行拖拽，你復(fù)制的庫(kù)的版本將會(huì)保持最新，由于合并很好理解和達(dá)成，所以你有機(jī)會(huì)將你改動(dòng)的代碼和其他人的改動(dòng)合并在一起，當(dāng)然最理想的是它能夠簡(jiǎn)單到可以自動(dòng)完成合并。要使用此技巧的話你就必須時(shí)刻監(jiān)視你的項(xiàng)目狀態(tài)。許多Git客戶端會(huì)自動(dòng)提示你需要更新以保持最新。

Git/GitHub小技巧3: 盡量提交得又快又頻繁

每次提交都是對(duì)項(xiàng)目的粒度更新，它包括一個(gè)或多個(gè)文件的改動(dòng)。把它看成是對(duì)已完成的工作的單位記錄，可以作為一個(gè)邏輯整體應(yīng)用到項(xiàng)目中或從項(xiàng)目移除。即使是在測(cè)試之前也要記得提交你完成的每次邏輯變動(dòng)。你的每次提交都只適用于本地儲(chǔ)存庫(kù)。參見技巧4和5對(duì)本技巧的推論。

手冊(cè)頁對(duì) git commit的定義：

在一次新的提交中儲(chǔ)存當(dāng)前的指數(shù)內(nèi)容并提交用戶描述改變的日志消息。

Git/GitHub 小技巧4:像要求別人的提交描述一樣要求你自己的

世界上有10種程序員：描述他們的提交的，還有不描述提交的。（呵呵，老笑話啦。提示：我用的基數(shù)是什么？）

我承認(rèn)我非常堅(jiān)持提交日志消息是很好的習(xí)慣。我把我的儲(chǔ)存庫(kù)設(shè)置成每次都需要提交日志消息，而且我是出了名地愛發(fā)送煩人的深夜消息，尤其是當(dāng)我以XX的順序提交日志的時(shí)候。如果你是這種堅(jiān)持認(rèn)為（1）代碼應(yīng)該“為自己代言”（2）在線注釋遠(yuǎn)比改變?nèi)罩局匾拈_發(fā)者，請(qǐng)?jiān)囋噺?fù)制一個(gè)你以前從來沒見過的儲(chǔ)存庫(kù)，并分辨在沒有閱讀所有代碼之前可能產(chǎn)生最新問題的最新提交。所以你可以看到，精確的提交日志簡(jiǎn)直是雙倍的好啊。

Git/GitHub 小技巧 5:當(dāng)你的改變被測(cè)試時(shí)進(jìn)行推送

我知道的最近發(fā)生的Git相關(guān)bug的大悲劇就是一個(gè)外包公司從Subversion切換出來的時(shí)候，他們的開發(fā)者并沒有被訓(xùn)練過如何分辨分布式源代碼控制和集中式源代碼控制。在大約一個(gè)月后，那個(gè)項(xiàng)目開始產(chǎn)生一些任何人都沒辦法追蹤的bug。在每天的會(huì)議上，負(fù)責(zé)那個(gè)應(yīng)用出現(xiàn)奇怪bug部分的開發(fā)者就會(huì)抗議道：“我兩個(gè)星期前就修復(fù)了那個(gè)bug了！”，或者指責(zé)另外一個(gè)開發(fā)者沒有上傳他們?nèi)f分仔細(xì)檢查過的改動(dòng)。

最終，發(fā)現(xiàn)了那個(gè)問題的人教會(huì)了所有開發(fā)者如何以及在何時(shí) push 他們的提交：長(zhǎng)話短說，就是當(dāng)你的提交在本地成功通過測(cè)試的時(shí)候。然后那個(gè)公司在可以創(chuàng)建并部署最新的集成項(xiàng)目之前，他們進(jìn)行了長(zhǎng)達(dá)兩天的合并行動(dòng)。

Git/GitHub小技巧6:多創(chuàng)建些分支

Git相對(duì)于其他分布式控制系統(tǒng)來說，最大的優(yōu)勢(shì)就是它的合并做得很好，至少一部分原因是因?yàn)镚it在合并時(shí)選擇的都是最好的原型。大多數(shù)軟件開發(fā)者需要更經(jīng)常地在他們的項(xiàng)目中創(chuàng)建分支了。它應(yīng)該成為每天的日常事件，而不是一個(gè)全體戰(zhàn)略會(huì)議的主題。最大的可能性是，當(dāng)你的分支項(xiàng)目已經(jīng)完成，通過，并且打算轉(zhuǎn)向主要項(xiàng)目時(shí)，這時(shí)合并就不會(huì)出現(xiàn)無法克服的問題了。

我知道這需要一些調(diào)整，尤其是你的公司是使用CVS進(jìn)行源代碼控制的話。但是還是要試試啊。總比你的用戶意外發(fā)現(xiàn)了你的主線項(xiàng)目必須因?yàn)橐粋€(gè)破壞性的bug被迫發(fā)布的時(shí)候遺留的一些未完成的實(shí)驗(yàn)性代碼要好得多。（這篇文章解釋了基本的分支和合并）

Git/GitHub小技巧7:合并要謹(jǐn)慎

用Git進(jìn)行合并通常來講是應(yīng)該進(jìn)行得很順利的，但是之前如果你不進(jìn)行謹(jǐn)慎的思考的話，偶爾你也會(huì)噴到一些困難。第一步首先要確保你沒有未提交的改動(dòng)。git merge手冊(cè)頁上說道：

在你進(jìn)行任何的外部改變之前，你應(yīng)該先使你的任務(wù)保持在基本完好的狀態(tài)并在當(dāng)?shù)剡M(jìn)行提交，所以在產(chǎn)生沖突的時(shí)候不至于徹底崩潰。參見git-stash。

更多詳情參見技巧8。

即使在一次git合并過程中你完全失敗了，也不至于遭受太大的損失：

即使你的合并導(dǎo)致了非常復(fù)雜的沖突并且想要重來一次，你可以通過 git merge —abort進(jìn)行修復(fù)。假設(shè)你是用GUI來進(jìn)行合并的話，git merge的后續(xù)命令通常是git mergetool。如果你更喜歡傳統(tǒng)的方法，那么你可以編輯與你最喜歡的編程編輯器沖突的文件，完全移除 <<<<<<<, =======, 和 >>>>>>>，把修訂過的文件保存后，再進(jìn)行記錄更新。

Git/GitHub小技巧8:在進(jìn)行分支切換之前記得保存

一個(gè)軟件開發(fā)者的工作流程很少是線性的。用戶常常會(huì)抱怨產(chǎn)品的bug，經(jīng)理常常會(huì)優(yōu)先考慮你并不想要在上面浪費(fèi)時(shí)間的門票，而你呢，你自己可能會(huì)隨時(shí)改變你想要做什么的想法。

現(xiàn)在在你面前，有三份提交過的文件待發(fā)行，還有第四份文件在一個(gè)已經(jīng)修訂過但是是不工作的狀態(tài)。（git status命令會(huì)告訴你所有這些信息，如果你剛好不記得你的進(jìn)度的話。）突然之間你需要對(duì)產(chǎn)品版本的bug進(jìn)行修復(fù)。你需要快速地切換分支，但是你做不到，因?yàn)槟愕墓ぷ髂夸浺粓F(tuán)糟，而且你不想放棄你兩個(gè)小時(shí)的辛苦工作。

進(jìn)入git stash。好啦！你可以看到你所有的改動(dòng)都保存在WIP（進(jìn)程中）里面，而且你可以從你干凈的目錄切換到產(chǎn)品分支。當(dāng)你把產(chǎn)品部分處理完畢，你就可以通過git stash apply切換回你之前在做的工作啦。

Git/GitHub小技巧9：使用gists來分享snippet和paste

GitHub “gists”—分享代碼片段—非Git格式，但是他們使用Git。所有的gists都是Git 庫(kù)，而且GitHub Gist使得他們分享起來很容易。你可以在公共gists通過主題、編程語言、分叉狀況以及獲得Star的狀況搜索Gist。你還可以創(chuàng)建私密的gists并通過URL分享他們。

Git/GitHub小技巧10：探索GitHub

很多有趣的開源項(xiàng)目在GitHub上都有代碼庫(kù)。Explore GitHub提供了找到這些項(xiàng)目的瀏覽界面，但是在大多數(shù)情況下在搜索框敲幾個(gè)項(xiàng)目名稱的字母可能還更快找到它的庫(kù)。例如，輸入 jq、back或者ang你就能找到主要的前三名開源JS框架。

Git/GitHub小技巧11：為開源項(xiàng)目做貢獻(xiàn)

既然你常常瀏覽開源項(xiàng)目，為什么你不貢獻(xiàn)一些呢？其實(shí)這并沒有你想象的那么困難，而且你可以從中學(xué)習(xí)到很多哦。舉個(gè)栗子，你可以復(fù)制jquery/jquery (jQuery Core)項(xiàng)目，然后在README.MD中進(jìn)行瀏覽，在最上方你會(huì)看到：

本著開源軟件開發(fā)的精神，jQuery總是鼓勵(lì)社區(qū)代碼貢獻(xiàn)。為了幫助你在敲代碼之前能有一個(gè)好的開始，請(qǐng)你確保你認(rèn)真閱讀了以下重要的貢獻(xiàn)指南……

后面又三個(gè)鏈接。第一個(gè)鏈接可以使你快速起步。并不是所有的開源項(xiàng)目都能很清晰地列出他們的計(jì)劃，但是他們都在嘗試。

理解做為一個(gè)貢獻(xiàn)者和提交者的不同。一個(gè)貢獻(xiàn)者是已經(jīng)簽了所需協(xié)議并且對(duì)項(xiàng)目做出有益貢獻(xiàn)的。一個(gè)提交者是被授權(quán)上傳項(xiàng)目庫(kù)所需要的貢獻(xiàn)的。因?yàn)樵谔峤徽邔?duì)你的貢獻(xiàn)進(jìn)行測(cè)試的時(shí)候是有延遲的，而且你也不想綁定你的主分支，所以你應(yīng)該在發(fā)送pull請(qǐng)求（參見技巧16）之前在你的另外一個(gè)分支當(dāng)中進(jìn)行修改（參見技巧6）。

Git/GitHub小技巧12：使用 “git it”的編輯器和IDE

如果你千辛萬苦寫了一堆代碼，結(jié)果在你下次登錄的時(shí)候，發(fā)現(xiàn)其他人也在編你那段相同的代碼，你肯定覺得心好累啊。你可以通過使用集成Git的編輯器或者IDE來避免心累或者減少心累，它會(huì)告訴你你現(xiàn)在正在瀏覽的代碼有了新的你需要Pull的提交，以及新的提交要實(shí)現(xiàn)的功能。

Git/GitHub小技巧13：Fork a repo

Fork一個(gè)庫(kù)意味著創(chuàng)建屬于你自己的代碼庫(kù)可編輯服務(wù)器拷貝，也就是說，在路徑中創(chuàng)建一個(gè)fork。如果它是一個(gè)我們沒有提交權(quán)利的公有庫(kù)（參見技巧11），那么貢獻(xiàn)我們的修改的最簡(jiǎn)單的方法就是在服務(wù)器端把它們托管在我們自己的fork中，此方法可通過初始的GitHub項(xiàng)目底部的fork按鈕實(shí)現(xiàn)。然后我們就可以向fork庫(kù)的所有者提出pull請(qǐng)求（參見技巧16），它們才有可能測(cè)試并采用我們的貢獻(xiàn)。開始的時(shí)候你可能會(huì)懵逼，但是后面就會(huì)越來越輕松啦。例如，請(qǐng)參見本書部分，介紹對(duì)一個(gè)小型公共項(xiàng)目的貢獻(xiàn)。

Git/GitHub小技巧14：查看項(xiàng)目

當(dāng)你fork一個(gè)項(xiàng)目的時(shí)候，你肯定想知道你的上游項(xiàng)目發(fā)生了些什么。如果是這樣的話，請(qǐng)查看repo。如果你覺得更新提示很煩，無視它就好。如果你注意到會(huì)影響你的改動(dòng)，提取并并到上游提交項(xiàng)目合。

Git/GitHub小技巧15：關(guān)注朋友

GitHub建議你以一種“不惡心的方式”關(guān)注GitHub員工。你還應(yīng)該關(guān)注上傳你感興趣項(xiàng)目的人，然后那可能可以拓展另外你可能感興趣的項(xiàng)目。我在GitHub上關(guān)注了dmethvin，但是完全不是令人惡心的方式哦，因?yàn)樵谒€在PC Tech Journal的時(shí)候我們就曾經(jīng)斷斷續(xù)續(xù)地共事過，然后現(xiàn)在他已經(jīng)是jQuery基金會(huì)的主席啦。

Git/GitHub小技巧16：發(fā)送pull request

在技巧13當(dāng)中，我們探討了如何fork一個(gè)GitHub庫(kù)。用上游庫(kù)（fork之后變成你的庫(kù)）合并一些或者所有的改動(dòng)的方法就是向它們發(fā)送一個(gè)pull request，參照這個(gè)指南。

Git/GitHub小技巧17：創(chuàng)造并解決問題

所有的軟件都有bug。許多軟件項(xiàng)目采用單獨(dú)的bug跟蹤系統(tǒng)，但是有些人在GitHub中會(huì)使用 Issues feature。你可以通過向一個(gè)項(xiàng)目報(bào)告bug來展現(xiàn)你的牛逼，如果能解決的話就更加牛逼啦

Git/GitHub小技巧18：寫有趣的README內(nèi)容

在技巧11，我給你了jquery/jquery的頁面來讓你了解這個(gè)項(xiàng)目。為你的項(xiàng)目寫個(gè)有趣的README內(nèi)容，你不會(huì)后悔的哦。

自從上世紀(jì)60年代以來，README在軟件開發(fā)領(lǐng)域就成了一個(gè)既定的規(guī)范，當(dāng)我看到我的第一份README文檔以全大寫字母的形式在綠白相間的紙上打印出來，還包裝著一堆字符卡，那時(shí)候企圖在1940年的IBM計(jì)算機(jī)上運(yùn)行。在70年代我就看到更多啦，在我還在研發(fā)DEC迷你計(jì)算機(jī)和大型IBM電腦主機(jī)的時(shí)候，在所有可以想象到的媒體以及操作系統(tǒng)上你都可以看見。參見REAMDE。

Git/GitHub小技巧19：使用Markdown

早期的大寫字母README文件只是一個(gè)雛形?，F(xiàn)在標(biāo)準(zhǔn)的格式化README文件都是Markdown, 尤其是 GitHub 味兒的Markdown。我以前還看見過HTML格式的README文件，但是這種形式慢慢地好像消失了。

Git/GitHub小技巧20：轉(zhuǎn)化你的舊有repo到Git

上面所有我列出的技巧，這個(gè)可能是最難實(shí)現(xiàn)的，不論是在技術(shù)上還是政治上。政治方面主要是因?yàn)槌绦騿T天生對(duì)他們的工具是比較保守的。這需要在訓(xùn)練中加以解決。

要轉(zhuǎn)化一個(gè)大型的，歷史久遠(yuǎn)的，存有上百萬行的代碼，數(shù)以萬計(jì)的提交，還有因?yàn)槭褂霉珖嵉膬?chǔ)存記憶而產(chǎn)生的成千上萬tag的庫(kù)在技術(shù)上也是非常困難的。我有一個(gè)幾十年的CVS庫(kù)，只能在大型或者加大型的亞馬遜EC2實(shí)例當(dāng)中進(jìn)行轉(zhuǎn)換，而且他們依然需要幾天的時(shí)間才能轉(zhuǎn)換完成。如果你是從Subversion進(jìn)行轉(zhuǎn)換，你可以試試svn2git。如果你是從CVS進(jìn)行轉(zhuǎn)換，可以考慮git -cvsimport和cvs2git。