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

这样，您将获得以下好处：

您可以在upstream分支上清楚地看到框架的当前状态是什么，以及哪些补丁已经提供给您，以及何时。
当您必须修补upstream并将其与您自己的工作合并时，如果出现问题，只需执行git merge --abort或删除合并提交即可轻松退出此步骤。
在项目进行过程中，您必须从教授那里合并以及引入的更改（以及可能合并您工作分支的冲突）时很容易看到。
（可选，并不总是有用）如果您自己为框架制作补丁，可以在upstream分支（而不是“工作分支”）上创建它们，这将使您更容易稍后显示它们（diff）。您可以将这些提交视为您自己的上游补丁，与教授一起生活。

请勿使用“rebase”

我强烈建议不要做“rebase”，因为你会有效地破坏重要的历史信息（如果你rebase而不是merge，那么很多比较操作就变得困难或不可能。

如果您需要合并的简单（通常是一次提交）更改，并且希望避免创建合并提交，则仅使用rebase。

Paul Stadig写了一篇关于这个话题的好文章（基础与合并）：Thou Shalt Not Lie: git rebase, amend, squash, and other lies

如何管理Git＆＃34;上游＆＃34;分支和相关补丁？

2 个答案: