果斷收藏!Git和GitHub大神常用的20個技巧!
Git不僅是編程世界最流行的分佈式版本控制系統，而且你還可以用它查找，分享以及優化你的代碼。接下來就來看看怎樣讓Git和GitHub更好地爲你服務吧。
儘管現在網上有很多Git的初學者教程，而且GitHub自己也提供相當一部分教程，但是要找到有效提高開發者使用Git和GitHub使用效率的技巧還是不太容易的，所以我們就來教大家一些方法吧。
對Git或者GitHub不熟悉的人來說，接下來的幾段話會提供充分的背景知識使得您更好地理解使用技巧。在文章結尾我們會列出一些實用的資源。
Git是一個分佈式版本控制系統，它由Linus Torvalds 2005年在Linux內核社區的幫助下創作完成。我並不是要向你吹噓Git，所以我就不向你不拉不拉它到底有多快多輕便多靈活多受歡迎了，但是，當你複製Git儲存庫時，你應該知道這些，你可以在本地電腦上獲得完整的歷史版本，而不是一次一個分支的快照。
Git起初是作爲命令行使工具，爲它的東家Linux內核社區服務。你仍然可以使用Git 命令行，但這並不是必要的。特別是，如果你使用GitHub作爲你的主機，你就可以在Windows 或者 Mac系統中免費使用GitHub客戶端。從另一個角度看，Git命令行在任何主機上都適用，而且它在大多數Mac和Linux系統中都是預裝的。
只有你能決定命令行和具有圖形用戶界面（GUI）的原生客戶端到底哪個更好用。如果除了GitHub客戶端（Windows和Mac系統），你還喜歡GUI，你可以考慮看看SourceTree (Windows和Mac系統，免費)，TortoiseGit (Windows系統，免費)，以及Gitbox (Mac系統, $14.99)。或者你可以用一個支持內部使用Git的編輯器或者IDE=（參見技巧11）。
Git/GitHub 小技巧1: 複製幾乎所有內容
現在在GitHub以及其他開源的Git庫上都有很多有意思的項目是可以免費複製到你的電腦上的。而你又爲什麼會想要這麼做呢？原因之一是想學學別人的代碼風格、實踐、以及感興趣的編碼語言工具，還包括提交日誌評論的風格吧（詳情看技巧4）。原因之二可能是想看看一個給定的項目是如何最終達到它的目標的吧。原因之三，既然證書允許你這樣做並且這樣做對實現你的目標是非常有意義的，那麼把這些項目納入你的努力和產品之中也是非常合理的。順便多看一遍許可證，以防將來出現合法性問題的爭論。
手冊頁的git clone 定義：
複製一個庫到一個新建的目錄下，在複製的庫中爲每一個分支創建一個遠程跟蹤分支（可視化使用git branch），然後創建並檢查從複製庫中當前激活的分支派生出的初始分支。
在複製之後，一個沒有獲取參數的 git fetch將更新所有遠程跟蹤分支，此外 git pull還將把遠程主分支合併到現有的主分支。
Git/GitHub 小技巧2: 儘量頻繁拖拽
用Git把自己弄得一團糟的最簡單的方法之一（在其他版本控制系統也適用）就是允許文件不同步。如果你經常在git中進行拖拽，你複製的庫的版本將會保持最新，由於合併很好理解和達成，所以你有機會將你改動的代碼和其他人的改動合併在一起，當然最理想的是它能夠簡單到可以自動完成合並。要使用此技巧的話你就必須時刻監視你的項目狀態。許多Git客戶端會自動提示你需要更新以保持最新。
Git/GitHub小技巧3: 儘量提交得又快又頻繁
每次提交都是對項目的粒度更新，它包括一個或多個文件的改動。把它看成是對已完成的工作的單位記錄，可以作爲一個邏輯整體應用到項目中或從項目移除。即使是在測試之前也要記得提交你完成的每次邏輯變動。你的每次提交都只適用於本地儲存庫。參見技巧4和5對本技巧的推論。
手冊頁對 git commit的定義：
在一次新的提交中儲存當前的指數內容並提交用戶描述改變的日誌消息。
Git/GitHub 小技巧4:像要求別人的提交描述一樣要求你自己的
世界上有10種程序員：描述他們的提交的，還有不描述提交的。（呵呵，老笑話啦。提示：我用的基數是什麼？）
我承認我非常堅持提交日誌消息是很好的習慣。我把我的儲存庫設置成每次都需要提交日誌消息，而且我是出了名地愛發送煩人的深夜消息，尤其是當我以XX的順序提交日誌的時候。如果你是這種堅持認爲（1）代碼應該“爲自己代言”（2）在線註釋遠比改變日誌重要的開發者，請試試複製一個你以前從來沒見過的儲存庫，並分辨在沒有閱讀所有代碼之前可能產生最新問題的最新提交。所以你可以看到，精確的提交日誌簡直是雙倍的好啊。
Git/GitHub 小技巧 5:當你的改變被測試時進行推送
我知道的最近發生的Git相關bug的大悲劇就是一個外包公司從Subversion切換出來的時候，他們的開發者並沒有被訓練過如何分辨分佈式源代碼控制和集中式源代碼控制。在大約一個月後，那個項目開始產生一些任何人都沒辦法追蹤的bug。在每天的會議上，負責那個應用出現奇怪bug部分的開發者就會抗議道：“我兩個星期前就修復了那個bug了！”，或者指責另外一個開發者沒有上傳他們萬分仔細檢查過的改動。
最終，發現了那個問題的人教會了所有開發者如何以及在何時 push 他們的提交：長話短說，就是當你的提交在本地成功通過測試的時候。然後那個公司在可以創建並部署最新的集成項目之前，他們進行了長達兩天的合併行動。
Git/GitHub小技巧6:多創建些分支
Git相對於其他分佈式控制系統來說，最大的優勢就是它的合併做得很好，至少一部分原因是因爲Git在合併時選擇的都是最好的原型。大多數軟件開發者需要更經常地在他們的項目中創建分支了。它應該成爲每天的日常事件，而不是一個全體戰略會議的主題。最大的可能性是，當你的分支項目已經完成，通過，並且打算轉向主要項目時，這時合併就不會出現無法克服的問題了。
我知道這需要一些調整，尤其是你的公司是使用CVS進行源代碼控制的話。但是還是要試試啊。總比你的用戶意外發現了你的主線項目必須因爲一個破壞性的bug被迫發佈的時候遺留的一些未完成的實驗性代碼要好得多。（這篇文章解釋了基本的分支和合並）
Git/GitHub小技巧7:合併要謹慎
用Git進行合併通常來講是應該進行得很順利的，但是之前如果你不進行謹慎的思考的話，偶爾你也會噴到一些困難。第一步首先要確保你沒有未提交的改動。git merge手冊頁上說道：
在你進行任何的外部改變之前，你應該先使你的任務保持在基本完好的狀態並在當地進行提交，所以在產生衝突的時候不至於徹底崩潰。參見git-stash。
更多詳情參見技巧8。
即使在一次git合併過程中你完全失敗了，也不至於遭受太大的損失：
即使你的合併導致了非常複雜的衝突並且想要重來一次，你可以通過 git merge —abort進行修復。假設你是用GUI來進行合併的話，git merge的後續命令通常是git mergetool。如果你更喜歡傳統的方法，那麼你可以編輯與你最喜歡的編程編輯器衝突的文件，完全移除 <<<<<<<,>>>>>>>，把修訂過的文件保存後，再進行記錄更新。
Git/GitHub小技巧8:在進行分支切換之前記得保存
一個軟件開發者的工作流程很少是線性的。用戶常常會抱怨產品的bug，經理常常會優先考慮你並不想要在上面浪費時間的門票，而你呢，你自己可能會隨時改變你想要做什麼的想法。
現在在你面前，有三份提交過的文件待發行，還有第四份文件在一個已經修訂過但是是不工作的狀態。（git status命令會告訴你所有這些信息，如果你剛好不記得你的進度的話。）突然之間你需要對產品版本的bug進行修復。你需要快速地切換分支，但是你做不到，因爲你的工作目錄一團糟，而且你不想放棄你兩個小時的辛苦工作。
進入git stash。好啦！你可以看到你所有的改動都保存在WIP（進程中）裏面，而且你可以從你乾淨的目錄切換到產品分支。當你把產品部分處理完畢，你就可以通過git stash apply切換回你之前在做的工作啦。
Git/GitHub小技巧9：使用gists來分享snippet和paste
GitHub “gists”—分享代碼片段—非Git格式，但是他們使用Git。所有的gists都是Git 庫，而且GitHub Gist 使得他們分享起來很容易。你可以在公共gists通過主題、編程語言、分叉狀況以及獲得Star的狀況搜索Gist。你還可以創建私密的gists並通過URL分享他們。
Git/GitHub小技巧10：探索GitHub
很多有趣的開源項目在GitHub上都有代碼庫。Explore GitHub 提供了找到這些項目的瀏覽界面，但是在大多數情況下在搜索框敲幾個項目名稱的字母可能還更快找到它的庫。例如，輸入 jq、back或者ang你就能找到主要的前三名開源JS框架。
Git/GitHub小技巧11：爲開源項目做貢獻
既然你常常瀏覽開源項目，爲什麼你不貢獻一些呢？其實這並沒有你想象的那麼困難，而且你可以從中學習到很多哦。舉個栗子，你可以複製jquery/jquery (jQuery Core)項目，然後在README.MD中進行瀏覽，在最上方你會看到：
本着開源軟件開發的精神，jQuery總是鼓勵社區代碼貢獻。爲了幫助你在敲代碼之前能有一個好的開始，請你確保你認真閱讀了以下重要的貢獻指南……
後面又三個鏈接。第一個鏈接可以使你快速起步。並不是所有的開源項目都能很清晰地列出他們的計劃，但是他們都在嘗試。
理解做爲一個貢獻者和提交者的不同。一個貢獻者是已經簽了所需協議並且對項目做出有益貢獻的。一個提交者是被授權上傳項目庫所需要的貢獻的。因爲在提交者對你的貢獻進行測試的時候是有延遲的，而且你也不想綁定你的主分支，所以你應該在發送pull請求（參見技巧16）之前在你的另外一個分支當中進行修改（參見技巧6）。
Git/GitHub小技巧12：使用 “git it”的編輯器和IDE
如果你千辛萬苦寫了一堆代碼，結果在你下次登錄的時候，發現其他人也在編你那段相同的代碼，你肯定覺得心好累啊。你可以通過使用集成Git的編輯器或者IDE來避免心累或者減少心累，它會告訴你你現在正在瀏覽的代碼有了新的你需要Pull的提交，以及新的提交要實現的功能。
Git/GitHub小技巧13：Fork a repo
Fork一個庫意味着創建屬於你自己的代碼庫可編輯服務器拷貝，也就是說，在路徑中創建一個fork。如果它是一個我們沒有提交權利的公有庫（參見技巧11），那麼貢獻我們的修改的最簡單的方法就是在服務器端把它們託管在我們自己的fork中，此方法可通過初始的GitHub項目底部的fork按鈕實現。然後我們就可以向fork庫的所有者提出pull請求（參見技巧16），它們纔有可能測試並採用我們的貢獻。開始的時候你可能會懵逼，但是後面就會越來越輕鬆啦。例如，請參見本書部分，介紹對一個小型公共項目的貢獻。
Git/GitHub小技巧14：查看項目
當你fork一個項目的時候，你肯定想知道你的上游項目發生了些什麼。如果是這樣的話，請查看repo。如果你覺得更新提示很煩，無視它就好。如果你注意到會影響你的改動，提取並併到上游提交項目合。
Git/GitHub小技巧15：關注朋友
GitHub建議你以一種“不噁心的方式”關注GitHub員工。你還應該關注上傳你感興趣項目的人，然後那可能可以拓展另外你可能感興趣的項目。我在GitHub上關注了dmethvin，但是完全不是令人噁心的方式哦，因爲在他還在PC Tech Journal的時候我們就曾經斷斷續續地共事過，然後現在他已經是jQuery基金會的主席啦。
Git/GitHub小技巧16：發送pull request
在技巧13當中，我們探討了如何fork一個GitHub庫。用上游庫（fork之後變成你的庫）合併一些或者所有的改動的方法就是向它們發送一個pull request，參照這個指南。
Git/GitHub小技巧17：創造並解決問題
所有的軟件都有bug。許多軟件項目採用單獨的bug跟蹤系統，但是有些人在GitHub中會使用 Issues feature。你可以通過向一個項目報告bug來展現你的牛逼，如果能解決的話就更加牛逼啦
Git/GitHub小技巧18：寫有趣的README內容
在技巧11，我給你了jquery/jquery 的頁面來讓你瞭解這個項目。爲你的項目寫個有趣的README內容，你不會後悔的哦。
自從上世紀60年代以來，README在軟件開發領域就成了一個既定的規範，當我看到我的第一份README文檔以全大寫字母的形式在綠白相間的紙上打印出來，還包裝着一堆字符卡，那時候企圖在1940年的IBM計算機上運行。在70年代我就看到更多啦，在我還在研發DEC迷你計算機和大型IBM電腦主機的時候，在所有可以想象到的媒體以及操作系統上你都可以看見。參見REAMDE。
Git/GitHub小技巧19：使用Markdown
早期的大寫字母README文件只是一個雛形。現在標準的格式化README文件都是Markdown, 尤其是 GitHub 味兒的Markdown。我以前還看見過HTML格式的README文件，但是這種形式慢慢地好像消失了。
Git/GitHub小技巧20：轉化你的舊有repo到Git
上面所有我列出的技巧，這個可能是最難實現的，不論是在技術上還是政治上。政治方面主要是因爲程序員天生對他們的工具是比較保守的。這需要在訓練中加以解決。
要轉化一個大型的，歷史久遠的，存有上百萬行的代碼，數以萬計的提交，還有因爲使用公噸的儲存記憶而產生的成千上萬tag的庫在技術上也是非常困難的。我有一個幾十年的CVS庫，只能在大型或者加大型的亞馬遜EC2實例當中進行轉換，而且他們依然需要幾天的時間才能轉換完成。如果你是從Subversion進行轉換，你可以試試 svn2git。如果你是從CVS進行轉換，可以考慮git -cvsimport 和cvs2git。