修正发布的分支与错误的父分支 [英] Fixing published branch with wrong parent branch

问题描述

我遇到了一个问题，我发布了一个分支到我的公共git存储库，它有错误的父分支。

最初，我有：

  A < -  master 
 \ 
 B < -  abstract-test-rule 
 \ 
 C < -  run-leaf 
  

我推送了抽象测试规则和 to我的公共github存储库，并为每个提出了请求。然后我意识到run-leaf包含提交B;我本来打算从A分支run-leaf。因此，我在分支run-leaf上运行了 git revert B ：

  A < -  master 
 \ 
 B < -  abstract-test-rule 
 \ 
 C  -  B'< -  run-leaf 
  

我重新将run-leaf推送到了我的公共github存储库。

问题1：我应该做什么？我猜测正确的做法是从A创建一个新的分支，只有提交C的增量，推送到我的公共github存储库，取消之前的请求并创建一个新的分支。不幸的是，分支run-leaf被合并到父库中开始，然后 B'被合并到父库中。

我知道抽象测试规则的合并现在对于父库的所有者来说是痛苦的，所以我试图准备抽象测试规则合并。这时候我的回购看起来像这样：

  A < -  master 
 \ 
 B -  D  -  E < - 抽象测试规则
 \ 
 C  -  B'< - 运行叶
  pre> 
 
 
我进入我的回购库，从父回购库中拉入主，然后将主合并为抽象测试规则。合并是一团糟（因为，我猜测，我正在合并父代的B'版本到抽象测试规则）。毕竟，我们有一些非常混乱的差异。
 
 
 
 问题2：有没有更简单的方法来清理抽象测试规则？换句话说，我想将master合并为abstract-test-rule，但是避免将我的父代回购版的B'合并到abstract-test-rule中。
 
 <问题3：验证到父库的合并是否正确完成的最佳方法是什么？现在，我只是从父库中取出，将我的版本的分支从master（查看合并的差异）和运行 git diff master 到验证该分支现在与master相同
 
 
 
谢谢！ 
 
解决方案
 
 
 
 问题1：我该怎么做？我猜测正确的做法是从A创建一个新的分支，只有提交C的增量，推送到我的公共github存储库，取消之前的请求并创建一个新的分支。最简单的方法是什么？
 
 
这取决于是否有人已经取消了您的更改。如果没有人拉你的修改，你可以删除分支并用想要的提交重新创建一个新分支。如果您的更改进入另一个回购，您只能 git回复不需要的提交。一般来说，如果你发布了分支，那么对于 git revert 更安全，因为在大多数情况下，你不能确定没有人拉动不需要的分支。
 
 
 
 编辑：变更移植  
 $ b 您可以创建一个只有C变更集的新分支， 
  git checkout -b newbranch A＃<  - 分支名称或commit-id 
 git cherry-pick SHA1 （C）＃为每个想要的提交重复
  
或 
 
 
  git checkout -b newbranch run-leaf 
 git rebase -i HEAD〜10＃大到足以包含您想要
＃的所有提交，并在编辑器中删除每个不需要的提交。
  
这两种方法都只创建一个新的分支，只有想要的提交。  
 
 
 
 
 问题2：有没有更简单的方法来清理抽象测试规则？换句话说，我想将master合并为abstract-test-rule，但是要避免将我的父代回购版的B'合并为abstract-test-rule
 
 
只要未发布更改，您可以分支历史记录 git rebase -i 。修改发布后，您无法修改历史记录。
 
 
 
 编辑  
 
 
由于您的更改已经展开，因此建议您更换变更集。你也可以通过交互式重新分区来去除不需要的变更集，并且 git push -f 会发生变化，但每个其他谁拉动旧分支在下次回购时可能会遇到麻烦。参见这个SO问题和 git文档了解更多信息 
 
 
 
 
 问题3：验证合并到父库的最佳方法是什么是否正确？现在，我只是从父库中取出，从master（从合并中查看差异）合并我的分支版本并运行git diff master以验证分支现在与master相同
 
 
