Git的工作方式

分為集中式工作流、功能分支工作流、Gitflow工作流和Forking，其中集中式工作流和功能分支工作流是已經使用過的，Gitflow和Forking兩種工作流暫時沒有使用過。

集中式工作流

一個遠程倉庫，一個主分支master，團隊每個成員都有一個本地倉庫，在本地倉庫中進行代碼的編輯、暫存和提交工作：

git add <some file> 或 git add .>
//`some file`代表要暫存的文件，`.`代表工作目錄下的所有文件
gie commit -m "一些描述"
//提交文，描述指的是本次提交修改了什么功能或者修改了什么bug，方便以后的查看
git push -u origin master
//-u選項設置本地分支去跟蹤遠程對應的分支。設置好跟蹤的分支后，就可以使用git push命令省去指定推送分支的參數(shù)
//發(fā)布本地倉庫到遠程的中央倉庫中，origin是遠程倉庫名，master是參數(shù)告訴Git的分支，master代表主分支，當然分支可以不是主分支

注意:在一種情況下push命令會出錯，即如果小明第一次發(fā)布代碼到遠程倉庫，此時小紅在 本地開發(fā)自己的功能，那么在小紅push自己的本地庫到遠程的時候會報錯，原因是小紅的本地庫和遠程庫有分歧，需要先pull遠程庫到本地，與本地庫合并之后再push到遠程庫。

功能分支工作流

在集中式工作流的基礎上，為各個新功能分配一個專門的分支來開發(fā)，即在master主分支外在創(chuàng)建一個分支，程序員開發(fā)的新功能全部push到此分支上，等到功能成熟的時候再把此分支合并到主分支master上

git checkout -b newbranch master
//checkout代表創(chuàng)建切換帶新分支newbranch
//-b代表如果新分支不存在則會創(chuàng)建一個新分支
//最后的master代表新分支是基于主分支創(chuàng)建的

新分支創(chuàng)建之后，對其的編輯、暫存和提交工作與之前一樣，對其push的命令變?yōu)?/p>

git push origin newbranch

等到新功能完善之后，通過以下命令：

git checkout mastergit pullgit pull origin newbranchgit push

首先git checkout master切換到主分支，然后執(zhí)行git pull把本地倉庫的主分支上傳到遠程庫，再執(zhí)行git pull origin newbranch保證合并newbranch分支和已經和遠程一致的本地master分支，你可以使用簡單git merge newbranch命令，但前面的命令可以保證總是最新的新功能分支。 最后把更新的master分支重新push到遠程庫。

Gitflow工作流

Gitflow工作流沒有用超出功能分支工作流的概念和命令，而是為不同的分支分配一個很明確的角色，并定義分支之間如何和什么時候進行交互。
除了有master主分支（用于存儲正式發(fā)布的歷史）外，還有一個作為功能集成分支的develop分支。當初始化完成后，某個程序員想要開發(fā)一個性能，并不是直接從master分支上拉出新分支，而是使用develop分支作為父分支，當新功能完成后，再合并會父分支，新功能的提交并不與master分支直接交互。

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

維護分支

維護分支或說是熱修復（hotfix）分支用于生成快速給產品發(fā)布版本（production releases）打補丁，這是唯一可以直接從master分支fork出來的分支。 修復完成，修改應該馬上合并回master分支和develop分支（當前的發(fā)布分支），master分支應該用新的版本號打好Tag。
為Bug修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個發(fā)布循環(huán)。 你可以把維護分支想成是一個直接在master分支上處理的臨時發(fā)布。

工作流程

為master分支配套一個develop分支

git branch develop
git push -u origin develop

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

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

現(xiàn)在每個開發(fā)都有了這些歷史分支的本地拷貝。
小紅和小明開團隊成員始各自的功能開發(fā)。他們需要為各自的功能創(chuàng)建相應的分支。新分支不是基于master分支，而是應該基于develop分支：

git checkout -b some-feature develop

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

git status
git add <some-file>
git commit

添加了提交后，功能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分支是最新的。注意，功能決不應該直接合并到master分支。 沖突解決方法和集中式工作流一樣。

Forking工作流

分布式工作流，充分利用了Git在分支和克隆上的優(yōu)勢，既可以管理大團隊的開發(fā)者（developer）和接受不信任貢獻者（contributor）的提交。這種工作流使得每個開發(fā)者都有一個服務端倉庫（此倉庫只有自己可以push，但是所有人都可以pull修改），每個程序員都push代碼到自己的服務端倉庫，但不能push到正式倉庫，只有項目維護者才能push到正式倉庫，這樣項目維護者可以接受任何開發(fā)者的提交，但無需給他正式代碼庫的寫權限。
這種工作流適合網上開源社區(qū)的開源項目，大家統(tǒng)一對項目做貢獻，但是有一個人或一個團隊作為開發(fā)者來管理項目，所有的貢獻者的代碼由開發(fā)者審核，其功能完善之后再由開發(fā)者push到正式倉庫中。

Pull Request

Pull Request是一個為討論提交功能的專門論壇，是一個友好的web界面（在個人github項目中也有這樣一個選項），大家在其中做一些Code Review的工作，把結果反饋到Pull Request中，還可以在其中push新的提交微調功能，等到討論結束后醒目維護者合并所有的功能到官方倉庫中，關閉Pull Request。

發(fā)起一個Pull Request，就是要請求另一個開發(fā)者來pull自己倉庫的一個分支到它的倉庫中，因此需要提供四個信息：源倉庫、源分支、目的倉庫、目的分支。

Pull Request可以用于上述除了集中式工作流的其他三種工作流，因為其要求要么分支不同，要么倉庫不同，而集中式工作流只有一個倉庫，一個master分支。

例：

在功能分支工作流中使用Pull Request

功能分支工作流只有一個公開的倉庫，所以Pull Request的目的倉庫和源倉庫總是同一個。 通常開發(fā)者會指定他的功能分支作為源分支，master分支作為目的分支。

收到Pull Request后，項目維護者要決定如何做。如果功能沒問題，就簡單地合并到master分支，關閉Pull Request。但如果提交的變更有問題，他可以在Pull Request中反饋。之后新加的提交也會評論之后接著顯示出來。

在功能還沒有完全開發(fā)完的時候，也可能發(fā)起一個Pull Request。 比如開發(fā)者在實現(xiàn)某個需求時碰到了麻煩，他可以發(fā)一個包含正在進行中工作的Pull Request。 其它的開發(fā)者可以在Pull Request提供建議，或者甚至直接添加提交來解決問題。

參考：http://shouce.jb51.net/gitbook/Distributed-Git/Distributed-Workflows.html

以上就是Git工作流模式及命令的使用講解的詳細內容，更多關于Git的工作流模式命令使用的資料請關注腳本之家其它相關文章！

最新評論