Ok, hold on. How to “back up an organization’s source control?” Are you saying the organization in question has a source control hosting solution of some sort and needs to implement a backup strategy for the contents of said source control solution?

Or are you saying the organization doesn’t have a source control solution and they need a source control solution.

The former question is an entirely reasonable sort of question to ask. (Not one I have much expertise on, but still a legitimate question.) If your question is the latter, let me say: source control is not a backup solution and conflating the two is a mistake.

I once talked to the guy in charge of another team at a company where I was working. We’ll call him Nick (because that was his name). I found out that Nick had instituted a policy wherein each developer on the team under him had their own dedicated branch in Git to which they were required to commit/push at the end of every day no matter what state their code was in. main was to be merged into these developer branches regularly (the only sane part of the whole scheme) and the developer branches would be merged into main with PRs which had to be reviewed personally by him. Then, if something went wrong and they lost work, they couldn’t lose more than a day’s worth of work (because at the end of the day yesterday, they’d pushed their code) – or so the “logic” went. Nick was a terrible person. Don’t be like Nick. (His whole mindset was “we have to protect the codebase from these ‘junior devs’ so they don’t ruin it! And we have to protect them from their own incompetence as well!” Weird guy. Definitely had a power-trip sort of complex.)

Commits are not a box you unceremoniously dump your code in so you can ship it off to put it in cold storage on the central Git repo backup server. They’re something to be curated. Push only atomic commits. (That is, don’t put multiple unrelated changes in a single commit. Also make sure that your commit covers the whole of a single, deliverable change.) Never knowingly push commits which put the code in a broken state or commits with half-completed changes. Strive for an ideal world in which any single commit in the central repo can be safely reverted without breaking other commits. When something is broken, your organization will thank you for not leaving a mess of interrelated and interdependent commits. And when one thing needs undone, they’ll thank you for making sure that reverting a single commit will accomplish it. The structure and content of your Git history is an important part of the product just like comments and documentation. (And that segues nicely in to another point: Write good commit messages while you’re at it.) There’s nothing more satisfying than a clean commit graph with good commit messages.

(One qualifier here. What you do on your own dev machine is your own business. Make sure that what you push is well formed. How you get there, who cares. If your coding style involves “oh, while I’m here, I’ll fix this unrelated thing”, that’s perfectly fine so long as when you push the unrelated things are in separate commit. Get familiar with git add -i and/or git add -p. And of course your team likely has requirements about things being committed under the correct topic branch and stuff. Those are good rules to follow as well.)

Hopefully you’re getting what I mean by “source control is not a backup solution” at this point. Source control is for collaboration.

Personally, if I’m working on code that nobody but me is expected to touch anytime soon, I don’t put it in Git. The source control I use is called “a directory”. If I need to keep previous versions of the codebase, I copy the whole codebase into another directory. To protect against hard drive failure, I back it up to off-site storage.

I put it in Git when I publish it. Whether that be publishing to the world under a FOSS license or publishing it to my dev team at work in the central Git hosting solution we have where I work.