Git rebase冲突理解

在我的工作流程中，我有两个主要分支，master和development。Git rebase冲突理解

我们最近决定在master上重新配置development，因为我们在master上做了很多修复，我们继续开发development上的功能。

我们的目标是在年底前完全去除development，并保持一个分支来改变我们的工作流程，因为它是不完美的为我们的使用...

所以我们有一些冲突（7个月的开发后正常型动物分支机构），但有些人退出怪异......

例如，很多的时候，我们有这样的事情：

$ git status 
# On branch master 
# Unmerged paths: 
# (use "git add/rm ..." as appropriate to mark resolution) 
# 
#  added by them:  X 
#  added by us:  Y

但对于added by us，该文件存在于master和我n development提交。你要知道，有关的文件都至少10个月老....

我的问题在这里：什么是added by us的确切含义是什么？

和是rebase是一个很好的做法吗？

来源

2013-07-12 Pierre Fourgeaud

当要折叠提交的，你没有分享过，曾经你的个人资料库; rebase是个好主意。如果你想折叠团队其他成员使用的提交并希望获得他们的仇恨，rebase是个好主意。 – tjd

我假定us表示您当前的分支，而them表示您正在进行重新绑定。但是，这实际上是一个非常小的点，因为：

你不应该重订7个月工作价值！

衍合应该差不多只能在本地代码中使用，也就是还没有推。如果你用它来做别的事情，你可能做错了什么。这是其中的一次。

的默认答案是合并，垫底的是特殊情况。所以你也应该在这种情况下合并。垫底的后果：

你要做100合并，而不是1和照顾冲突，而不是100次一次（在底垫中的每一步都是一个合并）
你的历史是一个total lie。我确实认为你没有彻底地测试每一个重新提交的提交（因为这显然会很疯狂）。其结果是，稍后没有任何代码可能实际工作，甚至是有意义的。有关冲突解决的信息也会丢失（如果您合并，则不会丢失 - 您可以通过与父母双方进行区分来获得）。

来源

2013-07-12 08:11:43 Chronial

在重大分支重写的情况下，重新生成是一种有效的工具，即使对于大量的历史记录也是如此。 –

我也认为这是完全有效的，你可以在rebase之前“挤压”那些提交，以使事情变得更容易。所以它就像“rebase -i commitBeforeBranchCreation”，做所有的壁球，修复必要的，然后“rebase masterBranch”......这样冲突就少得多了。 – mjsr

Git rebase冲突理解

回答

相关问题