Introduction to git

This guide should be fast forward - so I will first show you the stuff which is very important and then later write more advanced things.. also I try to put my own opinion everywhere, where possible..
I'm no git professional but I nearly work every day with it so if there are mistakes in that description please contact me and I'll correct them

getting a new repository:

either by downloading with git clone git://xyz.git (will create a remote "origin" which points to that address then)
or by initializing a current folder git init .
if you did the later one you have to manually set the remote with git remote origin git://xyz.git

about code in git:

git has 4 stages for code:
commited, added, changed and tracked, untracked
you can see all but the commited state with "git status"

committed:

  • philosophy: commit often, atomic, with nice description (important: first line 80 chars - 2nd line blank.. and after that as much text as you want)
  • special: besides other scm git doesn't name commits with numbers.. it names them with sha1-hashes based on the parent-commit, code and comment to refer to a specific commit i write [commit] which means sha1hash or HEAD" (latest) HEAD^ = 2ndlatest HEAD^^^^=4th latest or HEAD~5 = 5th latest
  • how to: "git commit" will commit all stuff from added.. "git commit -a" will commit all "changed and tracked" and "added" stuff
  • bullet proof: if you comitted something you can be very sure that you wont lose it - even if you play around
    with some of the git tools (even git reset --hard HEAD^)
    the only tools which can destroy that are the garbagecollectors
  • broswing: "git log" for displaying all commited things "git log --stat" for statistics
    git log --pretty=oneline is the reson to have only 80chars in the first line of the commit-description
  • displaying "git show [commit] also git show --stat
  • - warning: the following commands are altering the history: if you altering already commited history git will warn everyone about this so best is if you create a new branch when altering existing history and document them as good as possible
    • removing:
      • git revert [commit] - will create a new commit with the reverted code or lets you merge and then you have to manually commit
      • git reset [commit] - will remove all commits but the code is still there (but i think some files can be untracked)
      • git reset --hard [commit] - will remove all commits and also the code of it (but afaik files can be still there as untracked)
      • git rebase -i [commit] - will open you a texteditor where you can delete the commits you don't want.. warning mergeconflicts may occur
    • reordering:
      • git rebase -i [commit] - just reorder them and watch out for conflicts
    • merging (squashing): git rebase -i again.. instead of "pick" you have to write "squash" which will merge that commit in that one before
    • editing:
      editing the last one: change code you like and commit the added code with "git commit --amend" this will append that code to your last commit all other edits with "git rebase -i" - and then change the "pick" to "edit" - mergeconflicts may occur

added:

  • added code will be committed when you do "git commit"
  • it can be added with "git add" - which will also be required to track the untracked
  • to see the current changes including that of added code do "git diff HEAD"

changed and tracked:

  • display changes: git diff
  • remove changes: git checkout file
  • remove all changes git checkout -f

untracked:

  • add them with git add

branches:

  • see them as different development approaches - for the same codebase.. for example you want a tree with unstable and stable.. or a tree dev and devMystuff..
  • see git help merge for visualization
  • advantage:
    • you can just start off your stuff.. for example you can get drunk or stoned - start your crazy idea you got and on the next day you just "git diff branch1 branch2"
    • if you have multiple devs and each dev is in theory coding on stuff completely different from the other one.. so since they don't realy need each other no-one want to have merge conflicts from the other one (for example both have to set the configs in the same file).. also no one wants to have the bugs of the other one..
      (this is done for example in the linux-kernel.. at a new linux-version release torvalds is merging all stuff together disadvantage: changes which involves code over multiple branches)
  • creating a new one: git checkout [commit] from where you want to start the branch git checkout -b branchname
  • special: branchnames are actually nothing else than normal commits (the tip/HEAD of that branch).. so you can do everything which you can do with commits.. git diff [commit1] [commit2] for example to compare two branches
  • getting a commit from another branch git cherry-pick [commit]
  • listing branches git branch .. listing all branches git branch -a
  • deleting a branch git branch -D branchname

other random stuff:

  • git reflog: is the tool which allows you to see already deleted commits and get back at every development stage
  • git apply: can apply git-patches.. but sucks when there are conflicts.. (i rather use for that gnu patch)
  • git stash: people say it's useful.. i've never used it
  • you can delete everything (tracked) in your project folder except .git and get the files with git checkout branchname

git configuration:

in ~/.gitconfig i have the following: 
	
[color]
        ui = auto
[user]
        email = contact_emailaddress_will_also_be_published_at_commit
        name = my_commiter_name
[alias]
	# instead of git status you can type git st
    st = status
    di = diff
    co = checkout
    ci = commit
    br = branch
    sta = stash
    cp = cherry-pick

[merge]
	# you mergetool.. I also heared of kdediff
    tool = vimdiff

.gitignore inside a projectfolder (even subfolder) tells git which files are useless for us
example content:
	
.svn
build

.git folder in each project also allows much custom configuration..