MySQL Team Development – Best Practices for Using Different MySQL Instances

Please take a day to install version control and teach everybody on the project to use it. It's not that hard. Personally I've not used Git, but I have set up and used other version control systems and they are not that hard to get working. Make sure you choose one that integrates with your development environment. This will make using it virtually seamless.

This will not be wasted time.

The time you will lose when someone overwrites or deletes some code will cost you much more.

If you don't have version control you will also spend an inordinate amount of time backing up your project and worrying about which version everyone has and which version is on the server etc.

If you need to convince your boss make an estimate of the time that it will take you to set up and monitor any non-version control solution and add in the cost of rewriting a few days lost work. Don't forget to add in the cost of manually merging edits from 3 developers working on the same source file and the extra cost of getting that merge wrong. Good version control gives you this for free

Then compare that to the cost of getting version control - nil (if you go open source) and setting it up - 3 man days.

Don't forget that an error later in the project is going to cost more than one early on. If you have to redo the entire project because of a mistake anyone can make this will cost far more than just the rewrite time, it might cost your boss the reputation of his firm.

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.