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 master
git pull
git pull origin newbranch
git 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://[email protected]/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提供建議，或者甚至直接新增提交來解決問題。