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.
@jbc1785: I'm going to take a stab at this based on the following assumptions about your code and your team -
- You currently do not have any code in a version control system and you are new to version control
- Every developer can access and change any file in the code base
- You have multiple developers working on multiple projects in parallel
- The code is not very modular and there are some key files in your code base that need to be touched almost every time you make any change.
In your situation, I would recommend that you start off with a centralized version control system like Subversion (SVN) instead of a distributed one like Git. I have worked in places without version control systems and (as you have correctly identified) it is vital to put in place a version control tool that simple and provides a simple workflow that teaches good version control habits. Since you have a system where you have a high chance of multiple developers making changes to the same file at the same time, you should leverage a centralized tool like subversion better to reduce the amount of errors and confusion that can occur with merge conflicts.
Subversion provides a "lock" functionality that allows users to lock files that they are editing - I recommend you use this in the initial stages so that your team gets used to the concepts of checking out and editing files. The lock status will reduce the initial confusion by making clear that a file is being currently worked on by someone and that conflicts will occur if the file is changed by someone else.
As the team gets used to the concepts of version control you can disable the "lock" functionality and introduce the concept of merging files, "merge conflicts" and their resolution. Usually once a team gets comfortable with the concept of locked files, the necessary caution and communication needed for working on files in parallel gets developed.
Once the team gets used to working with Subversion, a DVCS like Git is the logical next step. It's very easy (there are multiple tools) to move from Subversion over to Git. In fact you can run Subversion and Git in parallel and migrate over. Git scores over Subversion in terms of performance, ability to scale and the fact that since it's distributed there are no single points of failure. I think the only problem with Git is that it's command syntax is a bit cryptic and it takes a bit of getting used to.
Update: Since the comments for this post are getting numerous and hidden, I thought I'd add them to the post itself in an effort to make it more easily seen.
According to @Tamás Szelei and @JanHudec, DVCS is the way to go since locking is a bad feature of centralized version control systems that should be avoided. The contention is that Subversion dont have a good merge feature and therefore uses locking as a way to get around that deficiency.
While I accept that merging in Subversion is not as great as it is in a DVCS like Git, I disagree that using locks and the workflow encouraged by Subversion is necessarily an evil thing that should be avoided at all costs. I think Subversion has its place and in certain situations (like in case of binary files - mentioned in the other answer to this question) might even be better suited than a DVCS.
This is a matter of opinion and I still believe that given the situation mentioned in the question (listed in the beginning of this answer) using Subversion is a good way to instill version control practices and workflows in a team that have never used version control before.
Best Answer
That workflow looks a lot like Vincent Driessen's git workflow model, with it's different branches for features and QA and I agree it's a lot to deal with at once. Vincent's model adds even more branches: develop branch, hotfix branches, release branches, but it is worth using.
That being said, there's two easy things that I think would make a good start:
Both are easy enough to do and shouldn't be too hard to implement off the bat. Have a stable version worth remembering? Tag it, that way you can QA a tagged version as opposed to constantly chasing the edge of the repository. Have a feature that you're not too sure about and you don't want everyone to have it yet? Build it in a branch. I'd say between those two things, you'll be doing 20% of the work for 80% of the benefit.
If however, you're still intrigued by the idea—and you should be—you should take a look at git-flow (and it's screencast). git-flow makes all of this a lot easier by building the functionality into commands like
git flow start feature fewer-clowns.