一.Git簡介

Git是目前世界上最先進(jìn)的分布式版本控制系統(tǒng)。它就沒有中央服務(wù)器的，每個人的電腦就是一個完整的版本庫，這樣，工作的時候就不需要聯(lián)網(wǎng)了，因為版本都是在自己的電腦上。
完成開發(fā)以后再將各自的修改推送給對方，就可以互相看到對方的修改了(為了便于項目中的所有開發(fā)者分享代碼，我們將代碼存放遠(yuǎn)程 Git 倉庫例如github)。與此對應(yīng)的是SVN是集中式版本控制系統(tǒng)，
版本庫是集中放在中央服務(wù)器的，而干活的時候，用的都是自己的電腦，所以首先要從中央服務(wù)器哪里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服務(wù)器。而且集中式版本控制系統(tǒng)是必須聯(lián)網(wǎng)才能工作。

二.Git文件狀態(tài)

• Untracked: 未跟蹤, 此文件在文件夾中, 但并沒有加入到git庫, 不參與版本控制. 通過git add 狀態(tài)變?yōu)?code>Staged
• Unmodify: 文件已經(jīng)入庫, 未修改, 即版本庫中的文件快照內(nèi)容與文件夾中完全一致. 這種類型的文件有兩種去處, 如果它被修改, 而變?yōu)?code>Modified. 如果使用git rm移出版本庫, 則成為Untracked文件
• Modified: 文件已修改, 僅僅是修改, 并沒有進(jìn)行其他的操作. 這個文件也有兩個去處, 通過git add可進(jìn)入暫存staged狀態(tài), 使用git checkout 則丟棄修改過, 返回到unmodify狀態(tài), 這個git checkout即從庫中取出文件, 覆蓋當(dāng)前修改
• Staged: 暫存狀態(tài). 執(zhí)行git commit則將修改同步到庫中, 這時庫中的文件和本地文件又變?yōu)橐恢? 文件為Unmodify狀態(tài). 執(zhí)行git reset HEAD filename取消暫存, 文件狀態(tài)為Modified
  

三.Git常見命令

1.設(shè)置相關(guān)

• git config --list查看配置
• git config user.name查看用戶名
• git config user.email查看郵箱
• git config --global user.name "nameVal"配置全局用戶名
• git config --global user.email "eamil@qq.com"配置全局郵箱
• git config --global credential.helper store全局緩存登錄憑證
• git config user.name “xxxx”配置單個項目用戶名(需進(jìn)入到項目文件夾根目錄里面)
• git config user.email "xxxx@xx.com"配置單個項目郵箱(需進(jìn)入到項目文件夾根目錄里面)
• git config –global credential.helper cache 設(shè)置記住密碼（默認(rèn)15分鐘）
• git config credential.helper ‘cache –timeout=3600’設(shè)置記住密碼自定義過期時間（這里設(shè)置一個小時之后失效）
• git config –global credential.helper store設(shè)置記住密碼長期存儲
• git config --global credential.helper wincred清除緩存登錄憑證
• git credential-manager uninstall清除緩存在git中的用戶名和密碼
• git version查看git軟件的版本號。

2.創(chuàng)建

