典型的單一分支git工作流程

Question

我們正在檢查git，並想了解哪個工作流可能適合我們的小團隊（4名開發人員）。

我們所做的一些細節：

• 我們對目前與周圍4-5的解決方案，共約〜70個項目 和不斷增長的組成1個 庫的.NET產品的工作。
• 我們目前有1箇中央存儲庫和1個分支。
• 雖然 偶爾會協作/修改其他團隊成員的代碼區域，但每個開發人員都在不同的代碼庫區域工作。

什麼是像我們這樣的團隊的「典型」git工作流程？

我希望在儘可能短的時間內儘可能地在「管理」操作上花費時間。

例如，今天我們已經看到，因爲另一推了之前提出由開發一個混帳推請求失敗，他不得不在本地使用混帳拉第一合併修改。

是一個典型的業務情景是這樣的：

開發，本地提交。 從git倉庫拉。 推入git存儲庫。

難道我們不能跳過拉？ （在遠程服務器上完成合並？）

當前我們正在使用ClearCase，並且在推送（「提交」）操作期間通過合併來解決，而不需要先取消。

Answer 1

首先，我會推薦至少兩個分支。我們稱之爲master和integration。 Master是目前穩定的生產就緒代碼庫。這是客戶手中或即將提交給App Store的事情（我們是iOS商店）。集成是我們存儲我們的測試就緒代碼的地方。如果有人要求測試版本，這是我們給他們的。這裏的代碼編譯和運行，但並不完美。根據您的部署和測試流程，您可以根據需要獲得儘可能多的額外分支。 git中的分支很容易和快捷，沒有理由沒有你需要的那麼多。

下面是我們如何處理工作：

1. 開發者使用git pull，以獲取最新版本整合他們的機器上。
2. 創建一個關於集成的主題分支。 'git checkout -b fix-home-page`會創建一個名爲「fix-home-page」的新分支。
3. 修復修復修復，代碼代碼每隔5分鐘進行一次新的提交，因爲git中的提交非常簡單快捷。完成功能/錯誤修復後：
4. 切換回集成分支並使用git pull確保獲得最新的提交。
5. git merge --squash fix-home-page將拉動你的分支在一個很好的乾淨的提交併保持你的歷史線性。
6. git push將您的修復推回到主回購。

我喜歡git merge --squash，因爲它大大減少了衝突的次數。其他人喜歡使用rebase，這也會給你一個線性歷史記錄，並保留你的主題分支的所有提交。使用任何適合你的東西。

最後，回答你的問題：是的，你必須在推動之前做一個git pull。 Git對於解決衝突非常有用，但如果它不能解決衝突，那麼你需要人爲干預才能找出應該發生的事情。

Answer 2

難道我們不能跳過拉嗎？ （在遠程服務器上完成合並？）

編號合併可能會導致衝突，而您必須手動解析 - 因此，必須先更新本地存儲庫，然後再推送新的如果另一位開發人員在您上次更新後推送更改，則會發生變化

Answer 3

不，git不知道合併會發生什麼 - 可能會有衝突 - 並且在推送之前需要將它們合併。

另外，不像SVN那樣在一個git倉庫中有許多項目是不可取的。 Git倉庫非常輕便，您可以在不同的倉庫中擁有單個項目或一組項目。這也確保了在一個項目上工作的人不必克隆整個回購，也不需要「拉」然後推。