[gayprogrammer]

There's data, and then there's metadata. Consider how you want to shift information between your files of data (variables), and the tree-like structure in a version control timeline.

You shouldn't need to record how the data changes directly alongside the data. That would be like commenting out old code for every change instead of making new commits. It just defeats the purpose of using version control.

Branching is metadata about how you have based changes off a given starting point, and committing records the actual, linear changes. Nobody ever said a branch must be merged into another branch--that's just typical of how bugs get fixed--it's not important to the tree data structure.

I would think that switching branches to see the code of some specific model would simplify my workflow; I would only have to manage a single set of data, instead of accommodating multiple model versions in my working directory. If you are going to be recording version/parent information every few lines of code anyway, then you might as well do it in a tree/timeline data structure with lots of tooling available.

You're right that branching could be a lot of overhead done manually as you are, but automating git (for example) to create or switch branch should not be difficult nor particularly slow. There are also ways you can avoid being overwhelmed by noise such as searching branches from only specific commits, limit the depth of results, etc.