如何優雅地使用 Git？

如果你使用 Vim 編輯器，那麼推薦你安裝 Fugitive 插件。它不但讓你不用再在 Vim 與 Terminal 之間切來切去，甚至還提供了 Terminal 上不具備的功能。我只在這裡簡略地展示一下，更詳細的介紹，推薦觀看 Vimcasts 上關於 Fugitive 的介紹。

1. A complement to command line git
2. Working with the git index
3. Resolving merge conflicts with vimdiff
4. Browsing the git object database
5. Exploring the history of a git repository

Gdiff


Gstatus


修改文件後，在 Vim 中運行 :Gstatus，可以在預覽窗口中看到熟悉的 git status 界面。游標標記需保存的修改項後，按 - 可快速 add 之。按 C 可進行 commit。什麼？只不過換了個地方做同樣的事？不僅如此。注意下圖，你可以在 commit message 中利用 Vim 的自動完成功能。媽媽再也不用擔心我 commit 時寫錯函數名了！

Gblame


一圖勝萬言。不用多說。

Glog


用 :Glog 隨時查看當前文件的所有版本。

oh-my-zsh git plugin with git alias makes you to use git any time, don"t forget to configure your ssh key to get access the repo.

在git裡面加了十多條alias在圈子裡什麼水平？

感覺alias要被我玩壞了。

1. 循序漸進, 實踐中學習
   git博大精深, 命令眾多, 每個命令的參數又很多. 不要想著看一遍書或者文檔, 然後就可以記住所有的使用方法. 應該在實踐中學習, 吸收大家的經驗, 逐漸提高.
2. 不排斥alias, 善用alias
   同意之前的回答, alias會影響對git本身命令的熟悉程度. 不過對已經熟悉的命令, 結合自身情況適用alias肯定是事半功倍的事情.
3. 適用圖形界面
   這裡推薦GitX. 最開始用純命令行, 後來用了GitHub官方客戶端之後, 查看diff就用GUI了. 再後來接觸了GitX之後, 就不再使用GitHub客戶端了. 如果只是看history的話, 命令行里再好看的git lg也不如GitX里用起來方便.
4. 冷僻的命令
   filter-branch, 用腳本的方式修改大量的提交. 如果你想把你的項目開源, 開源之前應該肯定需要用到這個命令.
   bisect, 其實在了解這個命令之前, 一直在用人肉的方式來模擬這個過程. 知道這個命令之後就方便多了.
5. hook
   客戶端hook, 以及伺服器端hook. 可以用客戶端hook做一些基本的檢查, 也能起到事半功倍的效果.
   比如空格和tab鍵. 我們的項目里要求大家用四個空格來代替tab, 為了達到這個目的, 要求在Eclipse或者IntelliJ里做設置. 但是新成員很可能會忽略這一點, 然後merge到代碼庫里. 用pre-commit hook可以做檢查, 在commit的時候就給出warning.

1. 熟練掌握常用命令

如果尚不能熟練使用工作、生活中常用的一些git命令，敲擊命令的時候一腦袋問號，我相信這絕逼不是高雅。clone有哪些常用參數？push的時候什麼時候可以簡寫？錯誤操作如何挽回？分支到底是個什麼玩意，怎麼才能玩得轉？等等問題，都屬於日常使用過程中經常遇到，或有很大機率會遇到的，應該熟練掌握。遇到此類問題思維不卡頓方能高雅初現。

2. 關於alias

堅決反對任何alias！這確實能夠帶來使用上的方便，不是一點半點，這是好的一面。但是因為git的多樣性，每個子命令往往都帶有眾多參數，這些參數能夠通過多種形式的匹配達到最符合當前使用場景的目的。而這也正是git的魅力之處（此處不評論svn，各位自行腦補），大量使用alias嚴重影響使用者對git本身命令的熟知程度，以及git的操作性。說嚴重了，離開了你的alias，git形同陌路。沒有魅力的git，形同陌路的git，這又哪有什麼高雅可言呢？

3. 偏門命令

filter-branch命令想必很少人會用，不過這個命令卻有著超級強悍的戰鬥力，可批量修改commit；

等等等等git的偏門命令，雖不常用，但是如果在恰當的時候、恰當的情景下，偶爾用出來那麼一兩次解決大大小小的問題。優雅程度直線上升有沒有？

