主要了解git的一些基本的團(tuán)隊(duì)協(xié)作命令，和GitFlow工作流指南

git 團(tuán)隊(duì)協(xié)作的一些命令

• 1.開分支

git branch 新分支名
例如，在master分支下，新開一個(gè)開發(fā)分支：
git branch dev

• 2.切換到新分支

git checkout 分支名
例如，在master分支下，切換到新開的dev：
git checkout dev

• 3.開分支和切換分支合并到一個(gè)命令

git checkout -b 新分支名
例如，新開一個(gè)開發(fā)分支，并立即切換到該分支：
git checkout -b dev

• 4.切換回原分支

git checkout 原分支名
例如，切換回master
git checkout master
注意：當(dāng)前分支有修改，還未commit的時(shí)候，會(huì)切換失敗，應(yīng)當(dāng)先commit，但可以不用push

• 5.合并分支

git merge 需要合并的分支名
例如，剛剛已經(jīng)切換回master，現(xiàn)在需要合并dev的內(nèi)容：
git merge dev
建議在GitLab(或者其他git系統(tǒng))上面創(chuàng)建merge request的形式來進(jìn)行分支的合并和代碼審核。

• 6.查看本地分支列表

git branch -a
前面帶remotes/origin 的，是遠(yuǎn)程分支

• 7.查看遠(yuǎn)程分支列表

git branch -r

• 8.向遠(yuǎn)程提交本地新開的分支

git push origin 新分支名:遠(yuǎn)程分支名
例如，剛剛在master下新開的dev分支：
git push origin dev:dev

• 9.刪除遠(yuǎn)程分支

git push origin --delete 遠(yuǎn)程分支名
例如，刪除剛剛提交到遠(yuǎn)程的dev分支：
git push origin --delete dev

• 10.刪除本地分支

git branch 分支名稱 -d
例如，在master分支下，刪除新開的dev分支：
git branch dev -d
注意：如果dev的更改，push到遠(yuǎn)程，在GitLab(或者其他git系統(tǒng))上面進(jìn)行了merge操作，但是本地master沒有pull最新的代碼，會(huì)刪除不成功，可以先git pull origin master，或者強(qiáng)制刪除
git branch dev -D

Git工作流指南：Gitflow工作流

在你開始閱讀之前，請(qǐng)記?。毫鞒虘?yīng)被視作為指導(dǎo)方針，而非“鐵律”。我們只是想告訴你可能的做法。因此，如果有必要的話，你可以組合使用不同的流程

image.png

Gitflow工作流定義了一個(gè)圍繞項(xiàng)目發(fā)布的嚴(yán)格分支模型。雖然比功能分支工作流復(fù)雜幾分，但提供了用于一個(gè)健壯的用于管理大型項(xiàng)目的框架。
Gitflow工作流沒有用超出功能分支工作流的概念和命令，而是為不同的分支分配一個(gè)很明確的角色，并定義分支之間如何和什么時(shí)候進(jìn)行交互。除了使用功能分支，在做準(zhǔn)備、維護(hù)和記錄發(fā)布也使用各自的分支。當(dāng)然你可以用上功能分支工作流所有的好處：Pull Requests、隔離實(shí)驗(yàn)性開發(fā)和更高效的協(xié)作。

工作方式

Gitflow工作流仍然用中央倉庫作為所有開發(fā)者的交互中心。和其它的工作流一樣，開發(fā)者在本地工作并push分支到要中央倉庫中。

歷史分支

相對(duì)使用僅有的一個(gè)master分支，Gitflow工作流使用2個(gè)分支來記錄項(xiàng)目的歷史。master分支存儲(chǔ)了正式發(fā)布的歷史，而develop分支作為功能的集成分支。這樣也方便master分支上的所有提交分配一個(gè)版本號(hào)。

圖二

剩下要說明的問題圍繞著這2個(gè)分支的區(qū)別展開。

功能分支

每個(gè)新功能位于一個(gè)自己的分支，這樣可以push到中央倉庫以備份和協(xié)作。但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。當(dāng)新功能完成時(shí)，合并回develop分支。新功能提交應(yīng)該從不直接與master分支交互。

image.png

注意，從各種含義和目的上來看，功能分支加上develop分支就是功能分支工作流的用法。但Gitflow工作流沒有在這里止步。

發(fā)布分支

image.png

一旦develop分支上有了做一次發(fā)布（或者說快到了既定的發(fā)布日）的足夠功能，就從develop分支上fork一個(gè)發(fā)布分支。新建的分支用于開始發(fā)布循環(huán)，所以從這個(gè)時(shí)間點(diǎn)開始之后新的功能不能再加到這個(gè)分支上 —— 這個(gè)分支只應(yīng)該做Bug修復(fù)、文檔生成和其它面向發(fā)布任務(wù)。一旦對(duì)外發(fā)布的工作都完成了，發(fā)布分支合并到master分支并分配一個(gè)版本號(hào)打好Tag。另外，這些從新建發(fā)布分支以來的做的修改要合并回develop分支。

使用一個(gè)用于發(fā)布準(zhǔn)備的專門分支，使得一個(gè)團(tuán)隊(duì)可以在完善當(dāng)前的發(fā)布版本的同時(shí)，另一個(gè)團(tuán)隊(duì)可以繼續(xù)開發(fā)下個(gè)版本的功能。
這也打造定義良好的開發(fā)階段（比如，可以很輕松地說，『這周我們要做準(zhǔn)備發(fā)布版本4.0』，并且在倉庫的目錄結(jié)構(gòu)中可以實(shí)際看到）。

常用的分支約定：

