git clone
  Download (clone) a copy of a remote git repository

git log
  Show the commit log
git log --tags
  Show the commit log and include tags in the listing
git log -n1 --pretty=format:%h-%ct
  Show an abbreviated hash code and a unix timestamp of last commit
git log --oneline --graph --decorate --all
  A nice view of branches, tags, and other refs.

git status
  This will output some information about the state of the local copy of the
  cloned repository. It reports the branch name, the number of commits that
  have not been pushed, a list of files staged for commit, and a list of
  untracked files.

git checkout local-branch-name
    Checkout a local branch
git checkout -b local-branch-name
    Make a new local branch and checkout the code
git checkout -b local-branch-name remote-branch-name
    Make new local branch and checkout the branch
git checkout -t -b local-branch-name remote-branch-name
    Make and checkout code for a new local branch to track a remote branch

git pull
  Use this if you have no local commits that have not been pushed
git pull --rebase
  Use this if you have local commits that have not been pushed

git branch
    List all local branches
git branch -a
    List all branches (local and remote)
git branch local-branch-name remote-branch-name
    Make a new local branch that tracks a remote branch
git branch --contains commit-hash-code
    Determine which branch contains the given hash code

git stash save
    Use this if you have locally changed files (not yet committed) before
    you use "git pull"
git stash list
    Show a list of stashed change sets
git stash show
    Show a summary of what files are affected by the stashed changes, a
    count of lines changed, and an indication of the number of additions
    and deletions.
git stash show -p
    Shows a patch file output of the latest stashed changes
git stash pop
  If you stashed local changes before the pull this reapplies your changes

git add [file1 [file2] ...]
  Mark a file to be committed on next use of commit. The "git status" command
  will show the added files as staged, and the staged files will not be shown
  in the output from "git diff".
git add --interactive [filespec]
  Interactively add (stage) files for the next commit
git add -p [file1 [file2] ...]
  Selectively add changes from the named files
git rm
  Removes a file (or files) from the list of staged files. For unstaged files
  the file(s) will be removed from the filesystem and deleted from the remote
  repository.

git commit
  It usually only commits staged changes if no file names are specified on
  the command line. Use git add or git rm to stage changes ready for commit.
git commit -a
  Files that have been modified or deleted will be staged for commit. 
  Newly added files to source tree will not be staged for commit.
git commit --amend
  Make changes to a commit that has not been pushed
git push [-a]
  Push recent local commits to the remote git repository

git format-patch [-n]
  where n is the number of recent commits to make patch files for
git am
    Apply patch(es) created by "git format-patch"
git am -3
    Update "git config" info to state command options to set autocrlf,
    user, and email.
git am --abort
  Abort the patching operation and restore the original branch.
git merge --abort
  Abort the current merge operation and try to restore the pre-merge state.

git clean [-df]
  Get rid of files
git clean -xdf
  Don't use ignore files when cleaning the source tree.
  Useful when it says a merge is required to avoid clobbering some files
  so it won't change branches.
git reset [--hard]\\
git reset [--mixed]\\
git reset "file"
  Unstage a file so it won't be committed
git config [--global]
  Automatic text file line ending conversion can be set in ~/.gitconfig
  using "autocrlf = input" under the [core] section.
  The user name and email to be recorded in commits can be set in the
  [user] section.

Additional information:\\
The file .git/config has the URL for the source of the remote repository

After amending a comment for an unpushed commit that was not the\\
HEAD commit, use the following to fix up the log entry:\\
    git rebase -i HEAD~n
  where n refers to the nth commit before the current HEAD commit

<file>
TODO:
- git checkout -- <some file(s) or directory>
- git commit -a
  Will record changes in directory tree (ie. files removed via rm instead of git rm).
- Add info on cherry picking commits
- Add information about deleting a branch
  git branch (-d | -D) branch-name
- Add info on marking files as binary
- Add info on ignoring certain files so they won't get checked in
- Add how to clean up after a conflict when applying an am patch
- Add information about 'gitk' and 'git gui'
- Is a rebase in progress? Check for the file .git/rebase-apply
- git --reflog -p | grep "that stuff it deleted"
  o what should be used with the grep to find changes in danger of being lost?
- git branch --track varregion origin/varregion
- Add information about git citool ?
- Add information about using --signoff with 'git am'
- Add information about using 'git format-patch #hashcode"
- Add information about setting some config options
  user.name=Real Name
  user.email=email@my.domain
  push.default=current
  core.autocrlf=input (use auto on Windows)
- git diff [--staged]

Digging through git history
- Getting a summary of the changes (ie. a patch) for a given commit
  git show <commit-hash>
- Getting a list of files changed in a given commit
  git show --stat <commit-hash>
- Finding a commit that affected files in a given path
  gitk -- plug-ins/script-fu/scripts
- Seeing when lines where changed, when, and by whom:
  git blame

Getting a clean copy of a git repo using a previously cloned copy
From Melanie:
Do you know that you can be in any directory
and make it a work tree temporarily?
  mkdir /tmp/core
  cd /tmp/core
  export GIT_DIR=/path/to/your/clone/.git
  git reset --hard
At this point, your /tmp/core is a clean work tree
you can then apply patches and commit and push.
Once you're done, simply rm -rf /tmp/core.
Having more than one clone is a much greater risk of screwups
than managing multiple work trees.
git isn't designed for more than one clone per box, not really.
They can be different versions relative to origin which isnt't good.
</file>