4. 關於shell和git圖形界面

Keep your own history readable

永遠保持工作區乾淨。

重複1萬次。

永遠不要git push -f

寫在前面：在我建議你使用git前，首先要給你潑一盆冷水，見博文我痛恨git的10個理由,以下為文中的片段：

Git 是一個源代碼版本控制系統，正在迅速成為開源項目的標準。它有一個強大的分散式模型，允許高級用戶用分支來處理各種棘手的問題和改寫歷史記錄。但是，要學習 Git 是需要付出更多的努力，讓人不爽的命令行介面以及 Git 是如此的忽視它的使用者。

如果你是一個架構師，那麼 Git 是很棒的。但對用戶來說它很糟糕，已經有不少人在為 Git 編寫一些簡化的介面，例如 easygit。

如果 Git 的強大之處是分支和合併，那麼它的弱點就是讓簡單的任務變得非常複雜。

git是如此的強大，強大到你都不知道該怎麼使用它才好了…

本文提出了一個「git該怎麼在科研實踐中輕鬆的使用」的一個模型，包含眾多的規範來約束你git的使用方法。所謂沒有規矩不成方圓，遵循了模型中的約束條件後，你的git倉庫會變得清晰、優雅起來;你會享受你那結構清晰的network圖（而不是之前那亂糟糟的圖形），而你的合作者也能從你的提交序列中清楚的認識到你的工作思路。

當然，每次使用git的時候都要小心翼翼的遵循這些規範是一件困難的事情。所以我開發了一套腳本，Fmajor/gg 路 GitHub

gg（good use of git），來傻瓜式的實現下述的模型。

=============模型開始的分割線===============

模型思想基於A successful Git branching model，結合本人的學習工作實際和腦洞，升級為此模型。

一、引言：版本控制

二、模型術語、假設、約定和其用途

對於關注此問題的人來說以上兩點不必多說.

下面進入本回答正題

用途：此模型主要用於實現三種類型的任務

舉例：進行新程序的開發/論文的寫作/小組合作完成一件工作等

1.為工作不斷增加新特性(新的程序功能/論文新的章節/工作新的任務)

下圖：開發型工作的開發流程示例

舉例：並不進行程序的開發，而是使用別人的程序，完成自己的工作。比如在網上下載了一個數值相對論的模擬程序，我用他來進行兩個模擬:

1.雙黑洞的繞轉

每完成一個任務，我都需要修改程序的配置文件和提供一些初始數據，也就是說我每次用這個程序只能完成一個模擬，當我想進行另外一項模擬的時候就需要重新修改一些文件，而我需要時不時的在兩個模擬工作間進行切換。

1.選定適當的程序版本，開始進行工作

下圖：使用型工作的流程示例

3.開發使用型:

以上兩種類型的合體，只需要把自己開發出的穩定版本程序作為工作所使用的程序即可

假設：存在以下幾種類型的分支

1.master類型分支，名為?|master或master，其中?為開發代號

下面介紹模型中的約定，並定義gg-*這樣的抽象動作來完成約定中的行為

約定：

1.每一次的提交都必須有意義：

　git在每次提交的時候要求輸入對此提交的概括，這個概括不能為空。

　　正確的提交概括：更新了程序doc

2.開發型任務中的master類型與develop類型分支必須成對出現，master分支的推進只能來源與release分支和hotfix分支的合併，禁止在master分支上直接提交。

註解：master分支上只有我們推送上去的穩定版本的程序，develop分支上的程序一直處於開發狀態，不穩定。

3.feature類型分支滿足：

　3.1.只能從develop類型分支上創建

註解：每當有新特性需要加入的時候，我們應該從develop類型分支上新建一個feature類型分支，完成新特性的開發和測試後將特性合併到develop類型分支上。

4.release類型分支滿足：

　4.1.只能從develop類型分支上創建

註解：每當工作進入到一個較為穩定階段的時候，我們可以使用gg-release-open versionNum建立並轉向一個名為release-versionNum的臨時分支，在這個分支上允許進行小的改動（比如修改一下readme文件中的版本號），然後使用gg-release-close將此版本合併（發布）到master類型分支上，同時合併到develop類型分支上，然後刪除此分支。

