這篇文章是針對git版本控制和工作流的總結，如果有些朋友之前還沒使用過git，對git的基本概念和命令不是很熟悉，可以從以下基本教程入手：

• 專為設計師而寫的GitHub快速入門教程
• git – 簡明指南
• 學習Git的線上互動教程

基本概念

Git是什麼？

Git是分散式版本控制系統，與SVN類似的集中化版本控制系統相比，集中化版本控制系統雖然能夠令多個團隊成員一起協作開發，但有時如果中央伺服器當機的話，誰也無法在當機期間提交更新和協同開發。甚至有時，中央伺服器磁碟故障，恰巧又沒有做備份或備份沒及時，那就可能有丟失資料的風險。

但Git是分散式的版本控制系統，客戶端不只是提取最新版本的快照，而且將整個程式碼倉庫映象複製下來。如果任何協同工作用的伺服器發生故障了，也可以用任何一個程式碼倉庫來恢復。而且在協作伺服器當機期間，你也可以提交程式碼到本地倉庫，當協作伺服器正常工作後，你再將本地倉庫同步到遠端倉庫。

為什麼要使用Git

• 能夠對檔案版本控制和多人協作開發
• 擁有強大的分支特性，所以能夠靈活地以不同的工作流協同開發
• 分散式版本控制系統，即使協作伺服器當機，也能繼續提交程式碼或檔案到本地倉庫，當協作伺服器恢復正常工作時，再將本地倉庫同步到遠端倉庫。
• 當團隊中某個成員完成某個功能時，通過pull request操作來通知其他團隊成員，其他團隊成員能夠review code後再合併程式碼。

Git有哪些特性

• 檔案三種狀態(modified, staged, committed)
• 直接記錄快照，而非差異比較
• 多數操作僅新增操作
• 近乎所有操作都是本地執行
• 時刻保持資料完整性

有關以上特性的詳細解釋，請檢視Pro git的git基礎章節

Git基本工作流程

1. 在git版本控制的目錄下修改某個檔案
2. 使用git add命令對修改後的檔案快照，儲存到暫存區域
3. 使用git commit命令提交更新，將儲存在暫存區域的檔案快照永久轉儲到 Git 目錄中

Git基本技巧

• 自動補全
• Git 命令別名

關於具體如何使用自動補全和命名別名技巧，請檢視Pro git的技巧和竅門

Git版本控制

建立倉庫

• git init
• git clone
• git config

儲存修改

• git add
• git commit

檢視倉庫

• git status
• git log –oneline

撤銷修改

檢視之前的commit

• git checkout <commit> <file>
• git checkout <commit>
• git checkout <branch>

撤銷公共修改

• git revert <commit>

撤銷本地修改

• git reset
• git clean

重寫Git歷史記錄

• git commit –amend
• git rebase
• git reflog

Git協作開發

分支

• git branch
• git checkout
• git merge

倉庫同步

• git remote
• git fetch
• git pull
• git push

Git工作流

由於git擁有強大的分支特性，它的工作流比較靈活而缺乏約束，於是參考Atlassian Git Tutorial的Comparing Workflows章節提供四種Git工作流：

• Centralized Workflow
• Feature Branch Workflow
• Gitflow Workflow
• Forking Workflow

以上工作流只是參考指南，而不是具體規則。你可以根據自己實際情況來選擇適合自己的工作流或微調來滿足自己的需要。

Centralized Workflow

過渡到分散式版本控制系統看起來像一個艱鉅的任務，但如果你充分利用好git的話，你不必改變你既有的工作流，你的團隊可以採用與之前使用SVN一樣的方式來開發專案。

如何工作

1. 從遠端倉庫(central repository)克隆工程到本地倉庫(local repository) — git clone
2. 在本地倉庫編輯檔案和提交更新 — git add和git commit
3. fetch遠端倉庫已更新的commit到本地倉庫和rebase到已更新的commit的上面 —git fetch和git rebase 或 git pull --rebase
4. push本地主分支(master branch)到遠端倉庫 — git push

管理衝突

