Table of Contents

• Bash Commands
• Setup
• Set Global Variables
• Basics
• Committing
• Showing Differences
• Branches
• Merging
• Remote Repositories
• Tags
• Changing History
• Recommended Workflow
• Useful Tips

Bash Commands

Notes

• Don't type curly braces {}
• Always use bash completion to save yourself from typing more than you need to. Example: type less REA then hit the tab key to complete it to less README.txt
• Use the up arrow to run commands again to save more typing.

cd {dirname} → change directory to {dirname}

cd ~ or just cd → change directory your home directory

cd .. → change directory to the parent directory (go up one directory)

pwd → present working drectory; where you are

ls → list the files in the current directory

touch {filename} → create a file called {filename}

rm {filename} → remove (delete) a file called {filename}

mv {filename} → move or rename a file called {filename}

mkdir {dirname} → make directory {dirname}

ls {dirname} → list the files in {dirname}

rmdir {dirname} → remove directory {dirname}

rm -r {dirname} → remove directory {dirname} and all of its contents (recursively)

less {filename} → look at the contents of {filename} (press arrows to go up and down, press "q" to quit)

clear or control+L → clear the terminal.

Editing a File in Unix (Linux or Mac OSX)

nano {filename} → use arrows to move, Ctrl-O, enter, Ctrl-X to save and exit

Editing a File in Windows

notepad {filename} → save and quit to get back to the terminal

Setup

mkdir gitorial → this is where our project will be stored

cd gitorial → enter the directory

git init → initialize the current directory as a new git repository

ls -a → see the new .git directory which git made

ls .git → see all the cool stuff that git made for you

Set Global Variables

Notes

• When no -- tag is used, configurations end up in .git/config in the current repository. These only affect the current repository, and have highest priority.
• When --global is used, configurations end up in ~/.gitconfig. ~ means your home directory. These only affect the current user on this machine, and have second-highest priority.
• When --system is used, configurations end up in /etc/gitconfig. These affect every user on this machine and have the lowest priority.

git config --global user.name 'Your Full Name' → the name that shows up with each commit you make

git config --global user.email 'youremail@yourdomain.tld' → the email which shows up with each commit you make

git config --global color.ui true → show colour in the terminal

git config --global alias.l log --graph --decorate --oneline --all --date-order → use git l to make very useful graph logs

git config --global merge.conflictstyle diff3 → make merge conflict's easier to fix

git config --global core.editor notepad → default editor for Windows

git config --global core.editor nano → default editor for Unix (Mac OSX and Linux)

Basics

git help {commandname} → learn more about {commandname}

git status → show the current status of the git repository

git log → show the project's commits, most recent until least recent

git log -p → show the changes introduced as well

git l → we made an alias for this earlier, show the entire tree of the repository in order of time (most recent to least recent). Shows the hashes for each commit at the beginning of each line. "HEAD" is the current commit which your repository is pointing to, meaning that your files will look like HEADs files, except for the changes you have which are either staged or not staged (git status shows these changes).

Committing

git add {filename} → stage {filename}'s changes, or add {filename} as a new file.

git commit -m 'message' → add a commit of whatever is currently staged with a message

git commit -a -m 'message' → add a commit of all changes in the current directory with a message

Showing Differences

git diff → show difference between what has been staged and what hasn't.

git diff --staged → show the difference between what has been staged and the previous commit.

git diff HEAD → shows both: the difference between how your code looks in your directory, and the previous commit (called the HEAD).

git diff {hash/branch/tag} → compare the current directory to the commit with {hash/branch/tag}

git diff {hash/branch/tag} {hash/branch/tag} → compare two commits, branches, or tags (any combination). If done in order { oldest } { newest } it makes most sense.

Branches

Notes

