Hi Iain,

It's too big a topic to give a very detailed answer here, but i'll try to give some initial pointers based on my personal experience (none of which constitutes endorsement of any kind!):

• Using WAS, you will need to have standalone sandbox environments (e.g. local environments using sqlite) 
• The most commonly used open source version control systems are git and subversion, both of which use the version control equivalent of optimistic locking by default (i.e. get latest version, change code, check for other changes and push, dealing with any conflicts).
• There are other alternatives such as mercurial, and of course commercial offerings.
• There are some conceptual & terminology differences between tools, e.g. in Subversion you push (commit) files, but in Git you push the changeset.
• If you prefer to lock files to prevent other users from modifying them, later versions of subversion can do that, but you still need to handle it with a process to some degree.
• In my personal experience, git is good for distributed working (tracking sets of changes) but has a steeper learning curve than subversion. You need to spend some time understanding how it works and choose a workflow that suits your needs (google is your friend).
• I use Atlassian SourceTree as a gui client tool for Github and BitBucket repositories, which gives me a nice way to "stash" changes for comparison and re-application when there are merge conflicts due to two users editing the same code.
• Subversion is simpler and I find the merge functionality easier to use, but you need to have access to a central repository.
• In either case, I would recommend playing with them performing an end-to-end process using text files and a server first to understand the basics. That could be a hosted service or you could install your own server. Both have plenty of free online documentation and learning resources, and I recommend reading those first, e.g. search for tutorials and look at documentation such as the git pro book and/or the subversion (red-bean) book. 
• Re: development and release tracking, you would typically use branches in the aforementioned tools to track versions of your software (or labels in some other tools). You might, for example, decide that the "trunk" latest changeset is work in progress and have branches for different releases and bespoke versions, but you might prefer to make the trunk the master release and branch changes, merging them in for release. What works best depends upon your needs. If you plan to do a lot of branching, then I would probably choose git, as it is designed for that kind of workflow. and arguably has better tracking of changesets. With git, you typically create a branch to for each feature you develop, then push your changes and issue a "pull request" to request a merge of your branched changes into the master repository.
• Tracking of changes and association with issues is typically done via commit comments - you can typically add hooks to the version control server that check them and associate them with issues in tracking systems such as JIRA. This is probably one of the last things you'll implement, but you might consider it if evaluating hosting services, which can come with these features pre-configured.

Kind Regards,

David Akerman