• 何時發生衝突：在開發者釋出它們功能之前，他們需要fetch遠端倉庫已更新的commit到本地倉庫和rebase到已更新的commit的上面。有時，本地提交與遠端提交會發生衝突，git會暫停rebase過程來讓你手動解決衝突。
• 如何解決衝突：你可以使用git status和git add來手動解決合併時衝突。

Feature Branch Workflow

Feature Branch Workflow的主要思想就是在開發每個功能時都應該建立一個獨立的分支而不只是使用主分支。由於每個分支是獨立且互不影響，這就意味著主分支不會包含broken code，對持續整合環境是很有幫助的。

如何工作

1. 仍然使用遠端倉庫(central repository)和主分支(master branch)仍記錄官方工程的歷史
2. 開發者每次開發新功能時都建立一個新分支 — git checkout -b
3. Feature branches應該推送到遠端倉庫(central repository) — git push
4. 傳送pull request來請求管理員能否合併到主分支(master branch)
5. 釋出新功能到遠端倉庫(central repository)

Pull Request

Pull request是一種當開發者完成一個新功能後向其他團隊成員傳送通知的機制。它的使用過程如下：

• 開發者可以通過Github或Bitbucket傳送pull request

• 其他的團隊成員審查、討論和修改程式碼
• 專案維護者合併新增功能分支到主分支(master branch)，然後關閉pull request

Gitflow Workflow

Feature Branch Workflow是一種非常靈活的開發方式。對於一些規模比較大的團隊，最好就是給特定的分支賦予不同的角色。除了功能分支(feature branch)，Gitflow Workflow還使用獨立的分支來準備釋出(preparing)，維護(maintaining), 和記錄版本(recording releases)。下面我會逐個介紹這個幾個分支：Historical Branches、Feature Branches、Release Branches和Maintenance Branches。

Historical Branches

• master分支儲存官方釋出歷史
• develop分支衍生出各個feature分支

Feature Branches

• feature分支使用develop分支作為它們的父類分支
• 當其中一個feature分支完成後，它會合並會develop分支
• feature分支應該從不與master分支直接互動

Release Branches

• release分支主要用來清理釋放、測試和更新文件
• 一旦develop分支獲得足夠的功能來發布時，你可以從develop衍生出一個release分支
• 一旦準備好上架，release合併到master分支並且標記一個版本號
• 另外，還需要合併回develop分支

Maintenance Branches

• maintenance分支用來快速給已釋出產品修復bug或微調功能
• 它從master分支直接衍生出來
• 一旦完成修復bug，它應該合併回master分支和develop分支
• master應該被標記一個新的版本號

標記Tags

使用兩個命令來給master分支標記版本號：

• git tag -a 0.1 -m "Initial public release" master
• git push origin master --tags

Forking Workflow

Forking Workflow與以上討論的工作流很不同，一個很重要的區別就是它不只是多個開發共享一個遠端倉庫(central repository)，而是每個開發者都擁有一個獨立的服務端倉庫。也就是說每個contributor都有兩個倉庫：本地私有的倉庫和遠端共享的倉庫。

Forking Workflow這種工作流主要好處就是每個開發者都擁有自己的遠端倉庫，可以將提交的commits推送到自己的遠端倉庫，但只有工程維護者才有許可權push提交的commits到官方的倉庫，其他開發者在沒有授權的情況下不能push。Github很多開源專案都是採用Forking Workflow工作流。

如何工作

1. 在伺服器上有一個官方公共的倉庫
2. 開發者fork官方倉庫來建立它的拷貝，然後存放在伺服器上

   

   Fork official repository.png
3. 當開發者準備好釋出本地的commit時，他們push commit到他們自己的公共倉庫
4. 在自己的公共倉庫傳送一個pull request到官方倉庫
5. 維護者pull貢獻者的commit到他自己的本地倉庫
6. 審查程式碼確保它不會破壞工程，合併它到本地倉庫的master分支
7. push master分支到伺服器上的官方倉庫
8. 其他開發者應該同步官方倉庫。

擴充套件閱讀

• Pro Git 簡體中文版
• atlassian Git Tutorials