I am a beginner developer and I have been wondering from the start, how do professional use tools like GIT and Subversion (I don't have a very good understanding about these tools), to fulfill their project's needs. If they do use it, how would I set up something like that?

My applications are not so large and I am not working in a team yet, would they be of huge help to me?

There are questions on this site about how to use the tools, but I need beginner support.

  • 5
    Git and Subversion come with instructions; they are basically a repository that stores development code in a structured way. Individual developers benefit from having a complete record of code changes, and a robust backup facility. Project teams benefit from the ability to share the same source code repository, keeping changes in sync between workstations. Nov 6, 2012 at 22:55
  • 1
    How Scott Chacon does it at GitHub
    – user16764
    Nov 6, 2012 at 23:37

4 Answers 4


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

  • 1
    Good answer except one point. I would definitely not pick subversion needing server as it's biggest drawback, partly because I've actually used it without one quite often; the repository can live in local directory and than the setup is single command. The main difference between Git and Subversion is that the distributed systems like Git are much more flexible than the centralized ones like Subversion.
    – Jan Hudec
    Nov 7, 2012 at 14:20

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

  • 1
    Not giving +1, because learning Subversion as first system is kind of contra-productive these days when everybody is switching to distributed systems.
    – Jan Hudec
    Nov 7, 2012 at 14:22

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

  • ‘Git does not seem to work yet on IBM i "native" source files)’ — Git should work on any file. What’s the issue here? Jun 15, 2018 at 14:41
  • @MarnenLaibow-Koser Most IBM i developers are working with source files with what we might call the native (legacy) file system QSYS, where source files have a built-in fixed length format. Each line starts with an 6 digit sequence number, a 6 digit change date, then the source code text line. Sequence and change date may change even though the source code on a line has not changed. Solutions may have been developed more recently. IBM & others are now supporting git on IBM i. And it should not be an issue with source in "normal" stream files in other IFS file systems on IBM i.
    – WarrenT
    Jul 19, 2018 at 22:56
  • Oh God, I vaguely remember that from doing AS/400 development 20 years ago. But there’s no reason, I think, that Git wouldn’t work with such files. You might need to write a merge driver that discounts the line numbers, but that should be easy to do. (I wonder if that’s what IBM did...) Sep 14, 2018 at 15:34
  • But, if you strip off the line numbers and the line change date, then you've lost them when you check something back out of Git. It's not easy to convince some people that they no longer need those dates, after relying on them for perhaps 3 decades. Yes, I know Git blame provides the same thing, but people are reluctant to give up something they've depended on for so long, even if its not necessarily a logical argument.
    – WarrenT
    Dec 31, 2018 at 3:41
  • You could actually make a Git clean/smudge filter to restore the date from Git blame. :) Feb 12, 2019 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.