Are there some best practices on the repository front, or some common newcomer-traps that I should avoid?

I have recently been reading about the benefits of repositories even for single-developer projects and, in addition, I am likely to start working with multiple other engineers in a short while but, how do I go from never having used a repository to setting one up - for multiple people, even!

Background: I am an electronics engineer before anything else, and while application programming has been part of that, it's never been something I've done a lot of - it has mainly been snippets of C for embedded systems where I was the only person working on it.

  • 6
    Write a program you are extremely proud of. Then take a screwdriver and jam it through your hard drive. Then realize you should of kept a copy somewhere. Tada. Or, take the same program and change something fundamental in it then try to change it back. Would of been easier with a commit history. We use these repositories because of earlier pain. Jul 11, 2013 at 12:07
  • 1
    A lot of people recommend git which is great, but at github private repos cost money. As an alternative, BitBucket allows unlimited private repos, and supports both git and mercurial. Jul 11, 2013 at 20:32

4 Answers 4


I'm a relative newbie to version control; I've used mostly SVN, a little Mercurial, and even less Git, for only a few years now. That said, I think the following is probably good advice:

  • Make small commits often.
  • When you commit changes, commit only related items together to keep things coherent. This helps later on when you're looking back through commit messages -- if you're looking for a particular change and it's one of many, unrelated things done in a commit, you might miss it. It's also helpful if you need to roll something back since you won't be rolling back unrelated changes that were committed at the same time.
  • If you're going to do something that you think will mess things up, do it in a branch and merge it in later after you get it working.
  • Write a nice overview of what was done in each change for your commit messages. If you need more information than that, you'll probably end up looking at the code anyway.
  • Link related changes together by mentioning some overarching task you're working on. This will help paint a story across commits when you look back at things later on. An example would be: "Refactoring Feature Alpha: Changed X, Y, and Z"

You might find the Hg Init Tutorial of interest; it has information on setting things up for multiple people and general usage advice.

Recently I've been reading through the (Ruby on) Rails Tutorial, and they take you through everything you'll do while working on a RoR project, including using Git; you might like to read/follow along for a few chapters of this to see how use of version control integrates with the rest of the development process, in more of a live setting.


Both GitHub and Bitbucket come with excellent tutorials on using their products with all major development environments on Windows, Mac and Linux. My best advice is to toy with a first repository, With a small HelloWorld solution to get your bearings.

  • 1
    I've actually had a go at this but the tutorial forks halfways through - it has a "As a next step, read this" part where "This" is a different tutorial that assumes you haven't done any of what the last tutorial asked you to do :/ - EDIT: I am not an unintelligent man, I can handle strange requirements, I just want assurance that I'm not shooting myself in the foot.
    – shieldfoss
    Jul 11, 2013 at 11:45
  • Out of interest, which tutorial? Jul 11, 2013 at 11:58
  • Git Bootcamp starts out with a link to a crash course "1.3 Getting Started - Git Basics." After you're done with that, you go back to Bootcamp which has next step "Download and Install Git." Well I've done that already at this point, that was part of the crash course.
    – shieldfoss
    Jul 11, 2013 at 13:39
  • 1
    You'll soon learn that documentation and instructions are not something that most coders are good at. At least, not as good as Electrical Engineers anyway. Things have drastically improved these last years fortunately, due to wiki's and blogs. All these documents are editted and reviewed multiple times, and not every flow of action can be expected. (No, i don't affiliate with Git bootcamp, lol) Jul 11, 2013 at 16:13

About getting how to start using a repository just signup on Github and create a repo. If you are having problems creating a repo you can try gitextensions. A very easy-to-use GUI for creating and managing repositories. That should take care of you having problems start to use Github. It has support for other online repo-storage websites also.

To get into the habit of using repo just make a folder containing code on your computer a repo and then start doing commits(quite easy via Gitextensions) and pushing them. Try to change things online on your repo and sync between the 2. It should become easy to grasp how it works.

That's for individual work. That's as far as my experience goes.

You can try reading this article. Helped me get started on using git. I don't use command-line much for git but it explains it all.


Like most habits, you have to just start doing it to form it. So choose a version control system that you're wanting to learn and start using it.

In your case, I'd suggest using git. You'll want it if you're going to use GitHub, but better yet, because of its distributed nature it is extremely easy to start saving data in version control. Just do a git init on your project folder and start enjoying benefits such as:

  • Ability to see what you've changed over time.
  • Undo or stash uncommitted changes.
  • Removing the fear of changing things.
  • Ability to quickly branch and tag.

Then when you're ready to use GitHub, you can just push your existing repository up into GitHub.

There is kind of a high learning curve for git, so you might choose something else like Subversion (svn). But unfortunately, with centralized (vs. distributed) systems it is harder to set up the repository initially. Git makes it stupidly easy -- I don't go without version control on even the smallest code snippets anymore.

Just playing around with version control on any project will help you get familiar with your system of choice. With Git there are some different workflows (e.g. git flow) that are used, but to start off you can just experiment.


  • Do experiment and try things out. Don't know how to branch and merge? Just try it on a sample project.
  • Do commit frequently.
  • Do learn how to view and use the history so you can get back old data.
  • Do integrate often (once you start working with others).


  • Don't be afraid. As long as it's your own repository, even if you mess things up you won't affect anyone else. And things won't get any worse (data loss wise) than if you didn't use version control.
  • Share code that breaks the build (i.e. won't compile, fails unit tests, etc.) When you're on your own it's not so important, but don't get into a bad habit.
  • 1
    I'd say don't push code that breaks the build. Jul 12, 2013 at 7:06
  • Good point, and very true with git. But not true with svn. :)
    – Allan
    Jul 12, 2013 at 14:31

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.