主要了解git的一些基本的團隊協(xié)作命令殉农，和GitFlow工作流指南

git 團隊協(xié)作的一些命令

• 1.開分支

git branch 新分支名
例如披摄，在master分支下行施，新開一個開發(fā)分支：
git branch dev

• 2.切換到新分支

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

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

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

• 4.切換回原分支

git checkout 原分支名
例如胆敞，切換回master
git checkout master
注意：當前分支有修改着帽，還未commit的時候杂伟，會切換失敗，應(yī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的形式來進行分支的合并和代碼審核予借。

• 6.查看本地分支列表

git branch -a
前面帶remotes/origin 的越平，是遠程分支

• 7.查看遠程分支列表

git branch -r

• 8.向遠程提交本地新開的分支

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

• 9.刪除遠程分支

git push origin --delete 遠程分支名
例如灵迫，刪除剛剛提交到遠程的dev分支：
git push origin --delete dev

• 10.刪除本地分支

git branch 分支名稱 -d
例如秦叛，在master分支下，刪除新開的dev分支：
git branch dev -d
注意：如果dev的更改瀑粥，push到遠程挣跋，在GitLab(或者其他git系統(tǒng))上面進行了merge操作，但是本地master沒有pull最新的代碼利凑，會刪除不成功浆劲，可以先git pull origin master，或者強制刪除
git branch dev -D

Git工作流指南：Gitflow工作流

在你開始閱讀之前哀澈，請記着平琛：流程應(yīng)被視作為指導(dǎo)方針，而非“鐵律”割按。我們只是想告訴你可能的做法膨报。因此，如果有必要的話适荣，你可以組合使用不同的流程

image.png

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

工作方式

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

歷史分支

相對使用僅有的一個master分支库倘，Gitflow工作流使用2個分支來記錄項目的歷史临扮。master分支存儲了正式發(fā)布的歷史论矾，而develop分支作為功能的集成分支。這樣也方便master分支上的所有提交分配一個版本號杆勇。

圖二

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

功能分支

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

image.png

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

發(fā)布分支

image.png

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

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

常用的分支約定：

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

用于合并的分支: master

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

維護分支

圖五

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

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

示例

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

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

image.png

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

git branch develop
git push -u origin develop

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

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

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

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

image.png

這個示例中膏蚓，工程師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了采郎。如果團隊使用Pull Requests，這時候可以發(fā)起一個用于合并到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開始準備發(fā)布

圖九

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

git checkout -b release-0.1 develop

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

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

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

圖十

一旦準備好了對外發(fā)布德迹，工程師A合并修改到master分支和develop分支上，刪除發(fā)布分支揭芍。合并回develop分支很重要胳搞，因為在發(fā)布分支中已經(jīng)提交的更新需要在后面的新功能中也要是可用的。另外，如果工程師A的團隊要求Code Review肌毅，這是一個發(fā)起Pull Request的理想時機筷转。

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分支）和對外發(fā)布（master分支）間的緩沖。只要有合并到master分支悬而，就應(yīng)該打好Tag以方便跟蹤呜舒。

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

Git有提供各種勾子（hook），即倉庫有事件發(fā)生時觸發(fā)執(zhí)行的腳本笨奠∠龋可以配置一個勾子，在你push中央倉庫的master分支時般婆，自動構(gòu)建好對外發(fā)布呻袭。

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

image.png

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

git checkout -b issue-#001 master

Fix the bug

git checkout master
git merge issue-#001
git push

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

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

最后

Git是一個不錯的版本管理工具连舍，但也僅僅是工具没陡。記住，這里演示的工作流只是可能用法的例子索赏，而不是在實際工作中使用Git不可違逆的條例盼玄。所以不要畏懼按自己需要對工作流的用法做取舍。不變的目標就是讓Git為你所用潜腻。