• git init初始化
• git clone git@git... .git克隆項目(git:// 協(xié)議)
• git clone http://... .git克隆項目(http(s)://)
• git clone http://郵箱（或用戶名）:密碼@倉庫地址指定郵箱或者用戶名克隆項目,如果用戶名或者郵箱及密碼中包含了@符號，所以需要把@轉(zhuǎn)碼一下代替:@-->%40
• git clone -b 要clone的分支名 倉庫地址克隆指定分支的項目.

3.添加到暫存區(qū)及提交

• git add readme.txt將文件提交到暫存區(qū)
• git add .把工作區(qū)域內(nèi)的所有變化提交到暫存區(qū)，包括文件內(nèi)容修改(modified)以及新文件(new)，但不包括被刪除的文件。
• git add -u僅監(jiān)控已經(jīng)被add的文件（即tracked file）將被修改的文件提交到暫存區(qū)。add -u 不會提交新文件（untracked file）。（git add --update的縮寫）
• git add -A是上面兩個的合集,提交所有變化。（git add --all的縮寫）
• git commit -m "first"提交到版本庫
• git status狀態(tài)查看(查看工作目錄中的狀態(tài)例如:有沒有沒被提交的文件之類的)

4.刪除

• git rm 我的文件在本地倉庫刪除文件
• git rm -r 我的文件夾/在本地倉庫刪除文件夾 此處-r表示遞歸所有子目錄，如果你要刪除的，是空的文件夾，此處可以不用帶上-r。

刪除的文件可以通過 git reset head file 和git checkout file恢復(fù).

5.branch(分支)

• git branch [branch-name]新建一個分支，但依然停留在當(dāng)前分支
• git checkout -b [branch-name]新建一個分支，并切換到該分支
• git branch 列出所有的分支(所有本地分支)
• git branch -r 列出所有的分支(所有遠(yuǎn)程分支)
• git branch -a 列出所有的分支(所有本地和遠(yuǎn)程分支)
• git checkout [branchname]切換到指定分支，并更新工作區(qū)
• git branch -d [branchname]刪除本地分支
• git push origin --delete [branchName]刪除遠(yuǎn)程分支
• git branch -m [oldname] [newName]分支重命名
• git reflog --date=local | grep nikeglass查看當(dāng)前分支的父分支
• git merge [branchname] 將branchname分支上的修改合并到當(dāng)前分支上
• git rebase [branchname] 對當(dāng)前分支基于branchname進(jìn)行變基操作

6.遠(yuǎn)程分支.

• git checkout -b [分支名] [遠(yuǎn)程名]/[分支名] 在本地建立分支并和遠(yuǎn)程分支同步

• git remote add origin [遠(yuǎn)程git地址]本地項目關(guān)聯(lián)遠(yuǎn)程倉庫(origin 是默認(rèn)的遠(yuǎn)程版本庫名稱,添加多個不同的遠(yuǎn)端需要不同的標(biāo)識)

• git remote列出所有關(guān)聯(lián)的遠(yuǎn)端倉庫.

• git remote update origin --prune更新遠(yuǎn)程分支列表

• git remote -v列出所有關(guān)聯(lián)的遠(yuǎn)端倉庫(詳細(xì)信息).

• git remote rm origin:origin(遠(yuǎn)程關(guān)聯(lián)倉庫的別稱)刪除關(guān)聯(lián)的遠(yuǎn)程倉庫。

• fetch+merge 拉取遠(yuǎn)程倉庫與本地倉庫進(jìn)行合并(git fetch 相當(dāng)于是從遠(yuǎn)程獲取最新到本地，不會自動merge)

  git fetch origin master //將遠(yuǎn)程倉庫的master分支下載到本地當(dāng)前branch中
  git log -p master...origin/master //比較本地的master分支和origin/master分支的差別
  git merge origin/master //進(jìn)行合并
  

• git pull origin master相當(dāng)于是從遠(yuǎn)程獲取最新版本并merge到本地。

• git push <遠(yuǎn)程主機(jī)名> <本地分支名>:<遠(yuǎn)程分支名>推送到遠(yuǎn)程倉庫.如果當(dāng)前分支只有一個追蹤分支，那么主機(jī)名和后面都都可以省略:git push。
  如果當(dāng)前分支與多個主機(jī)存在追蹤關(guān)系，那么這個時候-u選項會指定一個默認(rèn)主機(jī)，這樣后面就可以不加任何參數(shù)使用git push:git push -u origin(遠(yuǎn)程主機(jī)名) master:master(本地分支名:遠(yuǎn)程分支名)。

• git pull origin master --allow-unrelated-histories分支進(jìn)行強(qiáng)行合并

git fetch和git pull 區(qū)別: fetch 和 pull 的不同: fetch 相當(dāng)于是從遠(yuǎn)程獲取最新版本到本地，不會自動merge，所以本地倉庫的代碼還未被更新，
然后比較本地分支和遠(yuǎn)程分支的差別,最后通過 git merge origin/master 來合并這兩個版本，可以把它理解為合并分支一樣的。
pull 相當(dāng)于是從遠(yuǎn)程獲取最新版本并merge到本地(相當(dāng)于git fetch 和 git merge)。如果想要更加可控一點的話推薦使用fetch + merge,因為
git fetch更安全一些,在merge前，我們可以查看更新情況，然后再決定是否合并

7.標(biāo)簽

• git tag 列出所有tag
• git show [tag]查看tag信息
• git tag [tagname]打輕量標(biāo)簽
• git tag -a [tagname] -m [message]打標(biāo)簽并附注標(biāo)簽(例如，打v1.0標(biāo)簽git tag -a v1.0 -m 'v1.0 release')
• git tag -a [tagname] [commit_id]對過去的提交打標(biāo)簽
• git tag -d [tagname]刪除本地tag
• git push origin --delete tag <tagname>刪除遠(yuǎn)程tag
• git push [remote] [tag]提交指定tag(例如，將v1.0標(biāo)簽推送到遠(yuǎn)程服務(wù)器上git push origin v1.0)
• git push [remote] --tags提交所有tag
• git checkout [tagname]切換到對應(yīng)標(biāo)簽狀態(tài)(這時候 git 可能會提示你當(dāng)前處于一個“detached HEAD" 狀態(tài)。 因為 tag 相當(dāng)于是一個快照，是不能更改它的代碼的。如果要在 tag 代碼的基礎(chǔ)上做修改，你需要一個分支：git checkout -b [branchname] [tagname])

8.日志

• git log每一次操作記錄
• git reflog可以查看所有分支的所有操作記錄（包括（包括commit和reset的操作），包括已經(jīng)被刪除的commit記錄，git log則不能察看已經(jīng)刪除了的commit記錄，而且跟進(jìn)結(jié)果可以回退到某一個修改。
• git log --oneline --graph 查看歷史中什么時候出現(xiàn)了分支、合并
• git diff比較工作區(qū)和暫存區(qū)的所有文件差異變化
• git diff <file name>比較工作區(qū)和暫存區(qū)的指定文件的差異
• git diff --stat比較工作區(qū)和暫存區(qū)的所有文件變化列表
• git shortlog -n- 按每位作者的提交次數(shù)排序分組輸出。
• git show commit_id查看某個提交的詳細(xì)

8.撤銷修改版本回溯

• git checkout -- file丟棄工作區(qū)內(nèi)文件的修改(例如:git checkout -- readme.md)
• git checkout .放棄對工作區(qū)內(nèi)所有的文件修改

命令git checkout -- readme.txt意思就是，把readme.txt文件在工作區(qū)的修改全部撤銷，這里有兩種情況：一種是readme.txt自修改后還沒有被add到暫存區(qū)，現(xiàn)在，撤銷修改就回到和之前版本庫一模一樣的狀態(tài)；
一種是readme.txt已經(jīng)添加add到暫存區(qū)后，又作了修改，現(xiàn)在，撤銷修改就回到添加到暫存區(qū)后的狀態(tài)?？傊?，就是讓這個文件回到最近一次git commit或git add時的狀態(tài)。

• git reset HEAD <file>撤銷已經(jīng)add到暫存區(qū)的文件.
• git reset HEAD .撤銷所有的已經(jīng)add到暫存區(qū)的文件.

如果文件已經(jīng)被add到暫存區(qū),再使用git checkout是沒有用的.此時應(yīng)該使用git reset HEAD將文件撤銷添加到暫存區(qū)的操作,然后再使用git checkout操作讓文件恢復(fù)到最近一次commit.

• git reset --hard HEAD^ 回退到上個版本
• git reset --hard commit_id 退到/進(jìn)到 指定commit_id

撤銷修改分為三種情況

情況一:未使用 git add 緩存代碼時:
放棄單個文件修改git checkout -- filepathname,注意不要忘記中間的"--",不寫就成了檢出分支了! 放棄所有的文件修改git checkout .

情況二:已經(jīng)使用了 git add 緩存了代碼:
可以使用 git reset HEAD filepathname （比如： git reset HEAD readme.md）來放棄指定文件的緩存，放棄所有的緩存可以使用 git reset HEAD .**`` 命令。此命令用來清除 git對于文件修改的緩存。相當(dāng)于撤銷 git add 命令所在的工作。

情況三:已經(jīng)用 git commit 提交了代碼:
可以使用 git reset --hard HEAD^來回退到上一次commit的狀態(tài)。此命令可以用來回退到任意版本：git reset --hard commitid

三.Git忽略

1.使用.gitignore文件

在git中如果想忽略掉某個文件，不讓這個文件提交到版本庫中，可以使用修改根目錄中 .gitignore 文件的方法（如無，則需自己手工建立此文件）。

創(chuàng)建.gitignore

touch .gitignore打開 Git Bash->導(dǎo)航到 Git 倉庫的位置->為倉庫創(chuàng)建.gitignore文件

.gitignore匹配規(guī)則

  # 此為注釋 – 將被 Git 忽略
  *.a   # 忽略所有 .a 結(jié)尾的文件
  !lib.a# 但 lib.a 除外
  /TODO # 僅僅忽略項目根目錄下的 TODO 文件，不包括 subdir/TODO
  build/# 忽略 build/ 目錄下的所有文件
  doc/*.txt # 會忽略 doc/notes.txt 但不包括 doc/server/arch.txt 

.gitignore不生效問題

把某些目錄或文件加入忽略規(guī)則，按照上述方法定義后發(fā)現(xiàn)并未生效，原因是.gitignore只能忽略那些原來沒有被追蹤的文件，如果某些文件已經(jīng)被納入了版本管理中，僅修改.gitignore是無效的。
所以如果需要忽略的文件已經(jīng)提交到本地倉庫，則需要從本地倉庫中刪除掉該文件，如果已經(jīng)提交到遠(yuǎn)端倉庫，則需要從遠(yuǎn)端倉庫中刪除該文件，.gitignore文件才能實際生效。
解決方法就是先把本地緩存刪除（改變成未被追蹤狀態(tài)），然后再提交(push)，這樣就不會出現(xiàn)忽略的文件了。git清除本地緩存命令如下：

  git rm -r --cached .              去掉已經(jīng)托管的所有文件
  git add .                         添加文件 
  git commit -m '本地提交的comment'   提交

2.忽略本地修改

• 本地開發(fā)中需要用的文件，不能提交到遠(yuǎn)程，但是還不能寫入.gitignore文件。
• 遠(yuǎn)程倉庫里已存在的文件,在本地進(jìn)行修改了.但是不想提交到遠(yuǎn)程倉庫里面去(例如一些編輯器的配置文件,不同版本的編輯器配置文件可能不同.但是初始化倉庫時沒有做好.gitignore的配置導(dǎo)致配置文件被添加到版本庫里面了
  此時,要么在.gitignore里面添加忽略規(guī)則再把緩存修改)。

git update-index --assume-unchanged /XX/XX/XXX.file 本地忽略單個文件

git ls-files -z | xargs -0 git update-index --assume-unchanged進(jìn)入文件夾中(忽略文件夾中所有的文件)

git ls-files -v | grep '^h\ '找出所有被忽略的文件

git ls-files -v | grep '^h\ ' | awk '{print $2}'找出所有被忽略的文件路徑

git update-index –no-assume-unchanged –path /XX/XX/XXX.file 取消單個忽略文件

git ls-files -v | grep '^h' | awk '{print $2}' |xargs git update-index --no-assume-unchanged取消所有被忽略的文件

注意: 這種方式也有一個副作用，如果本地被忽略的該文件在本地被修改了，遠(yuǎn)程的該文件也被其他人修改了。那在拉取遠(yuǎn)程分支時，由于本地和遠(yuǎn)程文件存在不一致的更新，會導(dǎo)致拉取不成功的問題。此時應(yīng)該先取消文件忽略，再進(jìn)行拉取操作。

四.Git分支合并

merge兩種模式

merge一般有兩種模式:

• Fast forward模式
  通常，合并分支時，如果沒有分歧解決，就會直接移動文件指針，這就是Fast forward模式，也是merge默認(rèn)的模式。

舉例來說，開發(fā)一直在master分支進(jìn)行，但忽然有一個新的想法，于是新建了一個dev的分支，并在其上進(jìn)行一系列提交，完成時，回到master分支，
此時，master分支在創(chuàng)建dev分支之后并未產(chǎn)生任何新的commit。master分支合并dev分支并不會產(chǎn)生新的commit. 以后當(dāng)合并分支被刪除時，也就不知道對應(yīng)的提交是來自于哪個分支。
此時的合并就叫fast forward。如果想在這樣的的情況下也自動生成一個commit，記錄此次合并就可以用：git merge --no-ff模式。

• --no-ff模式
  git merge --no-ff -m "merge with no-ff" dev因為本次合并要創(chuàng)建一個新的commit，所以加上-m參數(shù)，把commit描述寫入。
  

總結(jié)：fast forward能夠保證不會強(qiáng)制覆蓋別人的代碼，確保了多人協(xié)同開發(fā)。盡量不要使用non fast forward方法提交代碼。

merge沖突問題

git沖突的場景:

• 情景一：多個分支代碼合并到一個分支時；
• 情景二：多個分支向同一個遠(yuǎn)端分支推送代碼時；
  實際上，push操作即是將本地代碼merge到遠(yuǎn)端庫分支上。push和pull其實就分別是用本地分支合并到遠(yuǎn)程分支 和 將遠(yuǎn)程分支合并到本地分支 所以這兩個過程中也可能存在沖突。

git的合并中產(chǎn)生沖突的具體情況：

1. 兩個分支中修改了同一個文件（不管什么地方）
2. 兩個分支中修改了同一個文件的名稱
   兩個分支中分別修改了不同文件中的部分，不會產(chǎn)生沖突，可以直接將兩部分合并。

merge解決沖突

1. 先本地直接提交代碼：git push origin master
2. 如果別人在自己之前提交了修改，git會提示push失敗，需要先pull遠(yuǎn)程代碼：git pull origin/master
3. （拉取遠(yuǎn)程倉庫進(jìn)行自動合并） 如果能自動合并，git會提示auto merge成功，這時可以直接git push origin master如果不能自動merge，git會提示auto merge失敗，
4. 需要手動解決沖突：git status 查看沖突情況修改沖突git status 查看沖突解決情況git add .git commit -m '解決沖突的注釋說明'git push origin master

避免產(chǎn)生沖突

現(xiàn)代軟件開發(fā)項目中，代碼沖突是不可避免的，但我們應(yīng)該盡量減少沖突的產(chǎn)生，避免不必要的沖突。下面列舉一下實踐經(jīng)驗：

1. 工作在不同的分支上，并經(jīng)常性的同步主代碼，如果由于項目要求，比如長期開發(fā)一個功能使得該功能代碼在開發(fā)完成之前合并到主分支，此時我們雖然沒有辦法經(jīng)常合并代碼到主分支，也至少需要經(jīng)常性的同步主分支代碼到開發(fā)分支上
   ，避免在最終合并到主分支上時產(chǎn)生過多沖突。
2. 盡量使用短生命周期分支而非長期分支。
3. 除了技術(shù)層面的手段，也可以通過項目管理上的手段來盡量避免，例如：不要同時將相同組件開發(fā)的不同任務(wù)分給不同的開發(fā)者，否則在合并代碼時該組件將會產(chǎn)生過多的沖突。
   各組件開發(fā)小組之間經(jīng)常性的溝通，互相了解各自的開發(fā)狀態(tài)，在可能產(chǎn)生沖突的時候及時采取手段。

merge和rebase(變基)

merge 會把公共分支和你當(dāng)前的commit 合并在一起，形成一個新的 commit 提交:

rebase會把你當(dāng)前分支的 commit 放到公共分支的最后面,所以叫變基。就好像你從公共分支又重新拉出來這個分支一樣。
舉例:如果你從 master 拉了個feature分支出來,然后你提交了幾個 commit,這個時候剛好有人把他開發(fā)的東西合并到 master 了,
這個時候 master 就比你拉分支的時候多了幾個 commit,如果這個時候你 rebase master 的話，就會把你當(dāng)前的幾個 commit，放到那個人 commit 的后面。此時切換到master分支再用merge進(jìn)行合并即可.

優(yōu)點

• rebase最大的好處是你的項目歷史會非常整潔
• rebase 導(dǎo)致最后的項目歷史呈現(xiàn)出完美的線性——你可以從項目終點到起點瀏覽而不需要任何的 fork。這讓你更容易使用 git log、git bisect 和 gitk 來查看項目歷史
  缺點
• 安全性，如果你違反了 rebase 黃金法則，重寫項目歷史可能會給你的協(xié)作工作流帶來災(zāi)難性的影響

• 可跟蹤性，rebase 不會有合并提交中附帶的信息——你看不到 feature 分支中并入了上游的哪些更改

  
  

1. 可以看出merge結(jié)果能夠體現(xiàn)出時間線，但是rebase會打亂時間線。
2. 而rebase看起來簡潔，但是merge看起來不太簡潔。
3. 最終結(jié)果是都把代碼合起來了，所以具體怎么使用這兩個命令看項目需要。

注意:

1. 不要在公共分支使用rebase
2. 本地和遠(yuǎn)端對應(yīng)同一條分支,優(yōu)先使用rebase,而不是merge

五.Git暫存與恢復(fù)

git stash命令作用

1. 當(dāng)正在dev分支上開發(fā)某個項目，這時項目中出現(xiàn)一個bug，需要緊急修復(fù)，但是正在開發(fā)的內(nèi)容只是完成一半，還不想提交，這時可以用git stash命令將修改的內(nèi)容保存至堆棧區(qū)，
   然后順利切換到hotfix分支進(jìn)行bug修復(fù)，修復(fù)完成后，再次切回到dev分支，從堆棧中恢復(fù)剛剛保存的內(nèi)容。
2. 由于疏忽，本應(yīng)該在dev分支開發(fā)的內(nèi)容，卻在master上進(jìn)行了開發(fā)，需要重新切回到dev分支上進(jìn)行開發(fā)，可以用git stash將內(nèi)容保存至堆棧中，切回到dev分支后，再次恢復(fù)內(nèi)容即可。

git stash命令的作用就是將目前還不想提交的但是已經(jīng)修改的內(nèi)容進(jìn)行保存至堆棧中，后續(xù)可以在某個分支上恢復(fù)出堆棧中的內(nèi)容。這也就是說，stash中的內(nèi)容不僅僅可以恢復(fù)到原先開發(fā)的分支，也可以恢復(fù)到其他任意指定的分支上。
git stash作用的范圍包括工作區(qū)和暫存區(qū)中的內(nèi)容，也就是說沒有提交的內(nèi)容都會保存至堆棧中。

• git stash能夠?qū)⑺形刺峤坏男薷模üぷ鲄^(qū)和暫存區(qū)）保存至堆棧中，用于后續(xù)恢復(fù)當(dāng)前工作目錄。
• git stash save "notes"作用等同于git stash，區(qū)別是可以加一些注釋
• git stash list查看當(dāng)前stash中的內(nèi)容
• git stash pop id將當(dāng)前stash中的內(nèi)容彈出，并應(yīng)用到當(dāng)前分支對應(yīng)的工作目錄上,id是可選項，默認(rèn)時上一次暫存,通過git stash list可查看具體值。只能恢復(fù)一次.
• git stash apply id將堆棧中的內(nèi)容應(yīng)用到當(dāng)前目錄，不同于git stash pop，該命令不會將內(nèi)容從堆棧中刪除，可以恢復(fù)多次.也就說該命令能夠?qū)⒍褩５膬?nèi)容多次應(yīng)用到工作目錄中，適應(yīng)于多個分支的情況。
• git stash drop stash id 刪除某個保存，id是可選項，通過git stash list可查看具體值
• git stash clear 刪除所有保存的快照

六.Git去除大文件

1. 首先找出git中前五大的文件：

   git verify-pack -v .git/objects/pack/pack-*.idx | sort -k 3 -g | tail -5
   

   或者:

   git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk '{print$1}')"
   

   或者:

   git rev-list --all | xargs -rL1 git ls-tree -r --long | sort -uk3 | sort -rnk4 | head -10
   

2. 用第一步文件的id找出文件名：

   git rev-list --objects --all | grep fileId 
   

3. 刪除文件提交記錄

   git filter-branch --index-filter 'git rm --cached --ignore-unmatch <your-file-name>'
   rm -rf .git/refs/original/
   git reflog expire --expire=now --all
   git fsck --full --unreachable
   git repack -A -d
   git gc --aggressive --prune=now
   git push --force 
   

七.Git Flow(版本管理工作流)

Git 作為一個源碼管理系統(tǒng)，不可避免涉及到多人協(xié)作。為了避免協(xié)作過程中產(chǎn)生混亂，必須有一個規(guī)范的工作流程，讓大家有效地合作，使得項目井井有條地發(fā)展下去。Gitflow是基于Git的強(qiáng)大分支能力所構(gòu)建的一套軟件開發(fā)工作流，這些流程應(yīng)被視作為指導(dǎo)方針，而非“鐵律”。Gitflow使用多個分支來記錄項目開發(fā)的歷史，而不是使用單一的master分支。

1.主要分支

主要分支包括Master和Develop，前者用于正式發(fā)布，后者用于日常開發(fā)。常設(shè)分支只需要這兩條就夠了，不需要其他的了。

Master分支（主）:

Git主分支的名字，默認(rèn)叫做Master。該分支上的代碼隨時可以部署到生產(chǎn)環(huán)境， 這個分支只能從其他分支合并，并且不能在這個分支做任何直接修改。每次版本封版后由主程序員合并release分支代碼進(jìn)來，發(fā)布完成以后打上tag，開發(fā)人員不可以隨意操作。

develop分支（開發(fā)）：

用來開發(fā)的分支，通?？梢灾苯釉谄渖线M(jìn)行開發(fā)，在每次發(fā)布版本（release）和線上緊急bug（hotfix）修復(fù)后，需要同步到其上。理論上此版本只在開發(fā)階段使用，提測時不可以直接修改，而在測試結(jié)束后由release分支合并到其上。如果想正式對外發(fā)布，就在Master分支上，對Develop分支進(jìn)行"合并"（merge）。

2.臨時性分支

除了常設(shè)分支以外，還有一些臨時性分支，用于應(yīng)對一些特定目的的版本開發(fā)。臨時性分支主要有三種：功能分支 （feature），預(yù)發(fā)布分支 (release)，修補bug分支 (fixbug)，這三種分支都屬于臨時性需要，使用完以后，應(yīng)該刪除，使得代碼庫的常設(shè)分支始終只有Master和Develop。

release分支（預(yù)發(fā)布）：

在發(fā)布正式版本之前（即develop合并到Master分支之前），我們可能需要有一個預(yù)發(fā)布的版本進(jìn)行測試。預(yù)發(fā)布分支是從Develop分支上面分出來的，所有測試階段的bug全部在此分支修復(fù)，測試結(jié)束后，必須合并進(jìn)Develop和Master分支。它的命名，可以采用release-xx的形式。

feature分支（功能）：

為了開發(fā)某種特定功能，從Develop分支上面分出來的。開發(fā)完成后，要再并入Develop。功能分支的名字，可以采用feature-XX的形式命名。如果在團(tuán)隊開發(fā)時，有一個功能的開發(fā)周期要長過本次版本開發(fā)周期，建議開啟一個 feature 進(jìn)行單獨開發(fā)，當(dāng)需要此功能的時候，只需要將 feature 合并入 develop 分支，下次一并提測即可。這樣設(shè)計可以避免這個功能在尚未開發(fā)完成或者通過測試的時候混入發(fā)布的版本，而導(dǎo)致不可預(yù)知的不穩(wěn)定。當(dāng)然也可以同時開啟多個 feature 分支進(jìn)行不同新功能開發(fā)，在合適的時候合并提測即可。

hotfix分支（bug修復(fù)）：

軟件正式發(fā)布以后，難免會出現(xiàn)bug。這時就需要創(chuàng)建一個分支，進(jìn)行bug修補。修補bug分支是從Master分支上面分出來的。修補結(jié)束以后，再合并進(jìn)Master和Develop分支。它的命名，可以采用fixbug-XX的形式。線上bug修復(fù)的熱補丁分支，應(yīng)由 master 拉出，并在修復(fù)完成后合并入 master 和 develop 保證兩分支的bug已修復(fù)。

3.新功能開發(fā)中，各角色的工作流程

（1.）前置階段(新功能啟動)

開發(fā)主管--》基于master主干創(chuàng)建一個develop分支。

現(xiàn)有主干分支: master、develop

（2.）開發(fā)階段(開始開發(fā))

功能開發(fā)人員--》基于develop分支創(chuàng)建一個feature_XX分支

功能開發(fā)人員--》在feature_XX分支上開發(fā)新功能

功能開發(fā)人員--》新功能開發(fā)完成以后，在git上發(fā)起Pull request把代碼合并到到develop分支上

開發(fā)主管--》確認(rèn)代碼沒問題，通過該合并請求

現(xiàn)有主干分支: master、develop、feature_XX

（3.）測試階段(開發(fā)完畢)

開發(fā)主管--》基于develop分支創(chuàng)建一個分支名為release-1.0.0的預(yù)發(fā)布版本

測試人員--》對release-1.0.0分支的代碼進(jìn)行測試，測試通過在git發(fā)起Pull request把release-1.0.0代碼合并到到master分支上。

現(xiàn)有主干分支: master、develop、feature_XX、release-1.0.0

（4.）發(fā)布階段(測試通過)

開發(fā)主管--》基于master分支創(chuàng)建一個里程碑版本(tag)名為1.0.0-Release

刪除完成使命的其他分支:feature_login、release-1.0.0

現(xiàn)有主干分支: master、develop、1.0.0-Release(tag)

4.線上代碼出現(xiàn)bug時，各角色的工作流程

（1）前置階段(提交bug)

測試人員--》發(fā)下問題，基于1.0.0-Release里程碑版本在git上新建一個issue

現(xiàn)有主干分支: master、develop、1.0.0-Release(tag)

（2）修復(fù)階段(開始修復(fù)bug)

功能開發(fā)人員--》基于1.0.0-Releasetag創(chuàng)建一個hotfix_XX(該issue序號)分支，在hotfix_XX分支上修復(fù)bug，修復(fù)完成后，在git上發(fā)起Pull request把代碼合并到到master主干上

開發(fā)主管--》確認(rèn)代碼沒問題，通過該合并請求

現(xiàn)有主干分支: master、develop、1.0.0-Release(tag)、hotfix_0001

（3）測試階段(bug修復(fù)完畢)

測試人員--》對master分支的代碼進(jìn)行測試

現(xiàn)有主干分支: master、develop、1.0.0-Release(tag)、hotfix_0001

（4）發(fā)布階段(測試通過)

開發(fā)主管--》基于master分支創(chuàng)建一個里程碑修復(fù)版本(tag)名為1.0.1-Release，刪除完成使命的其他分支:hotfix_XX

現(xiàn)有主干分支: master、develop、1.0.0-Release(tag)、1.0.1-Release(tag)

八.常見問題.

第一次輸入錯誤的gitlab用戶名和密碼，第二次clone不彈框提示輸入用戶名和密碼的解決方案。

git clone remote: HTTP Basic: Access denied

方式一:在控制面板里面將憑證刪除.

方式二:使用git命令重置憑證.

git config --system --unset credential.helper
git config --global credential.helper store