這篇文章是針對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

• git checkout

• git checkout

撤銷公共修改

• git revert

撤銷本地修改

• 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. 在服務器上有一個官方公共的倉庫

   開發者fork官方倉庫來創建它的拷貝，然後存放在服務器上

   
   
   

2. 當開發者准備好發布本地的commit時，他們push commit到他們自己的公共倉庫

3. 在自己的公共倉庫發送一個pull request到官方倉庫

4. 維護者pull貢獻者的commit到他自己的本地倉庫

5. 審查代碼確保它不會破壞工程，合並它到本地倉庫的master分支

6. push master分支到服務器上的官方倉庫

7. 其他開發者應該同步官方倉庫。

擴展閱讀

• Pro Git 簡體中文版

• atlassian Git Tutorials