2

It's a familiar scenario.

You have what you think is a great idea. Implementing it will require gutting your current code base. It may or may not work, it may work but be inefficient, etc.

If it works, you will continue from the new code. If it doesn't, you'll revert to the code prior to the experiment—but you'll keep the experiment around for reference.

You have several options:

  1. You can commit the experimental code and then either undo that commit or revert to a previous commit.
  2. You can branch, even after the fact, and then either merge the experimental code (knowing that you will not have conflicts) or just ignore the branch and continue on the trunk.
  3. If the experiment turned out to have no lasting merit, another option is to simply discard the changes.

Let's leave collaboration and even a remote repository out. Consider the case of working on a solo project with only a local repository.

Are git branches exactly what you need? Is there another facility in git that more closely matches this need? Is branching an overkill and reverting to a prior commit sufficient? Here we assume that you will not continue development on the trunk during the experiment.

What is the workflow recommended in an R&D scenario such as the one described here?

Community
  • 1
  • 1
Calaf
  • 10,113
  • 15
  • 57
  • 120

1 Answers1

1

Yes: 2.

Git branches are exactly what you need. Git is very good with everything regarding branches.

In git, branches are trivially lightweight. Branches are the main thing in git driving all the incredible power it has - compared to some other repository systems where branches are heavyweight, or afterthoughts, or not existant at all. Branches are never overkill.

Never hesitate even for a second to create a new branch in git. The creation is instantaneous and takes zero resources. Keeping a branch around forever after you merged it back into master als has zero cost, since it is impossible to delete the actual history anyways as it is now part of master, i.e. of a branch you are very unlikely to delete. You can delete them of course, it will only remove the name and nothing of the actual history - useful if you get confused by too many branch names in your (G)UI.

The only cost a branch ever incurs is to keep the commits leading up to it alive, before you merge it back into master (or into another permanent branch, for that matter). So if you really happen to have a branch with incredibly large space usage that you certainly will not need ever again, then sure, delete it after a while. But really, I don't see this as a concern; unless you happen to commit large images or other binary files to it.

AnoE
  • 8,048
  • 1
  • 21
  • 36
  • I would also say that another cost of branches is the cognitive overhead of filtering through them mentally to remember why each one exists - it's not that high a cost, but it's not zero, either – snorkpete Apr 27 '17 at 19:56
  • In any case, great answer – snorkpete Apr 27 '17 at 19:56
  • Well, it makes `git branch --list` give more output, sure. I know people who prefer to delete their old branches regularly just because of this. For some reason, it never bothered me; somehow all tools I use get along nicely without forcing me to see all branches all the time, and a "git branch --list | grep ..." is quickly written if I forgot how I named one. But an occasional cleanup is no problem, of course. ;) – AnoE Apr 27 '17 at 19:58
  • For this answer, I found it interesting to point out the fact that keeping a merged branch around takes no space inside the git repository), which, if someone is new to git, is probably not quite clear. – AnoE Apr 27 '17 at 20:01
  • I'm definitely "one of those ppl" :) – snorkpete Apr 27 '17 at 20:03