tags:

views:

41

answers:

3

I'm new to git; I know the basic commands, but I'm not as familiar with the optimal way to organize projects.

I have two versions of a file that do nearly the same thing. The only difference between the two files is the way that they scan a particular file, and the differences are confined to one area of code. As I add functionality to one, I could just copy and paste the same changes into the second file, but I imagine that this is what good version control is meant to simplify.

My best guess is that I should create a second branch (say, 'branch_B') and keep a copy of the file with the same name in both branch_A and branch_B (so that they can be merged easily). But then, when I merge, won't I end up with a weird combination of the two files in the master branch, rather than an updated version of the second file?

A: 

Keep variation A in the master branch and variation B in branch_B. Whenever you need to make changes to the file, make them in variation A and merge that in branch_B. In branch_B, keep an extra commit (or a few) that contains all of the changes that make branch_B different.

honk's advice to refactor your code is good advice in general, however I do realize that sometimes that's just not possible.

Daniel Stutzbach
A: 

I confirm that:

  • if you make change in f.txt (branch A)
  • merge to branch B

only the new changes from f.txt-branchA will be reported to f.txt-branchB.

The part with the existing differences will be untouched by the merge.
(that is unless your modifications are directly within that "one area of code")

VonC
+5  A: 

Avoiding duplication of code is something you should do by refactoring your code. Version control is not meant to be a substitute for this.

Git can efficiently store duplicated content, but that isn't the point. Once you have checked out code from the repository into your working tree, you will still have duplicate code to work with. Using your version control tool in this way isn't going to make anything more maintainable for you.

See: Code reuse

Ben James
+1. The Strategy pattern is a good choice here.
Mark Peters
Thanks, Ben. I had a feeling that was the case, but I wanted to check.
thebackhand