====== git walkthrough ======
  * this page mostly shows command line options; after you are familiar with them, learn how to use the git gui programs too for efficiency:
    * [[.:git gui]]
    * [[.:gitk]]
  * know how to get help first!<code>
git help (general overview)

git help [command], ie:
  git help init
  git help checkout
  git help branch
  git help status
  git help log
</code>
  * introduce yourself to git; this sets up your [[.:gitconfig]] file<code>
git config --global user.name "Your Name"
git config --global user.email "youremail@example.com"
</code>
  * start with an existing set of source code files to play with
  * cd inside the project root, then create a repository:<code>
git init
</code>
  * :!: (notice that a .git directory will be created at project root)
    * git is cool - the complete repository (all history) is stored inside this .git directory
    * even if you clone a repository from someone else, you have the full history available to work with - no further connection with them is required, unless you want future updates or to share code together
  * **IF YOU ARE USING CYGWIN ON WINDOWS...**<code>
git config core.filemode false
</code>
    * this tells git to ignore filemode permissions which do not work correctly on a non-unix host; if you don't do this, git will always complain that you are changing file permissions when you did nothing
  * add all content to the index (some call it the cache, it means what is staged for the next commit)<code>
git add .
</code>
  * commit the added content with an initial message<code>
git commit -m "initial import"
</code>
  * (modify some files, but don't add any new ones)
  * commit the changes<code>
git commit -a

* the -a switch will tell git to add and commit all changed files;
  if any were added, you would need to do git add for those

* when the -m switch is used, you specify the commit message here
  on the command line; when it is ommitted, your default editor
  (probably vim) will open
</code>
  * create an experimental branch<code>
git branch experimental
</code>
  * show current branches; notice * is on master, which is the default<code>
git branch
</code>
  * switch to the experimental branch<code>
git checkout experimental

* the shorthand way to create a branch and check it out at the same time is:
git checkout -b experimental

* you can also give a different reference to start the new branch at:
git checkout -b experimental HEAD~4
or
git checkout -b experimental e8f2ab
or
git checkout -b experimental sometagname
</code>
  * show branches again, with the * on experimental, indicating the current branch<code>
git branch
</code>
  * (modify some files)
  * commit all changes<code>
git commit -a
</code>
  * switch back to the master branch<code>
git checkout master
</code>
  * edit one of the files that you changed on the experimental branch, and you will see that it does not reflect those changes, because they were made while on the experimental branch and you are currently on the master branch
  * merge the active branch (master) with the experimental branch<code>
git merge experimental
</code>
  * this begins a merge operation with the experimental branch.  if there are no conflicts, your merge is complete and is ready to commit.  if there are conflicts, your files will be modified with markers designating the changes between each branch.  you can quickly see these conflicts by running git diff.  here is an example:<code>	 
<<<<<<< HEAD
exit("\nLine Count Total: $lineCount\n\n");
=======
exit("\nLine Counts: $lineCount\n\n");
>>>>>>> experimental
</code>
  * note that git will allow you to commit the files with conflicts in them!
  * once the conflicts are resolved, commit the merge with git commit -a
    * if you know that one version of the file is fully correct and doesn't need manually fixed, you can do this to update the file and tell git the file conflict is resolved<code>
git checkout --ours somefile
or
git checkout --theirs somefile

* --ours represents the file on our branch before the merge
* --theirs represents the file on the branch we are merging into ours
</code>
  * (modify one file)
  * view diff of changes<code>
git diff
</code>
  * if you have already staged some changes, git diff will not show them.  To see what the diff is with the staged changes, you need to do this:<code>
git diff --cached
</code>
  * contrary to svn, where we would run svn revert <filename>, when using git we use git checkout <filename or path> to restore the last commited state of a file, and lose any working copy changes
  * you can delete a branch with git branch -d <branch name>, and this will ensure the changes are in the current branch
  * if you want to throw away a junk branch entirely, you can use<code>
git branch -D <branch name>
</code>
  * to "go back in time" and review a project at the point of a previous commit, you can do so by creating a branch at that point and then checking it out<code>
git checkout -b old 53067

(when finished, delete the branch)
git branch -D old
</code>

===== graphical tools =====
  * you can work, including stage/unstage, commit and other items with a nice graphical representation of your changes with<code>
git gui
</code>
  * you can view a nice graphical representation of the repository with gitk; note that gitk has other possible switches/parameters
  * you can view the history of all branches with gitk --all
  * if you screw up and commit something that totally shouldn't be there, git allows you to fix it by running git reset <commit id>; note that it is much easier to use gitk and right click on a certain commit to reset
  * Mac frontend alternative is GitX: http://gitx.frim.nl/index.html

===== External Links =====
  * [[http://blog.technomancy.org/2009/1/9/how-to-go-back-in-time-in-a-git-repository|how to go back in time in a git repository]]
  * [[http://blogs.gnome.org/newren/2007/12/08/limbo-why-users-are-more-error-prone-with-git-than-other-vcses/|why users are more error prone with git than other vcses]]