Git工作流模式及命令怎么使用

今天小編給大家分享一下Git工作流模式及命令怎么使用的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

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命令省去指定推送分支的參數
//發布本地倉庫到遠程的中央倉庫中，origin是遠程倉庫名，master是參數告訴Git的分支，master代表主分支，當然分支可以不是主分支

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

功能分支工作流

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

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

新分支創建之后，對其的編輯、暫存和提交工作與之前一樣，對其push的命令變為

git push origin newbranch

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

git checkout mastergit pullgit pull origin newbranchgit push

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

Gitflow工作流

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

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

維護分支

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

工作流程

為master分支配套一個develop分支

git branch develop
git push -u origin develop

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

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

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

git checkout -b some-feature develop

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

git status
git add <some-file>
git commit

添加了提交后，功能OK了之后，如果團隊使用Pull Requests，這時候可以發起一個用于合并到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在分支和克隆上的優勢，既可以管理大團隊的開發者（developer）和接受不信任貢獻者（contributor）的提交。這種工作流使得每個開發者都有一個服務端倉庫（此倉庫只有自己可以push，但是所有人都可以pull修改），每個程序員都push代碼到自己的服務端倉庫，但不能push到正式倉庫，只有項目維護者才能push到正式倉庫，這樣項目維護者可以接受任何開發者的提交，但無需給他正式代碼庫的寫權限。
這種工作流適合網上開源社區的開源項目，大家統一對項目做貢獻，但是有一個人或一個團隊作為開發者來管理項目，所有的貢獻者的代碼由開發者審核，其功能完善之后再由開發者push到正式倉庫中。

Pull Request

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

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

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

例：

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

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

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

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

以上就是“Git工作流模式及命令怎么使用”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。