Git Usage Tutorial

The essencial knowledge of using Git: a case study

• Undoing things
• Git Reset Demystified
• Data recovery for anything that has ever been commited
• What's the difference between HEAD and HEAD~ and HEAD^?
• git log --oneline // display commit checksums: can be used instead of HEAD

Create your working directory and the file you will test git with:
mkdir github-test-project
cd github-test-project/
touch testfile.txt
echo "some text" >> testfile.txt

Initialize Git:
git init // Initialized empty Git repository
ls -a // lists all files in folder: there is now a .git directory.
git status // will show that you have one untracked file (testfile.txt) in your git Working Directory.

(Optional) Set up a local user name and e-mail for a project instead of the global:
git config --local user.name "username"
git config --local user.email "username@users.noreply.github.com"
// will overwrite your git --global settings for this directory. This way you can use different accounts for different git projects. You can confirm these local changes with the git config --local --list command.

Add remote server to the project (i.e. GitHub):
git remote add origin git@github.com:username/github-test-project.git // to add remote named "origin". You can rename your remote to anything you like, but with "origin" you have the privilege to use git push without specifying the remote.
git remote -v // to list added remotes by name with address

The standard usage:

Working Directory and Staging Area or Index (add)
//you have one untracked file (testfile.txt) in your git Working Directory.
git add testfile.txt // adds the file to the Staging Area (aka Index)
echo "and some more text" >> testfile.txt //you change something on the file, and now you have a tracked and an untracked version of your file in git status
git add -u // adds the changes to the files that are already tracked but does not add untracked files to git. now you have - yet again - a single file shown by git status
git reset testfile.txt // un-add file = remove file from index = the opposite of git add file. If you do this, the test file will be listed as untracked one again.

Local Repository (commit)
// this is the point when making mistakes get nastier.
git commit -m "first version of testfile" // commits all your indexed (added) files with the message specified in -m "". Now testfile.txt is in the local repository, and git status shows no "to-be-committed" files.
gitk // check out the commit in the repository browser
git commit --amend // if you realize you want to change your commit message, this can happen right after you commited.

touch newtestfile.txt
git add newtestfile.txt
git commit --amend // if you want to add some new files to your last commit (you can also change the commit message this way) -- now both testfile and newtestfile will be in your first commit.
git update-ref -d HEAD // if you want to undo your initial commit (NOT RECOMMENDED!). This will not bring back the state before the initial commit, only delete the HEAD (master), so it seems as if no commit has been made in this project yet. You could also delete your .git directory and start over from scratch.

//let's add some more commit to see the proper undo method for commits
echo "some other text" >> newtestfile.txt
git add -u
git commit -m "this is the second commit" // now gitk shows already two commits

echo "some more txt" >> testfile.txt 

git add testfile.txt  // this is the last indexed file

echo "some more txt" >> testfile.txt // this is the last untracked change

git reset --soft HEAD~ // will undo the last commit in the sense as if it did not happen at all, but does not change the indexed and untracked files.

// DANGER ZONE (not Working Directory safe!)
// reverting untracked changes = overwriting with last tracked (added/indexed) version
echo "some more txt I will permanently undo" >> testfile.txt
git checkout -- testfile.txt

// DANGER ZONE (not Working Directory safe!)

// reverting commits and uncommited changes = overwriting with commited version

echo "some more txt I will permanently delete" >> testfile.txt 

git add testfile.txt 

git commit -m "a commit I will permanently delete" // this is my last commit

echo "some more txt" >> testfile.txt 

git add testfile.txt  // this is the last indexed file

echo "some more txt" >> testfile.txt // this is the last untracked change

git reset --hard HEAD // will delete everything since the last commit

git reset --hard HEAD~ // will delete everything since the before-the-last commit (it will also delete the last commit)

Upstream or Remote Repository (push)

// you have to create the remote repository before you can push to it. On GitHub this can only be done manually through your profile on the website.

git push -u origin master // the very first time you push, you have to specify remote name (origin) and branch name (master) for further usage. The -u sets the remote to be the upstream.

git push // can be used in further cases with default to origin and master.

gitk // now shows the remote branch head status

// community remote repositories exist so more people may work on the same code.

// this is when the terms merge, rebase, fork, etc. come in picture

// the thing with remotes is that they will be always upstream (chronologically behind you). This is why you have to change your local repository first, to be able to make changes on the remote.

// local-repository-safe removal of remote repository commits

git reset --soft HEAD~ // remove the last commit, as written above

git push -f // -f is for force

// this will ruin your local commit-history!

git update-ref -d HEAD // deletes the local HEAD

git reset . // remove all indexed files

touch readme.txt // you'll have to add something to git to have the HEAD position back

git add readme.txt// it can be any file you want

git commit -m "initial commit" // now you have a HEAD again

git push -f // since you have a HEAD, you can reset the remote HEAD with it.

// now you could delete the remote repo if you want (on GitHub you have to do this by hand)

// I think it is generally a good idea to initialize a new project with some uninteresting files, to have a commit history to refer to.

//to be continued with merge, rebase, fork, etc...
// use interactive rebase to clean up commit history before pushing to remote.
// with interactive rebase it is possible to rewrite all of your commit messages to be more informative (before pushing to remote). it is a great tool, but use with extreme care!

// to write formatted text for a readme of wiki page this is the reference