• Branches are pointers to commits. If a commit is not dangling down underneath a branch, it is "deleted". (You can get it back, but it's not a very nice process.)

git branch → look at local branches

git branch --all → look at local and remote branches

git branch {branch} → create a branch called {branch}

git checkout {branch} → checkout a branch. Your files will now look like they did in the commit which {branch} points to. Make sure your working directory is clean before switching branches (nothing staged or unstaged).

git checkout -b {branch} → create {branch} and check it out at the same time.

git branch -d {branch} -b → delete {branch}. If the branch is not merge into another branch, all dangling commits will be deleted.

git checkout {hash} → checkout a specific commit. Make sure to create a branch right after doing this, or any new commit you make here will disappear when you checkout somewhere else.

Merging

Notes

• If only one branch has changes on it, it is a "fast-forward" commit.
• If there are changes to both in the same line of a file, then there can be a "merge conflict"
• During a merge conflict, diff3 shows the local file, the merging file, and the common ancestor (very useful). It looks like this:

  <<<<<<<
  changes made on my branch
  |||||||
  the common ancestor version
  =======
  changes made on the branch which is being merged in
  >>>>>>>
  

• To resolve a merge conflict, get rid of the <<<, ||||, ====, and >>>> lines while resolving the code how it should be.
Then use git commit

git merge {branch} → combine two branches (the current branch, and {branch}). The current branch will be automatically updated to point to the new merge commit.

Remote Repositories

git clone {url} → clone a remote repository into its own directory under the current directory

git pull or git pull origin {branch} → fetch all changes from the server and automatically update fast-forwardable changes from the default remote repository into the current branch or into {branch}.

git fetch origin {branch} → bring in changes, but do not fast-forward anything. You can later use git pull to fast-forward them.

git merge origin/master → merge your changes in with the changes on the remote master branch which you pulled or fetched.

git push origin → push all of your branches to the remote repository

git push origin {branch} → push {branch} to the remote repository

git push origin --delete {branch} → delete a branch from the remote repository. WARNING: make sure it's merged into another branch first, or all of its commits will disappear.

Tags

Notes

• Mostly used for version numbers.
• Don't have branches, tags, or files which share the same name. It makes things complicated.
• Like branches, but more permanently associated with a specific commit.
• Can be used almost anywhere {branch} or {hash} can.

git tag → show tags

git tag -a {tag} → add a tag at the current commit.

git tag -d {tag} → delete {tag}.

git push --tags origin → push your tags to the server.

Changing History

Notes

• WARNING: Do not change history to anything which is already on the server, and which someone else could have pulled onto their machine. This will cause large headaches.

git commit --amend → commit what is staged, but instead of making a new commit, add it to the most recent one. (Make sure most recent one is also not on the server already.

git reset --hard {hash} → move the current branch to {hash}. Commits which are no longer being held up by a branch are lost.

git revert {hash} → apply the opposite of the commit {hash} on top of the branch. This does not change history and is always safe to do because it adds negative history (in a way), rather than removing actual history.

git rebase {branch} → git will go to the current branch and {branch}'s closest common ancestor. Then it will apply each one of the current branch's commits (in order) as if it was done to the end of { branch } rather than in the middle of it. This effectively turns history into a straight line. { branch }'s history is not changed, but the current branch's history is changed.

Recommended Workflow

Notes

• master branch is what everyone else looks at and uses.
• Create your own branch, and work exclusively on it. You can create as many branches as you need.
• If you end up working on the wrong branch, don't panic. See git help stash.
Try not to commit when your code does not compile. If you must, make it known in the commit message. Do not push non-compiling commits to master.

To be done often

git pull origin

git rebase master → Only run this if your branch is not being used by anyone else, or if all your changes on that branch are local. If this has any merge conflicts at all, run git rebase --abort and use git merge master instead.

To be done when you have something for other people

The things in the previous section (pull, rebase/merge)

Test your code to make sure it does exactly what you want.

git checkout master

git merge { branch } → Where { branch } is your working branch.

git push origin master → If you've made changes to the master branch.

git push origin { branch }

Useful Tips

gitk can be useful for scanning through many changes.

Useful Aliases

git config --global alias.co checkout

git config --global alias.ci commit

git config --global alias.st status

git config --global alias.di diff

autocompletion of git commands

Further Reading

git help bisect → find out where a bug started.

Git Official Book

Interactive Introduction To Git

stackoverflow → A great place to find help.

Now Go Practice! :)