如何管理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，修正，壁球和其他谎言