处理“略有不同”的最佳实践源代码分支
这个问题是不可知的，而不是与某个版本控制程序相关。
假设在某种分布式版本控制下有一个源代码树。我们称其为 A。
在某些时候，其他人会克隆它并获得自己的副本。我们称之为 B。
我将称之为 A 和 B 分支，即使某些版本控制工具对分支有不同的定义（有些可能称为 A 和 B 存储库）。
我们假设分支 A 是“主”分支。在分布式版本控制的上下文中，这仅意味着分支 A 的修改更加主动，并且分支 B 的所有者定期从分支 A 同步（拉取）新更新。
让我们考虑分支 B 中的某个源文件包含一个类（再次） ，它也是与语言无关的）。分支 B 的所有者认为某些类方法更合适，并通过将它们移动到类体内来将它们组合在一起。功能上没有任何改变——这是对代码的非常简单的重构。但变化会反映在差异中。现在，假设分支 B 的此更改永远不会合并到分支 A 中，则分支 B 的所有者在从分支 A 拉取并合并到他自己的工作区时始终会得到此差异。即使只有一个这样微不足道的更改，分支 B 的所有者每次从分支 A 拉取时都需要解决冲突。只要分支 A 和 B 独立修改，就会出现越来越多的此类冲突。这种情况的解决方法是什么？分支 B 的所有者应遵循哪个工作流程以最大限度地减少与分支 A 定期同步的工作量？
This question is rather agnostic than related to a certain version control program.
Assume there is a source code tree under certain distributed version control. Let's call it A.
At some point somebody else clones it and gets its own copy. Let's call it B.
I'll call A and B branches, even if some version control tools have different definitions for branches (some might call A and B repositories).
Let's assume that branch A is the "main" branch. In the context of distributed version control this only means that branch A is modified much more actively and the owner of branch B periodically syncs (pulls) new updates from branch A.
Let's consider that a certain source file in branch B contains a class (again, it's also language agnostic). The owner of branch B considers that some class methods are more appropriate and groups them together by moving them inside the class body. Functionally nothing has changed - this is a very trivial refactoring of the code. But the change gets reflected in diffs. Now, assuming that this change from branch B will never get merged into branch A, the owner of branch B will always get this difference when pulling from branch A and merging into his own workspace. Even if there's only one such trivial change, the owner of branch B needs to resolve conflicts every time when pulling from branch A. As long as branches A and B are modified independently, more and more conflicts like this appear. What is the workaround for this situation? Which workflow should the owner of branch B follow to minimize the effort for periodically syncing with branch A?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
开发 B 应该要么取消重构，要么添加一些有意义的功能，这些功能有足够的动力来保证合并回 A。否则告诉他“他们就是突破点”。
举一个极端的例子，他可能认为自己不喜欢 C，并决定将所有内容逐行重写为 Pascal，使用相同的变量名、类名等。是语言。那么，当他坚持认为没有任何变化，因此不应该有差异时，你会告诉他什么呢？
Dev B should either un-refactor, or else add some meaningful functionality that has enough momentum to warrant merging back into A. Otherwise tell him "Them's the breaks".
To go to an extreme example, he could decide that he doesn't like C and decide to re-write everything as Pascal, line by line, using the same variable names, class names, etc.. To the point that the only difference is the language. So what would you tell him then, when he insists that there aren't any changes, so there should be no diff?
一种解决方法是在代码比较周围使用一个奇特的差异包装器，它将智能地忽略某些非常具体的差异。
在简单的层面上，它通常通过 gdiff 来实现，在 fancier 上，使用自定义 diff 代码。
然而，我必须说，这种情况确实是一件坏事，最好将更改合并回 A 中；例如，向 A 的维护者提交补丁
One workaround is to have a fancy diff wrapper around code comparison that will intelligently ignore certain very specific diffs.
On a simple level it's usually implemented via gdiff, on fancier, with custom diff code.
However, I must say that such a situation is really a bad thing and it's much better to merge the changes back into A; by for example submitting a patch to A's maintainers owners
分支 B 的所有者应该与分支 A 的所有者讨论该更改。他们应该决定该更改是否值得进行，在这种情况下，应该将其提交给主干 (A)，否则则不值得，在这种情况根本不应该发生。 VCS 不能替代开发人员之间的沟通。
The owner of branch B should have discussed the change with the owner of branch A. They should have decided that either the change was worth making, in which case it should have been committed to the trunk (A) or it wasn't, in which case it should have never been made. VCS is not a substitute for communication between developers.
开发人员 B 应该要求开发人员 A 从他那里撤出。
如果两个分支发散并且永远不会收敛，这种情况是不可避免的。它类似于项目中的分叉 - 合并两个不同的分叉非常困难。
Dev B should ask Dev A to pull from him.
The situation is not avoidable if two branches diverge and never converge. Its similar to a fork in a project - Its very difficult to merge two different forks.