proper workflow for concurrent versions

Question

I'm a researcher in applied mathematics. I code on a daily basis, but my focus has always been science not coding so I've never learned about good software engineering practices. I'm trying to change that at least a little.

Currently I'm working on a few simulations that are relatively similar; lets call them S1 S2 and S3. I wrote the code for S1 first. Then let's say I want to write code for S2. It's similar enough that it would make sense to just copy the code for S1 and change things around a little. Is the proper workflow for this kind of situation to setup a branch in git? I'm not sure if that functionality is intended for versions of code that are meant to live concurrently or if its intended for trying out some modifications and perhaps eventually making the branch the main version of a code.

The other thing I'm finding is that sometimes when I edit S2 I see something that's either a mistake or an inefficient way to do something. So I'd like to change this code but I would also like to have the change reflected in S1. Any ways to do this efficiently or do you basically have to propagate the change in all your codes by hand? Of course an automated tool wouldn't be able to distinguish which changes I'm making are essential to the difference between S1 and S2 and which should propagate. But perhaps if the tree structure in git is exploited, the extra information it provides could be useful here?

Thanks!

Answer 1

This isn't an issue of version control; you should use whatever facility is available in your given programming language to distill the shared parts of S1 to a shared library, which S1, S2 and S3 can then import and extend. You definitely should not attempt to do this in Git.