5.hotfix類型分支滿足:

　5.1.只能從master類型分支上創建

註解：當新版本發布後發現必須馬上解決的嚴重bug時，我們應該使用gg-hotfix-open versionNum建立並轉向一個名為hotfix-versionNum的臨時分支，在這個分支上完成bug的修復，然後使用gg-hotfix-close將此版本合併（發布）到master類型分支上，同時合併到develop類型分支上，然後刪除此分支。

6.issues類型分支滿足：

　6.1.只能從develop類型分支上創建

註解：每當有（比較複雜的）問題需要解決的時候，我們應該從develop類型分支上新建一個issues類型分支，完成問題的調試後合併到develop類型分支上。

7.trials類型分支滿足：

　7.1.可以從除了release類型分支以外的任何類型分支上創建

註解：在滿足條件的分支A上工作，時不時會冒出一些大膽的想法，這個時候使用gg-trials-open trialsName創建並轉向一個名為A/trials.trialsName的實驗分支，在這個分支上進行瘋狂的實驗，然後

　1.使用gg-trials-good-close完成實驗的和其父分支的合併，刪除此分支或

以上是開發型工作所需要的全部模型，對於使用型的工作，還需要

8.basedOn類型分支滿足:

　8.0.從name|master建立並初始化為name|basedOn

註解：這個分支是一個為了使工作流程更為清晰的緩存分支，分支上只有從master穩定分支上挑選出來的自己在工作中將要（嘗試）使用的穩定版本。在basedOn類型分支上使用gg-select 版本號 從對應的master分支上選出一個穩定版本或使用gg-select-the-latest從對應的master分支上選擇最新的版本，fork到這個分支，並加上inUse-versionNum的標籤

從master到此分支的行為是fork，即有可能此分支的log為 (init)v1.0===&>v0.9=====&>v0.8======&>v1.3,這個分支上的commit來源於master，但是其分支提交歷史與master分支無關

9.work類型分支滿足：

　9.1.只能從basedOn類型分支上創建

註解：

1.創建工作：假設我們已經在A.basedOn分支上選出了最新的需要使用的程序版本v1.0，這時候在A|basedOn上使用gg-work-open-from-current-state workName創建並切換到work-workName/basedOn-A-v1.0分支，開始進行工作，或者使用首先移動到A|basedOn 上面的 inUse-v0.5 版本，然後使用gg-work-open-from-current-state workName，創建並切換到work-workName/basedOn-A-v0.5分支。

2.升級工作：假設我們在工作分支work.workName/basedOn-devCode-tagName上工作，這個時候有人通知你你使用的程序的最新版本發布了，於是你pull origin master將master分支更新為最新的版本號newVersionNum，然後在basedOn分支上使用gg-select-the-leatest將新分支fork到basedOn分支，然後回到工作分支，使用gg-work-update自動創建work-workName/basedOn-newVersionNum，解決完合併衝突後你的工作已經升級為基於最新版本的程序，這個時候你可以測試這個新版本來決定是否使用，也可以隨時切換為老版本繼續在上面工作。如果使用gg-work-update-with tagsOnbasedOn則使用basedOn分支上的特定版本的程序對此程序進行升級（也有可能是「降級」），總之就是一個update的操作。

對於開發使用型的任務，只需要把自己開發出的穩定版本程序作為工作所使用的程序即可

總結:

我們需要知道最最最最基本的git 命令如

1. git add
2. git commit -a
3. git push
4. git pull
5. git checkout

本模型提出了以下這些操作

gg-init

使用型任務中可以使用的:

gg-select

gg-select–the-leatest

gg-work-open-from-current-state

gg-work-update

gg-work-update-with

這些操作的具體實現包括一些約束條件的檢測（嚴格遵照上述模型才能提交）和一些git的操作，將在Fmajor/gg 路 GitHub中一一實現

這就是我在日常的學習工作實踐中使用的（幾乎）所有關於git的命令，所用即所想，拋掉多餘的操作，專註於工作的本身，同時使工作有非常清晰的結構，便於自己欣賞和小組合作.

如果好用，請到github上給我點一顆星星哦～

歡迎討論此模型～

github客戶端超慢的載入速度，功能又少，除了界面比較好看以外我是沒有看到別的任何優點.

===更新===