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).

Source control systems (SVN, Git etc) at a very simplistic level allow you to keep the change history of files. This allows you to see how your code has changed over time and roll back changes which you may not want (e.g. the change doesn’t work as expected, you can revert the code to a previously known state). This is something that even developing on your own will become invaluable to you once you start using it.

As soon as you are working with other people in a team, the benefits increase even more as multiple people can change the same file and if the changes don’t conflict (e.g. 2 people change different sections of the file) the changes will be merged automatically. If there are any conflicts then you will be able to see your changes next to your colleagues and discuss with them how to merge the changes.

You can also create snapshots of the codebase (usually called a tag) when releasing a version of the code so that you can easily debug issues even though the main source has moved on with new features which may not have been released yet.

Here are a few useful resources:

Getting up and running Subversion and Tortoise SVN
with Visual Studio and .NET

Version Control with Subversion

Tutorials for Beginners

There are great tutorials (video and text) that can help you start from a very basic level. Git seems to have a great approach to introducing the topic in a gentle way for beginners that tells you the why first and uses repetition, definition, and graphics to help you remember the names and functions of key commands.

SVN

SVN intended to be CVS done better. CVS (concurrent Version System) worked on things a file at a time, SVN typically worked on things a directory or directory tree at a time. SVN (and CVS or other systems) may be important if you are using it at work, but my opinion is that we significantly improve our understanding of what it takes to do source control every few years, so just as you would prefer a late model computer, you should prefer a late model source control tool. It is a huge investment to change systems, and code history can be lost, although for many systems there are converters that let you migrate your code as well as history and other artifacts created by the system being retired.

Professional Source Control Meets Professional Needs

Your question “How do professional use tools like GIT and Subversion to fulfill their project’s needs?” closely relates to the question “How do teams work together without getting in each others way while still working as quickly as possible?”

The code is changing frequently with some developers making code that other developers will use, and with a variety of stakeholders needing differing levels of stability vs. innovation. Source control systems help by storing code for use by the team, keeping each change in context with versions that change with time and often also with branches that are controlled copies of the code that serve to isolate groups of changes from other groups of changes.

Bringing things back together, merging the work of many team members is a chore that in SVN and older systems was centralized and difficult. For teams using Git, merging becomes simpler and more accessible to the influence of the whole team instead of a few experts. In SVN, branching could be a personal matter, but merging often had painful impacts on the team and the movement of code back into the main line could be painful from the perspective of getting permission, avoiding breakage, and the level of effort needed the task.

From an established source control repository, professionals can fulfill other needs like diagnosing problems to their root cause. If there were versions of the code that used to work, and newly found problems that occur in the current version, it is possible to step forward and backward across the history to pin-point when the problem occurred. In SVN, this capability is immature, but in Git the search for the last working / first failing version is supported by a command called git bisect. The problem will be caused by one of the source changes between the two versions which is potentially a much easier diagnosis than a search of the entire code base.

Sorry to ramble, hope this helps you on your way toward using source control.

My team uses a home-grown team version control system. (Sadly, Git does not seem to work yet on IBM i “native” source files) But personally, once I have pulled source from that system, I use Git during my development, until the project is done and I check it back into the team VCS.

As they say in voting… commit early, commit often. As I work on new features, I commit. I commit between compiles, and at each attempt to correct compiler errors, each time I make changes during testing and debugging. This enables makes it simpler to try several variations on a theme and so easily back out of it if needed, especially when a change is coordinated across several files.

Git has improved the way I approach development.