你会在pull中选择rebase和merge方法么？ [英] What would you select between rebase and merge methods in pull?

问题描述

我使用SmartGit！
我知道 rebase 和合并之间的差异，但我听说将其分类为疑难解答操作，因此不推荐用于日常使用。所以SmartGit代之以推荐这种方法。你会怎么选择？

解决方案经验法则：如果您已经发布了要重新组合或合并的提交，并且未指定数量的用户已将它们放入其私有存储库克隆中，则合并是唯一选择。 如果您尚未发布它们，或者你可以要求所有的远程用户重新获取重新提交的提交，这对他们来说不会是一个很大的干扰，那么你可能会重新分配。

实际上，为了保持未发布的提交的历史直接和清洁，你应该改变它们。如果例如您在之前的未发布的提交中发现错误，您应该重置为已损坏的提交，对其进行修改，然后通过新的固定提交重新链接剩下的链。

理由：

在一个提交的git和[some]其他DVCS父目录中是一个提交的不可分割的属性。因此，如果父属性发生更改，则会产生全新的提交，即使它具有与原始提交相同的源代码树。这同样适用于修改的提交（至少在修改期间更改了提交时间）。

如果某人发布了一些提交，那些提交可能会被其他存储库用户为他们的衍生作品。已经发布的重新提交的提交请求所有其他用户都必须通过新版本的提交重新分配他们的作品。当然，它会让你的同事们的生活变得更加艰难，如果没有可行的论点，我不会推荐这种方法。另一方面，在你的本地链中进行不必要的合并事情复杂化，回购历史很快变得混乱。这就是为什么 rebase 是重新组织/重新排序未发布的提交集合的推荐方法。

I have usage the SmartGit! I know difference between rebase and merge, but I heard that rebase it classified as troubleshooting operation and it's not recommend for daily usage. So SmartGit instead reccomend that method. What would you select?

解决方案

The rule of thumb:

• if you have already published commits which are to be rebased or merged, and an unspecified number of users have already got them into their private repository clones, then merge is the only option.

• if you haven't publish them, or you can ask all remote users to re-fetch rebased commits, and this won't be a big disturbance for them, then you may rebase.

• Actually, to keep the history of unpublished commits straight and clean, you should rebase them. If e.g. you find a mistake in a previous unpublished commit, you should reset to the broken commit, amend it, and then rebase the rest of the chain over new fixed commit.

Rationale:

In git and [some] other DVCS parent(s) of a commit is an inseparable property of a commit. So if parent property is changed, this produces a completely new commit, even it has the same source tree as the original one. The same is applied to "amended commits" (at least commit time is changed during amend).

If one publishes some commits, those commits could be used by other repository users for their derivative works. Rebasing commits, that have been already published, demands that all other users, in turn, have to rebase their works over new versions of commits. Definitely, it makes life of your colleagues harder, and I wouldn't recommend this approach without feasible arguments.

From other hand, making unnecessary merges in your local chain of changes complicates things, and the repo history quickly becomes a mess. That's why rebase is a recommended approach to re-organize/re-order an unpublished set of commits.

这篇关于你会在pull中选择rebase和merge方法么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！