Git版本控制與工作流
這篇文章是針對git版本控制和工作流的總結，如果有些朋友之前還沒使用過git，對git的基本概念和命令不是很熟悉，可以從以下基本教程入手：
基本概念
Git是什麼？
Git是分散式版本控制系統，與SVN類似的集中化版本控制系統相比，集中化版本控制系統雖然能夠令多個團隊成員一起協作開發，但有時如果中央伺服器當機的話，誰也無法在當機期間提交更新和協同開發。甚至有時，中央伺服器磁碟故障，恰巧又沒有做備份或備份沒及時，那就可能有丟失資料的風險。
但Git是分散式的版本控制系統，客戶端不只是提取最新版本的快照，而且將整個程式碼倉庫映象複製下來。如果任何協同工作用的伺服器發生故障了，也可以用任何一個程式碼倉庫來恢復。而且在協作伺服器當機期間，你也可以提交程式碼到本地倉庫，當協作伺服器正常工作後，你再將本地倉庫同步到遠端倉庫。
為什麼要使用Git
- 能夠對檔案版本控制和多人協作開發
- 擁有強大的分支特性，所以能夠靈活地以不同的工作流協同開發
- 分散式版本控制系統，即使協作伺服器當機，也能繼續提交程式碼或檔案到本地倉庫，當協作伺服器恢復正常工作時，再將本地倉庫同步到遠端倉庫。
- 當團隊中某個成員完成某個功能時，通過pull request操作來通知其他團隊成員，其他團隊成員能夠review code後再合併程式碼。
Git有哪些特性
- 檔案三種狀態(modified, staged, committed)
- 直接記錄快照，而非差異比較
- 多數操作僅新增操作
- 近乎所有操作都是本地執行
- 時刻保持資料完整性
有關以上特性的詳細解釋，請檢視Pro git的git基礎章節
Git基本工作流程
- 在git版本控制的目錄下修改某個檔案
- 使用git add命令對修改後的檔案快照，儲存到暫存區域
- 使用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一樣的方式來開發專案。
如何工作
Centralized Workflow
- 從遠端倉庫(central repository)克隆工程到本地倉庫(local repository) --- git clone
- 在本地倉庫編輯檔案和提交更新 --- git add和git commit
- fetch遠端倉庫已更新的commit到本地倉庫和rebase到已更新的commit的上面 --- git fetch和git rebase 或 git pull --rebase
- push本地主分支(master branch)到遠端倉庫 --- git push
管理衝突
File Conflicts
-
何時發生衝突：在開發者釋出它們功能之前，他們需要fetch遠端倉庫已更新的commit到本地倉庫和rebase到已更新的commit的上面。有時，本地提交與遠端提交會發生衝突，git會暫停rebase過程來讓你手動解決衝突。
-
如何解決衝突：你可以使用git status和git add來手動解決合併時衝突。
Feature Branch Workflow
Feature Branch Workflow的主要思想就是在開發每個功能時都應該建立一個獨立的分支而不只是使用主分支。由於每個分支是獨立且互不影響，這就意味著主分支不會包含broken code，對持續整合環境是很有幫助的。
如何工作
Feature Branch Workflow
- 仍然使用遠端倉庫(central repository)和主分支(master branch)仍記錄官方工程的歷史
- 開發者每次開發新功能時都建立一個新分支 --- git checkout -b
- Feature branches應該推送到遠端倉庫(central repository) --- git push
- 傳送pull request來請求管理員能否合併到主分支(master branch)
- 釋出新功能到遠端倉庫(central repository)
Pull Request
Pull request是一種當開發者完成一個新功能後向其他團隊成員傳送通知的機制。它的使用過程如下：
- 開發者可以通過Github或Bitbucket傳送pull request
Pull request on Github
- 其他的團隊成員審查、討論和修改程式碼
- 專案維護者合併新增功能分支到主分支(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
Historical Branches
- master分支儲存官方釋出歷史
- develop分支衍生出各個feature分支
Feature Branches
Feature Branches
- feature分支使用develop分支作為它們的父類分支
- 當其中一個feature分支完成後，它會合並會develop分支
- feature分支應該從不與master分支直接互動
Release Branches
Release Branches
- release分支主要用來清理釋放、測試和更新文件
- 一旦develop分支獲得足夠的功能來發布時，你可以從develop衍生出一個release分支
- 一旦準備好上架，release合併到master分支並且標記一個版本號
- 另外，還需要合併回develop分支
Maintenance Branches
Maintenance Branches.png
- 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工作流。
如何工作
- 在伺服器上有一個官方公共的倉庫
-
開發者fork官方倉庫來建立它的拷貝，然後存放在伺服器上
Fork official repository.png
- 當開發者準備好釋出本地的commit時，他們push commit到他們自己的公共倉庫
- 在自己的公共倉庫傳送一個pull request到官方倉庫
- 維護者pull貢獻者的commit到他自己的本地倉庫
- 審查程式碼確保它不會破壞工程，合併它到本地倉庫的master分支
- push master分支到伺服器上的官方倉庫
- 其他開發者應該同步官方倉庫。
擴充套件閱讀
相關文章
- Git版本控制與工作流詳解Git
- Git版本控制與優缺點Git
- Git(1) —— 版本控制Git
- Git打標籤與版本控制規範Git
- 集中式版本控制與分散式版本控制——Git 學習筆記01分散式Git筆記
- Git與其他版本控制系統的區別Git
- 版本控制軟體Git的安裝與使用Git
- Git 版本控制工具的使用Git
- Git程式碼版本控制流程Git
- git引入_版本控制介紹Git
- 版本控制系統之gitGit
- Git分散式版本控制工具Git分散式
- Git 基礎與工作流Git
- git 入門教程之版本控制Git
- 版本控制工具——Git常用操作（下）Git
- 版本控制工具——Git常用操作（上）Git
- Git版本控制系統安裝Git
- Git版本控制的基本命令Git
- 採用GIT作為版本控制與線上程式碼釋出Git
- git 工作流程以及Git 工作區、暫存區和版本庫（筆記）Git筆記
- 一、Git分散式版本控制系統Git分散式
- 分散式版本控制Git 1.8釋出分散式Git
- Git 版本控制系統的完整指南Git
- Git工作流程Git
- Git 工作流Git
- Git 工作流程Git
- Git工作流Git
- Git新手教程-什麼是版本控制（一）Git
- 使用git不希望檔案被版本控制Git
- git使用系列01-->版本控制介紹Git
- 如何選擇版本控制系統——為什麼選擇Git版本控制系統Git
- Git工作流指南：Gitflow工作流Git
- 轉：Git 工作流程Git
- rails git工作流程AIGit
- Git工作流指南Git
- 理解Git工作流Git
- 搭建私有git伺服器進行版本控制Git伺服器
- Git 版本控制之Xcode 上使用(碼雲)GitXCode