GIT - Rebase - 如何处理冲突 [英] GIT - Rebase - How to deal with conflicts

问题描述

我正在研究一个有两个分支的项目： master 和功能

功能分支是前一段时间创建的，并且有很多提交。

自创建了特性分支，其中有一些提交给 master

此时，当我去 rebase 关闭 master 时，我会发生冲突。我解决它们，然后 rebase --continue 。然后我再次发生冲突，并再次解决，并且 rebase --continue 。这种情况反复发生，很多时候它们看起来像是同样的冲突。

在我看来，这是发生了什么：

master（提交） - > a-> b
功能（提交） - > ; c-> d-> e-> f-> g

特征是从 master-> a 分支的，然后所有提交都被创建。

当I rebase 它会回退到特征的开始位置，从 master 应用 master-> b ，然后开始应用 feature-> c 冲突。我解决了（接受 master 更改）并继续。现在它尝试应用 feature-> d 并找到相同的冲突。再次，我必须解决和继续。

例如这里有一些变化：

  master-> a 
< div id =foo> 
 
 master-> b 
< div id =bar> 
 
 feature-> c 
< div id =fubar> 
 
 feature-> d 
 //没有任何变化，继承自feature-> c 
< div id =fubar> 
  

我假设当它到达 feature-> c 它表示改变 foo 到 fubar ，然后注意到 foo code>已被更改为 bar 。我解析为 bar ，然后使用 feature-> d

我的两个问题：

1）我理解git如何工作/处理提交/冲突/重新定位是否正确？

<2>如何避免必须一遍又一遍地解决相同的冲突？我正在考虑压缩功能分支上的所有提交，以便只处理一个提交。我不确定这是一个好主意还是确切地说是在场景中压扁的最佳方式。

请注意，这是一个非常简单的例子。事实上，我有更多的承诺，并在每个众多的冲突文件中。其中一些在整个 rebase --continue 过程中看起来是相同的，并且对于每个 commit 都有一些新的

我的最终目标是尽可能简单地清理此项目（从当前的主设备中重新获得特性分支）。我不关心提交的历史。

解决方案

我不在乎历史。

如果你真的不关心历史，那么 git merge --squash 会让你一次解决所有的冲突，并产生一次提交所有的变更。

基本上这样做 - squash in-place，你可以这样做：

  git branch  - m功能特性旧
 git checkout master -b特性
 git合并--squash特性旧
  

解决所有冲突（一次）后，您将在功能上创建一个提交，其中 master 作为父母。

这就是说，我是保持历史的粉丝。绝对先试试 rerere 。你也可以尝试一个就地 rebase --interactive （例如 git rebase -i $（git merge-base HEAD master））来压缩fixup-type提交而不完全消除所有离散提交。

I am working on a project that has two branches: master and feature

The feature branch was created some time ago and has numerous commits.

Since the feature branch was created there have been a couple of commits to master

At this point when I go to rebase off of master I get conflicts. I resolve them and then rebase --continue. Then I get conflicts again, and again resolve and rebase --continue. This happens over and over and many times it seems like they are the same conflicts that are appearing.

In my mind here is what is happening:

master(commits)->a->b feature(commits)->c->d->e->f->g

feature was branched from master->a and then all commits were created.

When I rebase it rewinds back to the begining of feature where it was branched from master applies master->b and then starts to apply feature->c at this point it has a conflict. I resolve (accepting the master changes) and continue. Now it tries to apply feature->d and finds the same conflict. Again I have to resolve and continue. This happens over and over.

For example here are the changes:

master->a
    <div id="foo">

master->b
    <div id="bar">

feature->c
    <div id="fubar">

feature->d
    //Nothing has changed, inherited from feature->c
    <div id="fubar">

I am assuming that when it reaches feature->c it says change foo to fubar and then it notices that foo is already changed to bar. I resolve to bar and then it does the same logic applying feature->d

My two questions:

1) Is my understanding of how git is working / dealing with commits/conflicts/rebasing correct?

2) How can I avoid having to resolve the same conflicts over and over again? I was thinking of squashing all of the commits on the feature branch so that there is only one to deal with. I was not sure if this was a good idea or exactly the best way to go about squashing in the scenario.

Note, this is a very simplified example. In reality I have a lot more commits and within each numerous files with numerous conflicts. Some of them appear to be the same throughout the rebase --continue process and some are new for each commit.

My end goal is to clean up this project as simply as possible (get the feature branch rebased off the current master). I do not care about the history of the commits.

解决方案

I do not care about the history of the commits.

If you really don't care about history, a git merge --squash is going to let you resolve all your conflicts at once and produce a single commit with all the changes.

To essentially do that --squash in-place, you could do something like this:

git branch -m feature feature-old
git checkout master -b feature
git merge --squash feature-old

After you resolve all conflicts (once), you will create a single commit on feature that has master as a parent.

That being said, I'm a fan of keeping history. Definitely try rerere first. You might also try an in-place rebase --interactive (e.g. git rebase -i $(git merge-base HEAD master)) to squash the fixup-type commits without completely eliminating all the discrete commits.

这篇关于GIT - Rebase - 如何处理冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！