Getting Started with Git (for Developers)

There are very many resources on the web where you can learn about Git. See the two resources below to get started. Furthermore, this page will discuss three concepts that you need to grasp in order to get started.

• ​Git - SVN Crash Course
• ​Git Ready - knowledge base for git
• ​Pro Git - professional version control

Centralized versus Distributed

One of the main concepts to understand in the difference between Subversion and Git, is the difference between centralized and distributed version control. This is a topic much written about, and it would be a duplication to work it all out again. Have a look at ​Chapter 2 of the Pragmatic Version Control Using Git book.

The organization of the workflow will be using a shared repository. That means that on git.haiku-os.org there will be a repository that core developers are able to push to. In a sense this closely resembles the model of subversion, with the difference that everybody can start their own repository, and share it in order to collaborate on a feature before it is pushed into the centralized repository.

See this image graciously borrowed from the aforementioned book:

The staging area

A major difference between Git and Subversion is that you have to select which changes you would like to add to a commit. So from the changes in your working directory, you add these to the index, and the changes that are in the index are committed.

In Subversion, the svn add command just registers untracked files for committing, whereas git add also puts in tracked files with untracked changes into the index.

See the ​article on the staging area on gitready.com.

Editing history: rebasing and more

Unlike with SVN, with git you can edit the history of the repository. This means changing previous commits, changing the order of commits, removing previous commits and whatever more. See ​this chapter from the Git Magic resource to see how you can edit history.

A special mention is for rebasing. See the ​explanation to rebasing on gitready.com. However, rebasing is a destructive operation that sometimes destroys a part of history that you might need. Read this ​article on rebasing by Jarrod Spillers that clears up when to rebase and when not. Learn about it: it is likely that you will use it!

Editing history is destructive: you are actually destroying the paper trail. This can lead to problems when you are editing commits that are already in a shared repository. This will lead to all kinds of trouble. The rule of thumb is: you can edit history on changesets that have not left the privacy of your own home, but as soon as you shared them with others (or with other local trees) then you should perform non-destructive operations instead.