It is recommended that you read the Git Basics section at the end for a better understanding of how Git works internally thus giving you a better understanding of the commands themselves. There are references to the Git Basics sections throughout.
Finally, I have included some Commit Format guidelines when making commits. This promotes continuity in the git log. This is my personal style and of course is just a suggestion.
See the .bashrc section for commands that can be added to a .bashrc file you can use and expand upon. This section contains some useful Git aliases to the common commands that will be used on a daily basis. You will have to reload your Terminal or Git Bash for this file to take effect.
In the following documentation, the regular command will be first and then if applicable, in parentheses the alias will be shown. For example: git log (gl).
git pull [options] <repository> <branch>
For the most part you will be using git pull origin master.
This command will perform a git fetch and a git merge thus merging the pulled remote branch into your local checked out branch and giving you the latest version of the remote branch.
When you add the <repository> and <branch> parameters the following occurs:
- Only the specified <branch> is pulled from the specified <repository> also referred to as remote.
- The <branch> will then be merged into your current checked out local branch. Example: if you are working locally in the test branch and you call for the remote master branch, the master will be merged with test.
If only git pull is performed, you will be fetching updates to all local branches tracking the remotes, however only your current checked out local branch is merged with the tracked remote. It is best to be <repository> and <branch> specific.
If you want to force pull, use git pull -f <repository> <branch>. This will wipe out your local copy and give you the latest version of the remote branch.
git fetch [options] <repository> <branch>
The fetch command will pull down the latest commits and store them in your local repository but will not perform a merge. This is helpful if you want to keep the currently checked out branch up to date but aren’t ready to merge the remote branch. When you are ready to merge, perform git merge.
Sometimes if what you are working on didn’t work out and you just want to scrap everything, you can perform a git fetch –all and then a git reset –hard origin/master. This will wipe out your current branch and sync with the latest version of the remote branch.
This performs the following:
- Fetches all remotes without merging
- Resets the current HEAD (currently checked out branch or commit) to the specified state.
In the example above, the assumption is that there is a branch named master at the remote named origin. When we called git fetch –all it fetched the master branch and locally named it origin /master. We then reset our checked out local branch to the latest remote version of origin master.
You can also perform a git pull -f origin master.
git push [options] <repository> <branch>
For the most part you will be using git push origin master or git push origin <branch> where <branch> is the name of your local branch.
This command will push your latest commits to the remote.
It is important to note that we shouldn’t push to origin master until your code has been tested and peer reviewed.
Don’t ever perform a git push -f origin master. This command will wipe out the remote branch with your changes and your colleagues work will be lost.
git status (gs)
This command will show untracked, tracked and modified files, the current branch and if it has diverged from the server (changed since last commit).
You can use git status –short flag for a smaller footprint.
git add [options] <pathspec> (ga)
This command will add all untracked and modified files to the staging area found in the working directory so they will be ready to be committed where <pathspec> equals the file path. If you decide to use the ga alias, it will add a space so you can start typing the path.
You can also use the git add . (ga.) command to add ALL untracked and modified files to the staging area.
git rm [options] <pathspec>
This command has the same properties as the git add but it removes files from the staging area. This command should not be confused with the bash rm command. It will not remove the file from your computer. It will just remove it from the staging area when a file has been deleted. You must perform a commit after removing a file for it to be removed from the working directory.
Sometimes when you have deleted a bunch of files you want to remove them all at once from the staging area. You can do this by performing git rm $(git ls-files –deleted) or by using it’s alias grma.
git commit [options] (gc)
This command will store your current contents of the staging area into a commit with a message that describes the changes. Without flags, this command will open the bash editor vim and require you to type a message. It is better to use git commit -m “<message>” where <message> is the commit message. This way you can bypass vim and get it done in one command.
You can also perform git add -a -m “<message>” which will add all of the untracked and modified files and make the commit essentially performing git add . and git commit -m “<message>”.
Please use the following format when making commits.
Most of the time we will be committing something based on a story. When not committing based on a specific story, please still add a descriptor for easy readability of the log.
Example: “Story 19575: changed text color to black”
Example #2 without story: “Misc: added tenv6 user/pass”
There is no need to include punctuation or capitalize the word after the colon.
git branch [options] <branch> (gb)
This command lists, creates and deletes branches.
To list your local branches, perform git branch. This will list all available branches and highlight with an asterisk the current working branch.
To create a new local branch, perform git branch <branch> where branch is the name of the branch.
To delete a local branch, perform git branch -d <branch>.
If a branch won’t delete, perform git branch -D <branch>. This is the same as doing git branch –delete –force <branch>.
To delete a remote branch, perform git push <repository> –delete <branch> or git push <repository> :<branch>.
To checkout a new local branch, perform git checkout <branch> command listed below.
To create and checkout a new branch in one command, perform git checkout -b <branch>.
To merge your changes in from one branch to another, checkout the branch you will be merging into and then merge the other branch by performing git merge <branch>.
To track a different upstream branch, perform git branch –set-upstream-to=<repository>/<repository-branch> <local-branch>.
git checkout <branch> || <commit> || <pathspec> (go)
This command will switches in between branches or can be used to discard changes to files you made in your working directory. Essentially if you have made changes to a file and want to revert back to the original file use this command.
To switch to a branch, perform git checkout <branch>.
To switch to an earlier commit, perform git checkout <commit>. You only need to provide the first 7 characters of the SHA-1 hash.
To revert to the original file in the working directory, perform git checkout <pathspec> where <pathspec> is the path to the file.
git log [options] (gl)
This command will show the entire commit history so you will need to exit with q once the log grows. To narrow it down you can use the -<n> flag where <n> is the number of commits back you would like to show. Example: git log -2 will show you the last two commits.
You can also use the –since flag with a date. The easiest way is to use this format git log –since=”2015-04-27” of course substituting the date with the one you want.
To find a commit based on a string in a commit message use the –grep flag. Example: git log –grep Story.
git diff [options] <commit> || <commit> <commit> || <pathspec> || <pathspec> <pathspec> (gd)
This command will show you the differences in a single commit or file or between two commits or files.
gitk [options] <pathspec> (gitk)
Gitk is the Git repository browser. This GUI window will show a selected set of commits including the commit graph, info about each commit and the files associated in each revision.
git config [options]
You can set up configuration options that will be used for commits.
git config -global user.name “<username>”
git config -global user.email <email_address>
To list all of your settings in your Git config file, perform git config –list.
This command will get you to the Git manual.
Copy commands below into a .bashrc file and put into your User’s folder. Reload Terminal or Git Bash and give them a try.
alias gs=’git status ‘
alias ga=’git add ‘
alias ga.=’git add .’
alias gb=’git branch ‘
alias gc=’git commit ‘
alias gd=’git diff’
alias go=’git checkout ‘
alias gk=’gitk –all&’
alias gx=’gitx –all’
alias gl=”git log –color –graph –pretty=format:’%Cred%h%Creset %s %Cgreen(%cr) -%C(yellow)%d%Creset %C(bold blue)<%an>%Creset’ –abbrev-commit”
alias grma=’git rm $(git ls-files –deleted)’
alias got=’git ‘
alias get=’git ‘
Snapshots, Not Differences. (Quoted from the Git docs)
The above quote is referring to the subtle differences between Git and other VCS’s, namely CVS, Subversion, Perforce, etc. These other systems store information as a list of file-based changes made over time.
Git on the other hand thinks of its data as a set of snapshots of miniature file systems over time. Every time a commit is made or you save a state of your project in Git, it takes a picture and stores a reference to that snapshot. If a file hasn’t changed, Git doesn’t store the file again, it just refers to the previously stored file, thus promoting efficiency.
Git check-sums everything with a SHA-1 hash before it is stored and then stores a reference to that checksum. Example: 24b9da6552252987aa493b52f8696cd6d3b00373. You will see this anytime you use git log and a myriad of other commands.
Git has three main states that your files can reside in.
Committed: the data is safely stored in your local database.
Modified: you have changed the file but you haven’t committed it to your database yet.
Staged: you have marked a modified file in its current state to go into your next commit.
Below are the three main sections of a Git project, the .git directory, the working directory and the staging area.
Git Directory (.git)
The Git Directory (.git) is where Git stores the metadata and the database for you project. This is what is copied when you clone a repository from another computer and is the lifeblood of Git.
The Working Directory is a single checkout of one version of your project. The files are pulled from a compressed version of the database and are placed on the disk for you to use and modify.
The Staging Area is a file stored in your Git directory that stores information about what is going to go into your next commit. It is what is referred to as the “index”.
The basic flow is as follows:
- Files are modified in your working directory
- You stage the files subsequently adding a snapshot to your staging area
- You perform a commit, taking the files from your staging area and store that snapshot permanently to your Git directory.
If a version of a file is in the Git directory it is committed. If you have modified the file and added it to the staging area, then it is staged and if it was changed since it was last checked out but not added to the staging area, it is modified.
Tracked and Untracked Files
Every file in your working directory can have one of two states: tracked or untracked.
Tracked files already existed in your last snapshot and can be unmodified, modified or staged. Untracked files are everything else that was not present in your last snapshot and are not in your staging area.
When you edit a file, Git considers them modified since they have been changed since your last commit. You then stage these files and commit them to your Git directory.