« Previous - Version 8/10 (diff) - Next » - Current version
kju, 04/29/2009 19:08


What is a Version Control System

Preface

Everyone who got into using source control, will never work again without!

So there must be something good about it.

Top 10 reasons for using a version control system

IT guy version

  1. Never again suffer from the confusion of juggling multiple versions of your codebase by hand.
  2. Provides a single source for backups.
  3. Multiple developers easily work against the same code base.
  4. Branches are easily managed with version control. Sometimes you
    want to experiment and take the project in a whole new direction.
  5. Commits can reference ticket numbers or bug IDs so that developers
    can easily answer the question when did we fix that bug?.
  6. Easily diff new versions against old ones to pinpoint changes.
  7. Easily integrate with a web tool like Redmine to provide project
    statistics at a glance.
  8. Plays a key role in continuous integration systems.
  9. No real software engineer or manager will take your project seriously
    unless it’s under version control.
  10. Develop with impunity. With version control you’re like a trapeze artist
    flying worry-free over a safety net.

For these reasons, I believe that just after the compiler/interpreter and debugger,
a versioning system is the most useful weapon in the software engineer’s arsenal.
If your project isn’t under version control yet, what are you waiting for?

by Robert Boyd from http://www.softwarebloat.com

Non IT guy version

Let me wrap it up in a few words.

  1. Imagine a FTP server.
  2. Now with full history of every change (version) of each file.
  3. With only up and download of actual changed code lines instead of full files.
  4. With automated merging of your and mine changes in 99% of the cases.
In short:
  • It is the real way and only way to share files within a team for coding.
  • It makes it a lot easier and way less hassle compared to FTP /
    page upload / send files via IM etc.

Normally you use GUI tools to manage the interaction - much like FTP tools
like Filezilla and not FTP on command line. Same is true for SVN/git.

Wording

What makes use of source control a bit tricky at the start is the different
wording for one part.

  • For FTP/HTTP you call it download and upload.
  • Whereas SVN calls it update and commit.
  • Git calls it push and pull.

Git specifics

For git there is one bit strange aspect to just acknowledge at the start.
Upload is split into the 4 parts.

  1. Unstage file.
  2. Staged file
  3. Committed file.
  4. Pushed file.

The background is in normal words.

  • Unstaged file: File not marked for any action.
  • Staged file: Mark file to upload.
  • Commited file: Uploaded file to local server (with comment)
  • Pushed file: Uploaded file to dev heaven server.

General thoughts

  • Directory and file structure
  • Always update
  • Frequent commits
  • Commit comments
  • Binary file handling