Git – Should we use a monorepo

I can't be the only one to think of the Xzibit nested items meme, right? Anyway...

One of the remaining cool things that Subversion does is called "externals." It's a way to point at a specific branch or directory in another svn repository. You can even pin it down to a specific version of a specific directory. Externals are really darn nifty, and would solve this problem in an instant, as changes made in an externals directory are automatically pushed back to the source when doing a commit.

Externals is also something missing in git. Git has submodules, but they don't work in the same way, in that they're tied to a specific commit. This effectively means that there's no native solution to the problem of having "nested" repositories that can be read and written to at the same time and remain perfectly in sync, no less nested repositories using different backends.

If you don't want to do the submodule revision pinning dance, there's another workaround.

Git has decent svn emulation in the git-svn tool. You're probably already using it. The SO question "How do I keep an svn:external up to date using git-svn?" offers us a useful option by abusing that tool.

The accepted answer was simply using git-svn to check out the Subversion repository outside of the tree controlled by git, simply using a symlink to point to it inside the tree. There's a bit more manual work involved in this one, as you would need to remember to commit that specific repository every time you make a change in it. However, it's simple, it's straight-forward, and it is known to work.

Another option entirely would be looking at Mercurial's subrepositories, which can host both git and svn. I'm not sure if you really want to go three levels deep.

Source control is ubiquitous--one might even say you can't call yourself a professional developer if you are not using it. Even when developing alone, source control still offers quite a few benefits. In the end it provides both a history and an extensive undo path. It also frees you up to experiment a lot more, secure in the knowledge that if you do not like the new version, you can always switch back to what you had before.

That said, workflows, even within a source control system like Subversion or Git, vary immensely from team to team. The best place to start is probably to pick a source control system and get familiar with its standard workflows (keeping in your head that you will have to switch workflows throughout your professional life).

For getting started, I would recommend Git. I am a Git fan, but more specifically choosing Git gets allows you to begin by working serverless and only set up a server when it makes sense for you. Subversion, on the other hand, requires a server and setting one up, while not extremely difficult, is daunting when you are unfamiliar with that sort of thing.

Here is a good overview of the some good rules of thumb for source control in general: http://scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx

When working by yourself, you do not need a good deal of workflow. Commit early, commit often. If you start rolling out versions, tag your releases. Create branches for experiments or long divergent work (Git makes this cheaper and simpler than Subversion does).