Should I use Git branches to store unrelated code?

Question

I have a question about a non-standard git branching strategy.

Let's say I have a lot of small files, like scripts for instance, all largely unrelated with each other. Let's say I divide these up, into various conceptual groupings, and then commit each group of files, in turn, to different, empty, branches. So I will have an empty master and branches from that like foo-files, bar-files etc each containing completely different files and folder structure.

Some other requirements

• The branches never have to merge up to master. But may be mergable with each other, according to some naming convention, like: foo-files-master > foo-files-bobswork

• I definitely don't want separate repos because in some cases we are talking about only 1 or 2 files that are conceptually related, not enough to justify the admin overhead of a separate repo.

• I am hesitant to put all the directories on the same branch, because I don't want to have to clone all the files when I am just interested in two of thousands.

Is this advisable? Will it bite me in the future?

I searched and searched for any information on this approach and didn't find much. I found 'orphan branches' which looks to be relevant. I am going test this. But ignoring that feature for a minute, is there any downside to having a bunch of branches, stemming from an empty master, each with a completely different file structure?

Answer 1

Like you mentioned, you can accomplish this with orphan branches.

git checkout --orphan script-branch
git reset --hard
touch my-script.sh
git add my-script.sh
git commit -m 'Script commit'

Now if you do a git log, you will only see 'Script commit' in the history.

There is nothing inherently wrong with this approach, but there are some pros and cons:

Pros:

• Low overhead: Your new branches are easily accessible by everyone who already has access to your repo. All you have to do is checkout the branch and you're ready to go.

• Separation: Since your scripts are in a separate branch, they can be maintained separately and have their own separate git history.

Cons:

• Unusual organization: Typically people expect branches to be a modified version of the master branch. You will need to clarify your scheme to other developers.

• Can't access both at the same time: You will not be able to access your scripts while you have master checked out and vice-versa. You can solve this by cloning your repo twice, but that may complicate things.

• Heavy clone: You mentioned that a separate branch will save you from having to clone the whole repository, but you will do that anyway. If you run clone normally, git will clone every branch including your master branch regardless of which branch you have checked out. You can use the --single-branch flag to only clone one branch, but that would somewhat nullify the utility of having the branch in the same repo.

Alternatives:

• Include your scripts in a directory in your master branch. Yes, this means you have to clone the entire repository just to get the scripts. But if the scripts are related to the code in your master branch, this is the simplest and most standard solution.

• Create a single new repo just for your scripts. You can then use directories to group related scripts. This saves you the overhead of having a separate repo for every set of scripts, but still allows you to clone it separately.