= 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. * [http://git.or.cz/course/svn.html Git - SVN Crash Course] * [http://gitready.com/ Git Ready - knowledge base for git] * [http://progit.org/book/ 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 [http://media.pragprog.com/titles/tsgit/chap-002-extract.html 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: [[Image(http://media.pragprog.com/titles/tsgit/images/repo-shared-simple.png)]] == 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. [[Image(http://git-scm.com/images/about/index1.png)]] 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 [http://gitready.com/beginner/2009/01/18/the-staging-area.html 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 [http://www-cs-students.stanford.edu/~blynn/gitmagic/ch05.html this chapter from the Git Magic resource] to see how you can edit history. A special mention is for rebasing. See the [http://gitready.com/intermediate/2009/01/31/intro-to-rebase.html 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 [http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/ 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! {{{ #!html

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.

}}} == Hm, I'm new to Git - what if I've done a mess? == Let's hope Justin Hileman's [http://justinhileman.info/article/git-pretty/git-pretty.png Git Mess Workflow] can show you the way out ...