2

What would be the best approach to track a slightly different version of the project in the same repository?

The differences would be in couple of functions, and 99% of the code would be the same?

freediver
  • 309
  • 1
  • 10

3 Answers3

1

Probably the easiest would be to store your changes in a separate branch.

So basically have your main project in the 'master' branch and the other version in another branch. Name it related to what it is so you don't get confused.

When doing updates, do everything through master (unless updates are specific to that separate branch) and then merge master into it to keep it updated.

RDL
  • 7,865
  • 3
  • 29
  • 32
  • Unless you keep the custom work below a merge where you explicitly omitted the custom work, rebasing will cause you headaches when working on a team. – Adam Dymitruk Mar 17 '11 at 22:03
  • @adymitruk, in my answer I was implying that they should not merge back and only merge up. If they needed to merge from the special branch back down then they should `cherry-pick` the commits to apply to the main or from the main just checkout the specific files from the branch. See here: http://stackoverflow.com/questions/4315948/git-partial-merge-not-whole-branch – RDL Mar 17 '11 at 22:43
  • wouldn't merging to this branch also bring unwanted code that we purposely ommited to make the version different? – freediver Mar 18 '11 at 10:41
  • @freediver. if `master` is the root of the project and you need to apply those updates to the `special` version, then you would need to merge master into special. If you accidentally committed updates to `special` that should have been committed to `master` then you can `cherry-pick` the ones that should also be applied to `master` and leave out the ones that are `special` specific. The other option is to checkout specific files from the `special` project into `master` that don't have unwanted code. – RDL Mar 18 '11 at 13:24
0

There are a number of ways to do it. But I think the easiest would be to probably have one branch that is where most of the development is done. Then have one "slightly different" set of code in a second branch where the only changes are the "differences that should be different" (ha). Every so often, rebase the slightly different branch to the top of the main branch.

You could also do it with 3 branches, common changes in one branch that get merged into the other two, etc. But I think the above is easier.

Wes Hardaker
  • 21,735
  • 2
  • 38
  • 69
0

You will need to initially merge from one branch to the other with an "ours" merge strategy. This will ensure that the difference does not get merged into the original branch when you do back merges.

Hope this helps.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • can you provide me a reference to that merge strategy? basically we need to be able to mark a portion of the code as 'fixed' and should not be affected by merges. – freediver Mar 18 '11 at 10:43