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.
2
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.
4
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.
DOs:
- 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’Ts:
- 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.
2