1. Git – Fast Version Control System 09.2011

2. Git is a distributed revision control, initially designed by Linus Torvalds. The system has an emphasis on: - Decentralized - Speed - Non linear development - Easy use of branching and merging Introducing Git

3. Why is Git better then ... Everything is local

4. Why is Git better then ... Git has a Staging Area

5. Why is Git better then ... Cheap local branching

6. Back to Subversion and the Babysitter problem With Subversion ... 1. you can't do anything without access to the Server 2. experimental changes are hard to handle, because everyone see's what you commit. Solution : don't commit your changes (remember Rails3 upgrade?) :o)

7. Git and the decentralized model Every time you checkout a repository, you have a full copy of the Repository on your local machine. This means even if you work offline or the server explodes, you can ... - write a commit or revert files - create branches and merge them into master And if you (or the server) are back online, you can push the changes back to the remote server.

8. The Staging Area The Staging area is like a loading ramp for your next commit. With git add ./filename you can add the current state of the file to the Staging Area. Hint: Of course you can add a several number of files. If one file in the Staging Area changes later, it will not affect your state in the Staging Area – you'll need to add it again. After all your changes are finished, you can commit the files from the staging area with git commit -m 'your message'

9. The Staging Area $ git status Changed but not updated: modified: test.html $ git add . $ git status Changes to be committed: modified: test.html ... [now we'll change test.html again] ... $ git status Changes to be committed: modified: test.html Changes not staged: modified: test.html

10. Stashing Remember when you start working hours on a new feature and getting interrupted by a important bug-fix? With Stashing, you can put the current changes into the background and revert your working version back to the last commit. After you committed the bug-fix, you can pull your changes back from stash. Hint: you can use multiple levels of stashes.

11. Stashing $ git status Changes to be committed: modified: test.html $ git stash HEAD is now at 5ac8faf ... $ git status nothing to commit (working directory clean) $ git stash apply $ git status Changes to be committed: modified: test.html

12. Branching and Merging Branches are really lightweight and you can easy handle multiple branches in your repository (remember that everything is local!) It's also a good convenience to create a new branch for every feature or Bug-fix and merge them back into a release Branch. Never commit changes directly to the master Branch.

13. A successful branching model

14. A successful branching model Two main branches: develop and master The master branch should always reflect the production ready state. The develop branch reflects the state with the latest delivered changes for the next release. When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes must be merged to master

15. A successful branching model - Features When working on a new feature, we'll start off with creating a new branch from the develop branch. git checkout -b my_new_feature develop If the feature is finished and ready to release, we'll merge them back to the develop branch and push it to remote. git checkout develop git merge my_new_feature git push origin develop

16. A successful branching model - Hotfixes When a critical bug in a production version must be resolved, a hot-fix branch may be branched off from master that marks the production version. git checkout -b hotfix-1.2.1 master The bug-fix needs then to be merged back into master & develop branch git checkout master git merge hotfix-1.2.1 (do the same for the develope branch)

17. Git improvements Git-Flow – easy working with the branching model http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ Gerrit – A Code Review Tool for Git http://code.google.com/p/gerrit/ Netbeans Git Module http://nbgit.org/

18. Contact checkitmobile GmbH Gerrit Wanderer Ruby on Rails-Developer Waldemarstr. 37a 10999 Berlin Tel: +49 30 921 228 61 Mail: [email_address]