Git vs Subversion

1.1.1 Network traffic

1.1.2 Hopefully we have good repository backup

1.1.3 Clunky branch operations

1. svn copy URL1 URL2
   
2. svn checkout/switch URL2 (tea time)
   
3. uncomfortable for doing more than one quick fixes that need separate testing
   

1.1.4 Merging to trunk?

1. conflicts for files we haven't touched
   
2. diff + clean up conflicts + patch
   
3. single commit, bye-bye branch history
   
4. branch is unusable afterwards, refinements go directly to trunk
   

2.1.1 No central repository

1. No, this is not a limitation
   

2.1.2 Each node is a repo on its own

1. no real need for backup
   

2.1.3 Network traffic only when interacting with remote repos

2.1.4 Most operations happen within own repo and are often instantaneous

2.1.5 Allows alternative work-flows

3.1.1 That kernel git, Linus

3.1.2 Known as (one of) the fastest

3.1.3 Seems to scale well for big code bases

3.2.1 A lot of advanced commands

1. maybe too many for a novice, but hey, you don't need to know them to boot
   
2. fine-grained control
   
3. of course you may shoot yourself in the foot
   
   1. however, most things are re-fixable
      

3.2.2 (local) Branches are really, really cheap

1. this is what version control is mainly after, right
   

3.2.3 Allows the central repository model as well

3.3.1 Please introduce yourself

1. git config –global user.name "Andrey Kotlarski"
   
2. git config –global user.email akotlarski@vayant.com
   

3.3.2 initialize repository

1. git init
   
2. git add .
   
3. git commit -m 'Initial commit.'
   

3.3.3 …or clone existing one

1. git clone URL
   

3.4.1 unique SHA1s, not numbers

3.4.2 only initial characters can be used as long as uniquely identifiable

3.4.3 HEAD, HEAD\textasciicircum , HEAD\textasciitilde 5

3.5.1 git branch NAME

3.5.2 git checkout BRANCH/REV/FILE

3.5.3 git tag -a TAG

3.5.4 git tag -l

3.6.1 git checkout –track -b BRANCH

3.6.2 git remote add URL

1. don't switch to remote branch locally!
   

3.6.3 git pull

3.6.4 git push origin

3.7.1 git merge BRANCH

1. fast-forward merges
   

3.7.2 git rebase

1. for brave history manipulators
   
2. don't do this for public visible commits, havoc ensues!
   

3.7.3 git cherry-pick REV

3.8.1 git log

3.8.2 git status

3.8.3 git show REV/TAG/REV:PATH-TO-FILE-OR-DIR

3.9.1 avoid working in master

1. keep master clean and compilable, this is your face to the world normally
   

3.9.2 use branches for whatever little or big changes

1. instantaneous creation
   
2. commit often
   
3. it can often be in experimental state (including commits), no problem
   
4. push important branches to the remote origin for backup
   

4.1.1 man git-*

4.1.2 official site

4.1.3 Git - SVN crash course

4.1.4 Successful git branching model