I’ve gotten a number of emails recently from developers that are new to Git and want to know how to easily get started with it. As I have stated before, I do think that it is very important that you have some sort of understanding of what a tool is before you begin using it, so please if you have never used Git before or are new to version control in general please read Pro Git before you blow up someone’s project.
For the rest of you: Git is a distributed version control system that was invented by Linux’s Linus Torvalds for use with managing the source for the Linux kernel. This does not mean that Git is not a cross platform tool; in fact, you can use it on pretty much every operating system in one form or another.
GitIgnore
Use the .gitignore file to make sure that you are not adding unneeded files to your source control. What’s an unneeded file? An unneeded file would be anything that your app creates, such as a binary and any configuration files for your IDE.
Don’t be Afraid to Commit
You should be committing your code locally early and often, so if there is a problem you can reset and get back to a sane place without losing work. A good rule of thumb is that if you have been working on something and have not committed in two hours, that is probably a sign of a problem; for instance, it might suggest that your code is not sufficiently modular and may need to be refactored. When commiting make sure you include a logical com
mit message. If you are working off of a bug tracker, consider including the ID or name of the bug that you are fixing with your request. A common format for commit messages is:
“Basic Info”
“More details on your commit”
Make Like a Tree and Branch
Git encourages frequent branching and merging of branches. There are a lot of branching strategies
out there but the one I prefer is to branch per feature. In my mind, this creates a logical flow of project process for the person (your manager perhaps) who is looking at the source. Be sure to name your branches in a logical way; “my_branch” is not a good name, but “feature_twitter_integration” is.
Don’t Rewrite History
Rewriting history is evil. It unnaturally alters your source control and prevents future developers from getting a clear (100% accurate) understanding of the projects progress and any issues that it may have encountered.
.
