使用git和github的正確工作流程

Question

所以目前我一直在使用git和github編碼rails應用。 我通常一個人工作，但是在我的最新項目中，我正在與第二位開發人員一起工作。 我正在嘗試找出與其他用戶一起工作的標准方法。

目前，我讓他分叉我的gitrepo，然后在他准備好更改時才提交拉取請求。 情況還算不錯，除了我編寫了更多代碼外-當派生隊列中有要他推送的更改時，其中許多失敗（即使自上次推送我以來沒有做任何更改） ）。

對於他來說，每次重新分叉的整個過程似乎都更有效率，這讓我覺得我們正在做一些錯誤的事情。 我們應該使用分支而不是分叉嗎？ 還是叉子和樹枝？

謝謝！

Answer 1

第二個開發人員應首先將GitHub存儲庫拉入其本地存儲庫，以解決那里的任何沖突。

然后他可以提出拉取請求。

• 無需重新分叉（無論如何，這毫無意義：“分叉”是GitHub端的克隆）
• 無需額外的分支（例如，如果您都在使用同一組功能，那么您都可以使用' master '）

拉取請求的想法仍然是提交可以快速轉發的補丁（易於應用於您的GitHub存儲庫）。
這是通過在發出請求之前先在本地解決任何沖突來實現的。

---

其他選擇是在您的GitHub項目上聲明所述第二位開發者為“協作者”（他將能夠直接進行推送），但這不會改變為確保推送將必須“首先進行拉動”的事實直截了當。

Answer 2

因為它是一種靈活的工具，所以有許多git工作流程可供您使用，但是簡單的工作流程是擁有一個“ master”分支和一個“ develop”分支。 您可以直接將其直接拖入您的存儲庫，而無需在github上進行分叉，而您的協作者也不必不斷提交Github請求請求。

你們都可以在開發分支上進行大部分本地提交，但是經常要從遠程開發分支上拉下來以便合並彼此的代碼-在這個階段，您可以處理合並沖突，然后再推送到遠程。

較不頻繁地，您可以拉低master並將其與development合並。 這個想法是master分支更加穩定，可以隨時准備發布，因此不會在其上進行主動開發。 這里的所有都是它的。

如果您想走得更遠，您都可以從您的開發分支中創建“功能分支”，但是原理是相同的-合並回“ up”進行開發，然后從“ up”進行精通。

重要的是經常同步（合並）您的工作，否則代碼庫單獨副本中的差異可能會更大，這意味着發生沖突的可能性更大。 如果仍然存在沖突，請更頻繁地推動和拉動，以使差異更小並且更易於處理。

如果您倆都在同一個文件上進行大量工作，則沖突特別可能發生。 在這種情況下，有時需要進行整理並將工作划分為可更改代碼庫不同部分（文件）的功能，因此您不太可能踩到彼此的腳趾。

切記在拉動之前先提交本地更改，否則更改將被視為處於“暫存”狀態，並且在拉動期間不會自動合並。 幸運的是，git非常寬容，並且非常擅長處理合並沖突。