您可以在您的一侧进行合并，以便上游开发人员可以快速合并。这样，上游开发人员不会自行合并，而是使用您准备好的合并。
 
I ran into a problem where I published a branch to my public git repository that had the wrong parent branch. My attempts to fix this made things worse.

Initially, I had:
  A <-- master
   \
    B <-- abstract-test-rule
     \
      C <-- run-leaf
I pushed abstract-test-rule and run-leaf to my public github repository, and made pull requests for each. I then realized that "run-leaf" included commit B; I had meant to branch "run-leaf" off of "A". So I ran git revert B on branch "run-leaf":
  A <-- master
   \
    B <-- abstract-test-rule
     \
      C--B' <-- run-leaf
I re-pushed "run-leaf" to my public github repository.

Question 1: What should I have done? I'm guessing the correct thing would be to create a new branch off of A with only the delta from commit C, pushed that to my public github repository, canceled the previous pull request and create a new one. What's the easiest way to do that?

Unfortunately, branch "run-leaf" was merged into the parent repository from commit C, and then B' was merged into the parent repo. 

I knew the merge of "abstract-test-rule" would now be painful for the owner of the parent repository, so I tried to prepare "abstract-test-rule" for merge. By this time my repo looked like this:
  A <-- master
   \
    B--D--E <-- abstract-test-rule
     \
      C--B' <-- run-leaf
I went into my repo, pulled from the parent repo into "master", and then merged "master" into "abstract-test-rule". The merge was a mess (because, I'm guessing, I was merging the parent repo's version of B' into "abstract-test-rule"). After all this, we have some very confusing diffs.

Question 2: Was there an easier way for me to cleanup "abstract-test-rule"? In other words, I wanted to merge "master" into "abstract-test-rule" but avoid merging my parent repo's version of B' into "abstract-test-rule"

Question 3: What is the best way to verify that the merges to the parent repository were done correctly? Right now, I'm just pulling from the parent repository, merging my version of the branches from "master" (reviewing the diffs from the merge) and running git diff master to verify that the branch is now identical to "master"

Thanks!
解决方案

  
Question 1: What should I have done? I'm guessing the correct thing would be to create a new branch off of A with only the delta from commit C, pushed that to my public github repository, canceled the previous pull request and create a new one. What's the easiest way to do that?
It depends on if anyone has already pulled your changes. If no one has pulled your changes you can remove the branch and recreate a new one with the wanted commits. If your changes got into another repo you can only git revert the unwanted commit. As a rule f thumb if you published the branch it is safer to git revert since in most cases you can't be sure that no one pulled the unwanted branch.

edit: changeset transplanting

You can create a new branch with only the C changeset by either
git checkout -b newbranch A # <- branch name or commit-id
git cherry-pick SHA1(C) # repeat for every wanted commit
or
git checkout -b newbranch run-leaf
git rebase -i HEAD~10 # large-enough number to include every commit you want
                      # to strip, and remove every unwanted commit in the editor
Both ways create a new branch with only the wanted commits. 

  
Question 2: Was there an easier way for me to cleanup "abstract-test-rule"? In other words, I wanted to merge "master" into "abstract-test-rule" but avoid merging my parent repo's version of B' into "abstract-test-rule"
As long as the changes are not published, you can git rebase -i the branch history. When the changes are published you can't edit the history.

edit

As your changes are already spread out, so reverting the changeset is the recommended way. You could also have striped out the unwanted changeset with interactive rebase, and git push -f this changes out, but every other who pulled the old branch would likely run into trouble on the next pull of your repo. See this SO question and the git docs for more information about that.

  
Question 3: What is the best way to verify that the merges to the parent repository were done correctly? Right now, I'm just pulling from the parent repository, merging my version of the branches from "master" (reviewing the diffs from the merge) and running git diff master to verify that the branch is now identical to "master"
You can do the merge on your side so that for the upstream developer these are fast forward merges. That way the upstream developer does no merge on it's own but uses your prepared merge.

                        
这篇关于修正发布的分支与错误的父分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！