Recently I took a great introductory course to Git/GitHub from Udacity. Those of you who are interested in what Git and GitHub is or simply want to add a better structure to your knowledge, please, follow this link. Here I decided to post a cheat sheet with some basic commands and a bit of theory behind them that I learned from that course.
git init
git init should be executed when you are located in your working directory. When you initialize a repository, Git creates a hidden folder named .git. This folder keeps track of all the history and changes that have ever been done to your files.
git add [file name]
adds a file to the staging area. A staging area is an intermediary that Git uses to see what files were added or changed in your working directory since the last commit. These changes will not be saved into .git folder until you make a commit (read: explicitly save them).
To check the current sate of your Staging Area type
git status
Git allows you to "save" the current state of the the files in your working directory. This is called a commit. To commit a file after you have added it to the staging area type:
git commit -m "Commit message"
If commit message is too long, then a simple git commit can be used. This will open up a text editor in which a commit message can be added.
A commit does not affect the files in your working directory. It only commits ("saves") the files that have been changed and are currently added to the staging area.
!!! DANGEROUS !!! If you have done some changes, but want to disregard them, type git reset --hard to discard all the changes. But keep in mind that this command will wipe out your uncommitted work.
git log is used to to browse through the whole history of the changes in a particular repository. Having an easy access to the entire history of editing of a file can help you learn stuff by following peoples' way of thinking literally line by line, as well as it can allow you to trace back the evolution of your own code.
You can also present a log in terms of a diagram with branches (if any):
git log --graph --oneline
Or You can present a diagram with all the commits that have been done to the master, branch1 and branch2.
git log --graph --oneline master [branch1] [branch2]
In Git's terminology, to "checkout" means to extract a snapshot (restore) all the files in the repository to the state they were at a particular point. If you know the name of the commit that you want to get back to, you can checkout this commit by:
git checkout [commit name]
After you have added new files to your working directry and committed them, you can compare the difference between two commits (two versions). This can be done by ‘git diff’. Viewing a difference between two files using a 'diff' command can be pretty handy. If a bug was caused during the process of editing an existing file, using 'diff' can easily reveal that bug by showing a difference between two versions and highlighting the lines that contain pieces with different code.
You can compare a working directory with a staging area using the following command:
git diff
You can also compare a staging area with the commit 1 (the most recent commit):
git diff --staged
Or compare two commits with each other:
git diff [commit1] [commit2]
git branch can be used to check what branch is currently active.
git branch branch_name can be used to create a (new) branch of your repository.
Branches are handy when you want to introduce a new feature to your code and would like to debug it first, while keeping your current working code unchanged. You might also want to create a branch every time you you are moving to a new piece of work - when you want to make something different. Thus, a branch is like a parallel version of your code. One may have 'master' (production) branch that never fails and a 'development' branch which he/she is using to develop new features. Eventually you can merge branches back to the master branch.
Suppose you want to get away from the master branch for while and instead get back to a certain older version of our code and keep developing that version. In order to make sure that the commits you are going to make are not getting lost in the history after you come back to master again, you should create a branch. There are two ways to do this:
-
You can create a new branch and then log into that branch later by using two different git commands:
git branch [new branch name] git checkout [new branch name] -
Or you can checkout a certain commit into a new branch righ away using a single statement:
git checkout [commit name] -b [new branch name]
In case you need to recover a branch that was removed via git branch -d [branch name], it can be done relatively easy by using git reflog. This command shows the 30 days (by default) history of HEAD and can be use to find the SHA1 for the commit at the tip of your deleted branch. Once you locate the SHA1 and follow that commit, you can recreate your lost branch via:
git checkout -b [branchname]
A simple FAQ on why git reflog is so important can be found here
Sometimes it may happen that while you have been working on our feature branch, branch1, someone else has been working on master and thus a master branch has significantly evolved. Now you would like to merge master into our branch1 in order to inherit those changes. In case when some parts of the file were modified simultaneously, git will throw a conflict. In this case you should manually check the differences in both versions of the file and modify the file accordingly to resolve a conflict.
Suppose you are trying to merge branch1 with master:
git chekout [branch 1]
git merge master [branch1]
But Git refuses to do this due to a conflict. In order to finish your merging, you need to see what file has a conflict via git status, open that file and manually fix the conflict, add that file to the staging area, make sure is gone via git status and finish your commit.
git status see what file has a conflict
git add [file_name]
git status
git commit
git log -n1