title: Best practices to deal with "slightly different" branches of source code
body: <p>This question is rather agnostic than related to a certain version control program.</p>
  
  <p>Assume there is a source code tree under certain distributed version control. Let's call it A.</p>
  
  <p>At some point somebody else clones it and gets its own copy.  Let's call it B.</p>
  
  <p>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).</p>
  
  <p>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.</p>
  
  <p>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?</p>