如何管理Git“上游”分支和相关的补丁？ [英] How to manage a Git "upstream" branch and related patches?

问题描述

最近我遇到了一个问题，就是因为教授已经更改了代码以添加新功能，所以我得到了一个作业的补丁。不幸的是，我已经把原始的代码库放在git中，并且已经做了很多更改和提交。我用来应用该补丁的工作流程如下所示：

  git checkout< hash_of_where_patch_should_go> 
 git checkout -b patch_branch 
 git apply patch 
 git add ./*&& git commit -m应用补丁
 git rebase master patch_branch 
 //修复合并冲突
 git rebase patch_branch master 
  

这很好用，但我的问题是：这是执行此类任务的正确方式吗？在我看来，必须有一种更直接的方式。

解决方案

为未修改的上游代码保留一个单独的分支

创建一个分支，您可以在其中放置由教授发布的代码。在你的情况下，这可能意味着：

  git checkout -b上游< commit_where_you_imported_professors_stuff> 
  

将补丁从上游应用到上游分支

当你的教授给你一个他（她）的代码的补丁时，你会检查你的上游分支，并应用补丁那里 - ndash;这应该永远是可能的，没有冲突。

  git checkout upstream 
 git apply< whatever> 
 git add -A 
 git commit -m'来自上游的补丁'
  

将您自己的工作分支上游，并在需要时合并

现在，添加你自己的工作，你将分支上游，并提交到该分支。在你的情况下，这已经发生了，因为你已经在处理这个项目。

  git checkout -b my_work upstream 
 ...工作...工作...工作（不玩）
 git add< stuff> 
 git commit -m'完成工作'
  

当您必须修改上游（由教授给你的框架），你可以按照上面描述的方式进行操作（checkout，patch，commit），然后将其合并到你的工作分支中：

  git checkout上游
 ...上游补丁... 
 git checkout my_work 
 git merge upstream 
  

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

1. 在上游分支上，您清楚地看到框架的当前状态以及哪些补丁已经提供给你和什么时候。


2. 当你必须修补上游并将它与自己的作品合并时，很容易如果出现问题，退出此步骤（只需执行 git merge --abort 或移除合并提交）。
   
3. 这很容易在项目进行过程中，您必须与教授合并才能找到您（可能并不总是有用）。如果您为框架制作了自己的补丁，您可以将它们放在上游分支（而不是您的工作分支），这将使您更容易显示（ diff ）他们以后。您可以将这些提交视为您自己的上游补丁，与教授一起生活。

不要使用rebase 为此

我强烈建议不要这样做rebase，因为您将有效地摧毁重要的历史信息（如果您做了许多比较操作变得困难或不可能

$ b如果您需要合并并且希望避免创建合并提交，那么使用重新分页（rebase）。

Paul Stadig就这个话题写了一篇很好的文章（重新组合和合并）：你不应该撒谎：git rebase，修正，壁球和其他谎言

Recently I had an issue where I was given a patch for an assignment, as the professor had changed the code to add new functionality. Unfortunately, I had already put the original codebase in git and had made lots of changes and commits already. The workflow I used to apply the patch is as follows:

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

This worked wonderfully, but my question is this: is this the 'correct' way to perform such a task? It seems to me like there must be a more straightforward way.

解决方案

Keep a separate branch for the unmodified upstream code

Create a branch where you put the code as it is released by your professor. In your case, that will probably mean:

git checkout -b upstream <commit_where_you_imported_professors_stuff>

Apply patches from upstream only to the upstream branch

When your professor gives you a patch to his (her?) code, you will then checkout your upstream branch, and apply the patch there – this should always be possible without conflicts.

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

Branch your own work off upstream, and merge when needed

Now, to start adding your own work, you will branch upstream, and commit to that branch. In your case, this has already happened, because you're already working on the project.

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

When you have to modify upstream (the "framework" given to you by professor), you do it as described above (checkout, patch, commit), and then merge it into your work branch:

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

This way, you will get the following benefits:

1. It's clearly visible to you on the upstream branch what the current state of the framework is, and which patches have been given to you, and when.
2. When you have to patch upstream and merge it with your own work, it's easy to back out of this step if things go wrong (just do git merge --abort or remove the merge commit).
3. It's easy to see for you when during the course of the project you had to merge from Professor and which changes (and possibly merge conflicts on your work branch) that introduced.
4. (Optional, not always useful) If you make your own patches to the framework, you can make them on the upstream branch (instead of your "work branch"), which will make it easier for you to display (diff) them later on. You can think of those commits as your own upstream patches, living alongside those of Professor.

DON'T use "rebase" for that

I strongly advise against doing "rebase", because you will effectively destroy important history information (many comparison operations become difficult or impossible if you do rebaseing instead of mergeing).

Only use rebase if you have trivial (usually one-commit) changes that you need to merge, and want to avoid creating a merge commit.

Paul Stadig wrote a good piece about this topic (rebasing vs. merging): Thou Shalt Not Lie: git rebase, amend, squash, and other lies

这篇关于如何管理Git“上游”分支和相关的补丁？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！