如何管理Git“上游”分支和相關補丁？

Question

最近我遇到了一個問題，我給了一個分配補丁，因為教授已經改變了代碼來添加新的功能。 不幸的是，我已經將原始代碼庫放在git中並且已經做了很多更改和提交。 我用來應用補丁的工作流程如下：

git checkout <hash_of_where_patch_should_go>
git checkout -b patch_branch
git apply patch
git add ./* && git commit -m "applying patch"
git rebase master patch_branch
    //Fix merge conflicts
git rebase patch_branch master

這非常有效，但我的問題是：這是執行此類任務的“正確”方法嗎？ 在我看來，必須有一種更直接的方式。

Answer 1

假設僅僅應用補丁並直接處理任何拒絕並不簡單，我會

git checkout $patch_base
git apply --index patch
git commit -m'patch from prof'
git checkout @{-1}

git cherry-pick @{-1}
# or git merge @{-1}

Answer 2

為未修改的上游代碼保留單獨的分支

創建一個分支，您可以在其中放置教授發布的代碼。 在您的情況下，這可能意味着：

git checkout -b upstream <commit_where_you_imported_professors_stuff>

僅將上游補丁應用於上游分支

當你的教授為你的（她的？）代碼提供補丁時，你將檢查你的upstream分支，然后在那里應用補丁 - 這應該總是可以沒有沖突。

git checkout upstream
git apply <whatever>
git add -A
git commit -m 'Patch from upstream'

在upstream分支您自己的工作，並在需要時合並

現在，要開始添加自己的工作，您將分支upstream ，並提交到該分支。 在你的情況下，這已經發生了，因為你已經在做項目了。

git checkout -b my_work upstream
... work ... work ... work (no play)
git add <stuff>
git commit -m 'Work done'

當你必須修改upstream （教授給你的“框架”）時，你可以按照上面的描述（checkout，patch，commit）進行修改，然后將它合並到你的工作分支中：

git checkout upstream
... patch upstream ...
git checkout my_work
git merge upstream

這樣，您將獲得以下好處：

1. 在upstream分支上，您可以清楚地看到框架的當前狀態是什么，以及哪些補丁已經提供給您，以及何時。
2. 當你必須修補upstream並將其與你自己的工作合並時，如果出現問題，很容易退出這一步（只需執行git merge --abort或刪除合並提交）。
3. 在項目進行過程中，您必須從教授合並以及所引入的更改（以及可能合並您的工作分支的沖突）時很容易看到。
4. （可選，並不總是有用）如果您為框架制作自己的補丁，可以在upstream分支（而不是“工作分支”）上創建它們，這將使您以后更容易顯示（ diff ）它們。 您可以將這些提交視為您自己的上游補丁，與教授一起生活。

不要使用“rebase”

我強烈建議不要做“rebase”，因為你將有效地破壞重要的歷史信息（如果你做的是rebase而不是merge許多比較操作變得困難或不可能）。

如果您需要合並的簡單（通常是一次提交）更改，並且希望避免創建合並提交，則僅使用rebase。

保羅·斯塔迪格寫了一篇關於這個話題的好文章（重新定位與合並）： 你不應該說謊：git rebase，修正，壁球和其他謊言