Git版本控制與工作流

PHP實現頁面靜態化

Duang~MySQLi擴展庫來襲

使用D3製作圖表

iOS-動畫入門

原文出處： 劉耀柱（@Sam_Lau_Dev）歡迎分享原創到伯樂頭條

Git Version Control

這篇文章是針對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一樣的方式來開發項目。

如何工作

Centralized Workflow

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

管理衝突

File Conflicts

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

如何解決衝突：你可以使用git status和git add來手動解決合併時衝突。

Feature Branch Workflow

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

如何工作

Feature Branch Workflow

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

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

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

1 贊 2 收藏 評論

你的讚賞是我堅持原創的動力

讚賞共 0 人讚賞
推薦閱讀：