用於本地提交，上游提交和部署的Git工作流程

Question

我知道有很多關於git工作流的文章，但我找不到我期待的內容：關於以下工作流最佳實踐的建議：

我有一個通過git部署的web應用程序。應用程序開發人員通過公共git回購發佈更新。我也有自己的需要應用的更改。處理這個問題的最佳方法是什麼？

我一直在做的：我創建了一個本地部署回購，從上游克隆。這是通過gitolite服務的，所以這是一個裸回購。我有一個這個回購的克隆，我在其上應用更改，並將它們推回到部署回購。當更改發佈到上游回購，我已經把它們納入到這個克隆，使用推薦的命令：

git fetch && git pull --rebase 

然後我推到部署回購。問題是，我開始在任何已更改的文件上發生大量合併衝突。同樣的文件會在rebase期間給我許多衝突。我正在尋找一種可以或多或少自動化的方法，但我不太瞭解git足夠了解問題所在。

任何git gurus都可以提供一些建議嗎？讓我知道是否需要澄清。謝謝。

Answer 1

我不想知道和記住蹩腳的，醜陋的，愚蠢的，「原始的」Git-jargoon，所以我會以「需要的動作」的形式編寫食譜，將它翻譯爲命令的任務，你

準備

發送您當前的工作流程地垃圾桶

操作

• 您必須有一個回購與兩個分支（供應商和自己的）。供應商分支鏈接到上游的遠程回購，您的分支是單個地方，您可以在其中存儲自己的更改。必須從Vendor創建分支自己，爲了獲得兩個分支中所有文件的共同父項，Own中的文件必須用您的更改進行修補
• 通過更新遠程供應商分支和與自身分支進行合併它（改變從供應商合併成自家）

你必須在合併階段只對改變雙方的衝突（你和上游）文件

Answer 2

您當前的工作流程就可以了，如果你從git pull中刪除了--rebase。然後拉將做一個合併（默認），而不是一個rebase，你會有更少的衝突。當然，總是會出現git無法自行解決衝突的情況，所以這個過程不能完全自動化。

問題是rebase需要很多步驟，回顧整個歷史並解決您在上游所做的每個更改。這對於您的情況來說是不必要的，甚至會適得其反，因爲它無法確定您的更改是相對於上游的更改而做出的。合併會更好，因爲它們只採取一個步驟，不必在歷史上走得很遠（僅適用於以前的合併）。

如果你在進行合併時仍然遇到比你想要的更多的衝突，你將不得不尋找方法來減少你的修訂和上游之間的差異（你可以在做完合併），或將更改移動到上游不經常修改（或上游不存在）的位置。