使用Git和Github的最佳工作流程

Question

我正在尋找有關如何使用Git和GitHub為我的團隊正確構建工作流程的建議。

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

這里有一些背景知識：我對命令行很滿意，我的團隊對此很陌生，但是可以遵循use命令。 我們所有人都在具有3個環境（開發，暫存和生產）的同一個項目上工作。 我們是開發人員和設計人員的混合體，因此有些使用git GUI和某些CLI。

我們在svn中的設置如下：

• 我們有一個開發，生產和生產分支。
• 當人們對代碼有信心時，他們會提交代碼，然后將其合並到階段中。
• 服務器將進行自我更新，並且在發布日期（每周一次），我們將進行比較並將更改推送到生產服務器。

現在，我設置了那些分支，並在服務器運行時啟動了該進程，但是它的實際工作流程卻使我感到困惑。

每次有人對文件進行更改時，他們都會創建一個新分支，提交，合並和刪除該分支，這似乎有些過頭。 根據我的閱讀，他們將能夠在特定的提交（使用哈希）上做到這一點，我有權利嗎？ 這是使用Git處理問題的可接受方法嗎？

任何建議將不勝感激。

Answer 1

您可以逐字復制svn的工作流程。 Git可以做svn可以做的所有事情（但是它可以做的更多！）。 但是，盡管使用了CVS，您的工作流程仍可以得到改善。

如果您要在您描述的工作流程中將分支的數量保持最少（如果您是git的新手，這實際上會簡化事情），我建議每個開發人員分支（而不是一個開發分支）具有三個： devel-john，devel-mary等：

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

這很方便：所有開發更改都將被推送到中央存儲庫（即使對於git來說也是一件好事）而不會發生沖突，並由願意/有義務進行合並的任何人（例如到暫存分支）隨時合並。

Answer 2

使用DVCS時要記住的想法是：

• 發行版 ：即使您有一個中央GitHub，開發人員也不限於僅發布（推送）到該 GitHub存儲庫。 他們可以分叉存儲庫並以自己的版本發布（同時從官方的中央GitHub存儲庫-稱為“ 上游 ”中獲取）。
  好處是他們可以根據需要多次重寫歷史記錄（ reset ， rebase --onto ， rebase -i ，...），最后，他們將發出請求請求，從而使集成商可以管理其更改。

• 出版物之一 ：在您自己的本地倉庫中，您可以根據需要設置任意數量的分支（當然，不是每個文件修改一個分支，而是一個新的任務或需要開發的任務集的分支）。
  但是，您也可以設置將被推送（“發布”）到遠程倉庫的公共分支。
  請參閱有關Git工作流的問題，以及有關遠程分支機構的JC Hamano的文章：
  o 遠程分支機構的樂趣（1）
  o 遠程分支機構的樂趣（2）
  短語“當人們對代碼有信心時，他們會提交然后將其合並到階段中”不適用於DVCS：提早提交，經常提交，但僅在需要時才推送（“發布”）。

Answer 3

ProGit書中還描述了一些項目工作流程，這些流程顯示了開發人員每天將遵循的Git命令。

在http://nvie.com/git-model中描述了一個公認的Git分支模型

Answer 4

一位GitHub創建者Scott Chacon和提到的Pro Git書 ：P的作者在GitHub Workflow上發表了出色的文章

Answer 5

根據您的工作流程，您可以在中央存儲庫中（例如，在github上）擁有一些“重要”分支，人們可以在本地進行克隆。 這將對應於“穩定”，“測試版”，“發展”上的一組可能的分支等一個很好的文章是這樣 。

完成后，您可以讓人們使用自己的策略。 我更喜歡為大型項目保留主題分支，並為我需要做的快速事情准備一個名為“快速修復”的分支。 如果您有一個團隊正在處理一個大型項目，而他們想保留一個與主倉庫分離的分支，則可以讓他們在沒有任何干預的情況下進行操作。 如果人們喜歡有很多細小的樹枝來嘗試其他事情，那么他們也可以這樣做。

至於從階段自動測試並集成到生產中，您可以配置git掛鈎來執行此操作，或者運行一個可以定期為您執行此操作並報告問題的系統。