Git和Github的最佳工作流程

Question

我正在尋找一些關於如何使用Git & GitHub正確構建我的團隊的工作流程的建議。

我們是最近的svn轉換器，這有點令人困惑，我們應該如何最好地設置我們的日常工作流程。

這是一個小小的背景：我對命令行感到滿意，我的團隊對它很新，但可以遵循使用命令。我們都在與3個環境（開發，分期和生產）一起開展同一個項目。我們是開發人員的混合，所以有些人使用git GUI和一些CLI。

我們在SVN的設置去是這樣的：

• 我們有發展，分期和生產的一個分支。
• 當人們對代碼有信心時，他們會提交，然後將其合併到分段中。
• 服務器將自行更新，並在發佈日（每週）我們會做一個比較並將更改推送到生產服務器。

現在我設置了這些分支，並獲得了運行服務器的過程，但它的實際工作流程讓我感到困惑。

看來每次有人對文件進行更改時都會產生新的分支，提交，合併和刪除該分支。從我讀過的內容他們可以在特定的提交（使用哈希）上做到這一點，我有這樣的權利嗎？這是一個可以接受的方式去與Git的事情？

任何意見將不勝感激。

Answer 1

您可以從svn逐字複製您的工作流程。 Git可以做任何事情（但它可以做的比這更多！）。儘管使用了CVS，但您的工作流程可能會得到改進。

如果你想在你描述的工作流程中保持最小分支數（如果你是git的新手實際上會簡化一些事情），我建議擁有（而不是一個開發分支）三個-developer分支：devel的約翰，devel的瑪麗等：

devel-john >--\ 
       \ 
devel-mary >------> staging ---> production 
      /
devel-peter >-/ 

這是方便的：所有的發展變化將不會發生衝突推到中央存儲庫（這往往是即使是git的一件好事），一旦合併由任何願意/有義務進行合併的人（例如進入分期分支機構）。

Answer 2

根據您的工作流程，您可以在中央存儲庫（即github）上擁有一些可以在本地進行克隆的「重要」分支。這些將對應於'穩定'，'測試版'，'發展'等。關於一組可能的分支的不錯文章是this。

一旦完成，您可以讓人們使用自己的策略。我更喜歡爲主要項目保留主題分支，併爲我需要做的快速事情提供一個名爲「quick-fixes」的快速修復。如果你有一個團隊在一個主要項目上工作，他們希望保留在與主要回購站隔離的獨立分支上，你可以讓他們在沒有任何干預的情況下進行。如果人們喜歡有很多小分支來嘗試等等，他們也可以做到這一點。

至於自動測試和從staging集成到生產中，您可以配置git鉤子來做到這一點，或者有一個系統運行，將定期爲您做，並報告問題。

Answer 3

與DVCS工作時要記住的想法是：

• 分佈：即使你有一個GitHub的中部，developper不限於發佈（推送）只那 GitHub回購。他們可以fork the repo並在他們自己的版本發佈（而來自官方的中央GitHub庫獲取 - 所謂的「上游」）。
  優點是他們可以根據需要多次改寫歷史記錄（reset，rebase --onto，rebase -i，...），最終他們將提出拉取請求，允許集成者管理其更改。

• 的publication之一：在您自己的本地回購，你可以設置儘可能多的分支機構，只要你想（不是一個對每個文件進行修改，當然，而是一個對任何新的任務或一組任務的需要發展）。
  但您也可以設置公共分支機構，將其推送（「發佈」）到您的遠程回購。
  查看Git workflow這個問題，也JC濱野對遠程分支機構的文章：
  ØFun with remote branches (1)
  ØFun with remote branches (2)
  短語「當人們有信心，有代碼，他們會犯，然後將其合併到分級」不應適用使用DVCS：提前提交，經常提交，但只在需要時推送（「發佈」）。

Answer 4

也有在顯示Git命令開發商將日常使用遵循ProGit book描述的一些項目工作流程。

有一個GitHub的創造者斯科特·查孔，並提到Pro Git book的作者在http://nvie.com/git-model

Answer 5

Great post on GitHub Workflow描述一個頗受歡迎的Git分支模型：P