用于新建發(fā)布分支的分支: develop

用于合并的分支: master

分支命名: release-* 或 release/*

維護(hù)分支

圖五

維護(hù)分支或說是熱修復(fù)（hotfix）分支用于生成快速給產(chǎn)品發(fā)布版本（production releases）打補(bǔ)丁，這是唯一可以直接從master分支fork出來的分支。修復(fù)完成，修改應(yīng)該馬上合并回master分支和develop分支（當(dāng)前的發(fā)布分支），master分支應(yīng)該用新的版本號(hào)打好Tag。

為Bug修復(fù)使用專門分支，讓團(tuán)隊(duì)可以處理掉問題而不用打斷其它工作或是等待下一個(gè)發(fā)布循環(huán)。你可以把維護(hù)分支想成是一個(gè)直接在master分支上處理的臨時(shí)發(fā)布。

示例

下面的示例演示本工作流如何用于管理單個(gè)發(fā)布循環(huán)。假設(shè)你已經(jīng)創(chuàng)建了一個(gè)中央倉庫。

創(chuàng)建開發(fā)分支

image.png

第一步為master分支配套一個(gè)develop分支。簡單來做可以本地創(chuàng)建一個(gè)空的develop分支，push到服務(wù)器上：

git branch develop
git push -u origin develop

以后這個(gè)分支將會(huì)包含了項(xiàng)目的全部歷史，而master分支將只包含了部分歷史。其它開發(fā)者這時(shí)應(yīng)該克隆中央倉庫，建好develop分支的跟蹤分支：

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

現(xiàn)在每個(gè)開發(fā)都有了這些歷史分支的本地拷貝。

工程師A和工程師B開始開發(fā)新功能

image.png

這個(gè)示例中，工程師A和工程師B開始各自的功能開發(fā)。他們需要為各自的功能創(chuàng)建相應(yīng)的分支。新分支不是基于master分支，而是應(yīng)該基于develop分支：

git checkout -b some-feature develop

他們用老套路添加提交到各自功能分支上：編輯、暫存、提交：

git status
git add
git commit

工程師A完成功能開發(fā)

image.png

添加了提交后，工程師A覺得她的功能OK了。如果團(tuán)隊(duì)使用Pull Requests，這時(shí)候可以發(fā)起一個(gè)用于合并到develop分支。否則她可以直接合并到她本地的develop分支后push到中央倉庫：

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一條命令在合并功能前確保develop分支是最新的。注意，功能決不應(yīng)該直接合并到master分支。沖突解決方法和集中式工作流一樣。

工程師A開始準(zhǔn)備發(fā)布

圖九

這個(gè)時(shí)候工程師B正在實(shí)現(xiàn)他的功能，工程師A開始準(zhǔn)備她的第一個(gè)項(xiàng)目正式發(fā)布。像功能開發(fā)一樣，她用一個(gè)新的分支來做發(fā)布準(zhǔn)備。這一步也確定了發(fā)布的版本號(hào)：

git checkout -b release-0.1 develop

這個(gè)分支是清理發(fā)布、執(zhí)行所有測試、更新文檔和其它為下個(gè)發(fā)布做準(zhǔn)備操作的地方，像是一個(gè)專門用于改善發(fā)布的功能分支。

只要工程師A創(chuàng)建這個(gè)分支并push到中央倉庫，這個(gè)發(fā)布就是功能凍結(jié)的。任何不在develop分支中的新功能都推到下個(gè)發(fā)布循環(huán)中。

工程師A完成發(fā)布

圖十

一旦準(zhǔn)備好了對(duì)外發(fā)布，工程師A合并修改到master分支和develop分支上，刪除發(fā)布分支。合并回develop分支很重要，因?yàn)樵诎l(fā)布分支中已經(jīng)提交的更新需要在后面的新功能中也要是可用的。另外，如果工程師A的團(tuán)隊(duì)要求Code Review，這是一個(gè)發(fā)起Pull Request的理想時(shí)機(jī)。

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

發(fā)布分支是作為功能開發(fā)（develop分支）和對(duì)外發(fā)布（master分支）間的緩沖。只要有合并到master分支，就應(yīng)該打好Tag以方便跟蹤。

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

Git有提供各種勾子（hook），即倉庫有事件發(fā)生時(shí)觸發(fā)執(zhí)行的腳本?？梢耘渲靡粋€(gè)勾子，在你push中央倉庫的master分支時(shí)，自動(dòng)構(gòu)建好對(duì)外發(fā)布。

最終用戶發(fā)現(xiàn)Bug

image.png

對(duì)外發(fā)布后，工程師A回去和工程師B一起做下個(gè)發(fā)布的新功能開發(fā)，直到有最終用戶開了一個(gè)Ticket抱怨當(dāng)前版本的一個(gè)Bug。為了處理Bug，工程師A（或工程師B）從master分支上拉出了一個(gè)維護(hù)分支，提交修改以解決問題，然后直接合并回master分支：

git checkout -b issue-#001 master

Fix the bug

git checkout master
git merge issue-#001
git push

就像發(fā)布分支，維護(hù)分支中新加這些重要修改需要包含到develop分支中，所以工程師A要執(zhí)行一個(gè)合并操作。然后就可以安全地刪除這個(gè)分支了：

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001

最后

Git是一個(gè)不錯(cuò)的版本管理工具，但也僅僅是工具。記住，這里演示的工作流只是可能用法的例子，而不是在實(shí)際工作中使用Git不可違逆的條例。所以不要畏懼按自己需要對(duì)工作流的用法做取舍。不變的目標(biāo)就是讓Git為你所用。