Git版本控制與工作流

idjs6295 8年前發布 | 8K 次閱讀 Git 工作流 iOS開發版本控制系統

基本概念

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
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一樣的方式來開發項目。

如何工作

從遠程倉庫(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

管理沖突

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

Feature Branch Workflow

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

如何工作

仍然使用遠程倉庫(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

其他的團隊成員審查、討論和修改代碼
項目維護者合并新增功能分支到主分支(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工作流。