Version Control – Maintaining Two Software Versions from Same Codebase

With distributed SCMs like git or mercurial (which is what bitbucket uses), branching is still possible but often unnecessary. What you do instead is (basic workflow):

• Set up a repository in a location that is accessible for all developers (a network share, a server that people can ssh into, a third-party service like github or bitbucket). This will be your authoritative repository.
• Clone this repository onto each developer's machine, and do whatever you have to to create a suitable development environment.
• Work on your local copy; commit whenever you want to. Commits are local, so you won't hurt anyone. Be sure to pull from the central repo from time to time, so that your local copy doesn't go out of sync.
• When you have something you think is ready for production, push from your local clone to the central repo.
• On the central repo, whenever you have a version you want to mark as release candidate, tag it. This way, you can update any given clone to that exact version later on.

Since distributed SCMs allow unlimited clones to your repository, and each clone can serve as the master, you can build more complex workflows from this base. For example, you can have several central repositories: one for development, one for QA, one for production. You can use a dedicated clone just for a build server. You can use more than one clone locally; instead of branching, you just create another clone, and if it doesn't work out, you simply delete it.

Another nice benefit is that if the central repository breaks beyond repair, you'll still have several copies around; all you need to do is clone one developer's repo back to the central server and all is good (you do lose uncommitted changes on the central server though, but ideally, nobody should make changes there directly anyway, so the only thing left to do is for everyone to push their latest changes again).

Tracking databases is hard; normally, you want to track the structure, but not the data - data changes a lot, isn't really relevant for the code, and may contain sensitive information you better not make accessible that way. A common approach is to make a script that sets up the database in its current form, and maybe another that populates it with typical test data. Alternatively, you keep track of incremental change scripts - you'll have one script that creates the database as designed on day one, and then a bunch of scripts that, if applies in order, modify the database until you finally end up with the current state of things. Those are less reliable than tracking code changes though, and they require more manual work, so whatever you do, you want to have a good backup / restore plan for your production database.

Let the developer who went for a couple of months without merging fix it. Maybe they can get one big chunk of code to merge, maybe they can get a bunch of little chunks to merge one at a time. In any case, they should be doing the legwork to fix the problem, since they caused it.

What is the best way to deal with such a situation where one branch is really far away from the others?

In general, don't worry about it: it's the other developer's problem. If two branches are really too far apart to merge, then they aren't really part of the same project anymore and you have a defacto fork. If it's an open source project, that may not even be a problem.

If this developer is really brilliant, and their code is better/smarter/more important than the rest of the team combined, then it's worth making it your problem instead of theirs. Otherwise, it isn't.

To answer the literal question: the best way to deal with this kind of situation is to not get in that kind of situation.

What ways can we avoid branches getting a very large number of commits away from master in the future?

Make sure everyone notices that the developer who went for months without merging is having to fix the problem they caused. Make sure everyone knows that it's easier to commit to master frequently than infrequently, since fewer changes means fewer opportunities for conflicts.

Make sure that people know that they can pull from master to stay up-to-date with other people's changes.

"If you merge every day, suddenly you never get to the point where you have huge conflicts that are hard to resolve." --Linus Torvalds

That quote is from a talk he gave at Google, here's the transcript, and here's the video.