CODEWITHSUNDEEP
gitversion-control
13ren
13ren

Reputation: 12187

experimental branch: how to record multiple alternative implementations?

I've set up an experimental branch in git, but I'm trying out a few different implementations of a feature, using different libraries. I'd like to keep a record of these, as my own documentation of that approach/library. My pre-git instinct is to comment out the previous experiment --- but what's the best way to handle multiple experiments in git (or version control generally)?

EDIT I should clarify these will often be little bits of code (really, parts of features), perhaps only 3-10 lines long. For example, using getenv("HOME") vs. wordexp on ~; using strcpy vs. memcpy. So there could be a lot of them, for alternatives on each step of even a relatively simple feature.

As a first stab, I've made a different branch for each version - but that will get unmanageable fast.

My current guess is:

  1. implement the first experiment
  2. commit it
  3. delete the first experiment
  4. implement the second experiment
  5. commit it

Then I can just look at the log to find the particular experiment. EDIT log entry will then be commented and dated.

(Actually I'd probably like to instead comment out the first experiment while working on the second one, so I can refer to it easily - then delete it just before committing the second one).

Is that a good workflow? Is there a better/standard approach? Many thanks for sharing your experience!

Upvotes: 1

Views: 565

Answers (2)

Gary Fixler
Gary Fixler

Reputation: 6038

Using branches is the right way. It shouldn't become unmanageable. That's exactly where git shines. Branch off a commit, with a name that explains what's going on (e.g. git checkout -b featureX_fooLib), work on that, then branch off the same commit you originally branched off for the next test (e.g. git checkout -b featureX_barLib a41f38), and work there on the next example. You coulld also tag where you are before starting any of these branches - git tag featureX_libTestsBase - then for each new branch use that as the new starting point - git checkout -b featureX_bazLib featureX_libTestsBase.

I prefer not to have cruft from other places in my code, so I wouldn't want to be committing commented-out versions of old code in each new branch, but that doesn't mean I wouldn't do it; I just wouldn't have it be part of the barLib commits. One thing you could do is - from the working, final commit of the fooLib branch, save out a duplicate of the file, and don't add it to git. Now when you checkout the new barLib branch, it'll be there as an untracked file. You could also - from the new barLib branch - simply stomp over that commit's version of the file with git show featureX_fooLib:filename >filename. Now you can go in, comment out that bit, start working, and simply patch-add the new stuff for each new commit. This might be the best of both worlds.

Upvotes: 2

twalberg
twalberg

Reputation: 62439

Keep one branch per experiment and give them suitable names, maybe even "namespacing" them (i.e. git checkout -b experiments/testing-algorithm-A). Initially, these branches will live only in your local repository, but you could push them up to origin or a different repository so you have redundant copies of the experiments, just in case...

Upvotes: 1

Related Questions