Version Control Systems<\/code> are one of the software tools that help developers manage the source code over time. They keep track of the modification, compared with different versions of the source code. As the number of lines increases, it could go up to thousands and thousands lines.<\/p>\nIn real life, it could be a disaster if we make some irrecoverable mistakes without any backups. However, this will not happen in code-writing for the developers, especially with the help of Git<\/code>, which is one of the most popular source code management system for software development. Git<\/code> has been widely used among programmers.
\n <\/p>\n
\nCompared with other Version Control Systems, such as SVN<\/code> (Apache Subversion) and CVS<\/code> (Concurrent Version System), Git is more powerful by its distributed nature, fast operation and branch handling mechanism. The distributed system makes it easy and efficient for multiple developers work together towards the same project. Git<\/code> works fast as its lightweight operations. Also every developer can work with the code as its own branch. Others can merge to different branches and this makes cooperation work quite easy. In addition, Git<\/code> is free and open-source.<\/p>\nBecause of the efficient of Git<\/code>, Github<\/code>, which is the web-based repository hosting service platform, is also popularly used. You can find many useful materials\/codes in Github<\/code> with the link here<\/a>.<\/p>\nIn this article, we will go over the basic principles and operations of Git<\/code>. All the examples below is shown in MacOS EI Capitan Version 10.11.3 and the Git version is 2.5.4. Note all the operations below is working on local machine, without connecting to Github.<\/p>\n2. Git installation<\/h2>\n
Before we dig into the principles and operations of Git<\/code>, we need to have the tool and install Git<\/code>. To install Git<\/code>, two ways could be used:
\n(1) Use the command line: For different operating systems, different command line may be used in terminal. For example, for linux, sudo yum install git-all<\/code> could install Git<\/code> successfully. For more detailed installation methods on other system, you can follow the tutorial here.<\/a><\/p>\n(2) Use the package: Also, it’s easier if you could find the installation packages for Git<\/code>. Then you can download it and easily install it by click the package. It also provide the GUI for Git<\/code>, which makes it user-friendly. The Git<\/code> community provides information for different systems, such as MacOS, Windows, Linux and Solaris. For detailed packages download, you can refer to the link here<\/a>.<\/p>\n3. Basic concepts and principles<\/h2>\n
Firstly, we need to get used to the repository concepts. In Git<\/code>, there will be three repositories or areas. If we consider the usage of Github<\/code>, then we need to understand the remote repository. To make it clear, we use the following flow to demonstrate how the git works.<\/p>\n![\"gitflow\"](\"http:\/\/examples.javacodegeeks.com\/wp-content\/uploads\/2016\/04\/gitflow.jpg\")
<\/a>Git working flow<\/figcaption><\/figure><\/p>\n\n- Workspace<\/strong>: it\u2019s the place where you see in your computer system, or the directory where you check out your files. Files in the workspace could be added to the Git by using
git add<\/code> command. Basically it could be any folders in your computer.<\/li>\n- Index<\/strong>: it\u2019s also called stating area. It\u2019s an invisible space where you can add files that you want to commit. To add commit, you can use
git commit<\/code> command.<\/li>\n- Local repository<\/strong>: it\u2019s also an invisible repository. Actually it\u2019s stored in the .git folder, which is hidden in the folder you created.<\/li>\n
- Remote repository<\/strong>: this could be another computer, or it could be the server of others, such as Github, which we can consider it as a remote repository. To access to the remote repository, git push or
git pull<\/code> could be used.<\/li>\n<\/ul>\nIn addition, we also need to be familiar with some other common concepts in Git<\/code>.<\/p>\n\n- Branch<\/strong>: it’s used to create another line of code. Usually it’s for creating another new feature. Once the new feature has completed, it can be merged back the the master branch.<\/li>\n
- Master Branch<\/strong>: we can consider it as the main branch\/code to work on. You can add other branches if needed. But the whole project can only have one master branch.<\/li>\n
- Commit<\/strong>: it holds the current state of the repository. It can be considered as a node of a linked-list. Every commit has a pointer to the parent commit object. You can go back to the parent commit object by changing the pointer.<\/li>\n
- HEAD<\/strong>: it is the pointer to the most recent commit on the current branch. It\u2019s actually a hash value of current commit, which is calculated by SHA-1 hash on a file with a hash value of 160 bits that uniquely identifies the contents of the file.<\/li>\n<\/ul>\n
4. Git operations<\/h2>\n
After we understand the repositories and basic concepts of Git<\/code>, we will move to the operations of Git<\/code>.<\/p>\nBefore we go to the detailed example, make sure git is installed on your computer\/laptop. Then open the terminal, try to run git --version<\/code>, you will see the version of the Git you\u2019ve installed as below:<\/p>\nWXMs-MacBook-Pro:~ WXM$ git --version\ngit version 2.6.4 (Apple Git-63)\n<\/pre>\nTo have a basic idea of what command you’re going to use, you can refer to the table below:<\/p>\n
\n\n\ngit command<\/td>\n functions<\/td>\n<\/tr>\n \ngit init<\/td>\n create a new local repository<\/td>\n<\/tr>\n \ngit clone<\/td>\n download a project and its entire version history<\/td>\n<\/tr>\n \ngit add<\/td>\n add file to the stating area<\/td>\n<\/tr>\n \ngit commit<\/td>\n add file from staging area to local repository<\/td>\n<\/tr>\n \ngit status<\/td>\n list all new or modified files to be commited<\/td>\n<\/tr>\n \ngit diff<\/td>\n show files differences to be staged<\/td>\n<\/tr>\n \ngit log<\/td>\n list version history for current branch<\/td>\n<\/tr>\n \ngit rm<\/td>\n delete file from the working directory<\/td>\n<\/tr>\n \ngit reset<\/td>\n undo commits and change back to specified one<\/td>\n<\/tr>\n \ngit push<\/td>\n upload all local branch commits to github<\/td>\n<\/tr>\n \ngit pull<\/td>\n download bookmark history and incoorparates changes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n4.1 git init command<\/h3>\n
After checking the installation of Git<\/code>, we need to create a folder in our computer. So we create a blank folder named GitTutorial. Then go into the folder and type command git init<\/code>. This command will change this folder to be a repository which you can manage. Also, the output after you type git init<\/code> shows that you\u2019ve successfully created and initialized an empty git repository. After running ls -ah<\/code>, you will see there\u2019s a .git folder inside the GitTutorial folder. This folder is utilized to track the git folder. Make sure you won\u2019t change it, which may lead to errors happening to the whole git folder. Also note that .git folder is hidden by default, and you can use the previous ls -ah<\/code> command to make it visible. <\/div> <\/div><\/p>\nFor all these operations, you can check the result below:<\/p>\n
WXMs-MacBook-Pro:~ WXM$ cd Documents\/\nWXMs-MacBook-Pro:Documents WXM$ cd GitTutorial\/\nWXMs-MacBook-Pro:GitTutorial WXM$ ls\nWXMs-MacBook-Pro:GitTutorial WXM$ git init\nInitialized empty Git repository in \/Users\/WXM\/Documents\/GitTutorial\/.git\/\nWXMs-MacBook-Pro:GitTutorial WXM$ ls -ah\n.\t..\t.git\n<\/pre>\n4.2 git add command<\/h3>\n
Secondly, we can use a text file as an example in usage of Git. Inside the GitTutorial folder, create an empty txt file with name GitExample.txt. Then add any words in it with: This is a txt file for Git Example.<\/p>\n
Lastly, we need to add the GitExample file into the Git system. Then run git add GitExample.txt<\/code>. This command will add the txt file to the staging area, which is a middle area between workspace and the local repository.<\/p>\nWXMs-MacBook-Pro:GitTutorial WXM$ vi GitExample.txt\nWXMs-MacBook-Pro:GitTutorial WXM$ ls\nGitExample.txt\nWXMs-MacBook-Pro:GitTutorial WXM$ cat GitExample.txt \nThis is a txt file for Git Example.\nWXMs-MacBook-Pro:GitTutorial WXM$ git add GitExample.txt \n<\/pre>\n4.3 git commit command<\/h3>\n
Then, we need to add this file from staging area to local repository. To achieve this, we can run git commit -m \"First time writing the txt file\"<\/code>. Note the string after -m is the comment that we make by ourselves. It can be anything you want to comment. Below shows the results of all these operations.<\/p>\nWXMs-MacBook-Pro:GitTutorial WXM$ git commit -m \"First time writing the txt file\"\n[master (root-commit) 9f3fca6] First time writing the txt file\n 1 file changed, 1 insertion(+)\n create mode 100644 GitExample.txt\n<\/pre>\n4.4 git status command<\/h3>\n
Afterward, we can check the status of the whole folder with command git status<\/code>. Then it seems to be everything if fine until now.<\/p>\nWXMs-MacBook-Pro:GitTutorial WXM$ git status\nOn branch master\nnothing to commit, working directory clean\n<\/pre>\n4.5 git diff command<\/h3>\n
The main purpose for git diff<\/code> command is to show changes of the file between commits, commit and working tree, etc.<\/p>\nTo make it work, we need to create some differences. As a start, we modify the content in the GitExample.txt file and add one more line with \u201cOne more line\u201d. The content in side the txt file now is:<\/p>\n
This is a txt file for Git Example.\nOne more line.\n<\/pre>\nAfter this, we can run command git diff<\/code> to check the difference between the current version with the previous one, the output is:<\/p>\nWXMs-MacBook-Pro:GitTutorial WXM$ git diff\ndiff --git a\/GitExample.txt b\/GitExample.txt\nindex 30e6813..8c7c8d2 100644\n--- a\/GitExample.txt\n+++ b\/GitExample.txt\n@@ -1 +1,2 @@\n This is a txt file for Git Example.\n+One more line.\n<\/pre>\nThen we can see that the sentence with \u201c+\u201d shows that where we add some contents to the file. Also we can predict that “-” operation shows we delete some contents from the file.<\/p>\n
Then if we made another change to the the txt file and add another line with \u201cI love changing things.\u201d Until now we\u2019ve made three changes \u2013 adding three lines compared with the first version. The four commits are : Love making changes <- Made changes again <- Add bad words <- First time writing readme file, where the arrow shows the order of the changes.<\/p>\n
Another useful git diff command is git diff --cached<\/code>, it\u2019ll show the differences between the index and the most recent commit. After running this command in our example, it sows nothing. The reason for this, is that until now, there\u2019s no difference between the index and most recent commit.
\nThen if we want to check the difference between the working directory and he most recent commit, git diff HEAD<\/code> could be used.<\/p>\nHere, we check the status of our current system, with the help of git status<\/code>:<\/p>\nWXMs-MacBook-Pro:GitTutorial WXM$ git status\nOn branch master\nChanges not staged for commit:\n (use \"git add ...\" to update what will be committed)\n (use \"git checkout -- ...\" to discard changes in working directory)\n\n\tmodified: GitExample.txt\n\nno changes added to commit (use \"git add\" and\/or \"git commit -a\")\n<\/pre>\nIf we add the txt file to the index with command git add GitExample.txt<\/code>, then run the git diff<\/code>, it shows nothing. That\u2019s because right now the content in the working directory and the index are the same. This time, we run the command git diff --cached<\/code>, it shows the content below instead of showing nothing as previous.<\/p>\nWXMs-MacBook-Pro:GitTutorial WXM$ git diff --cached\ndiff --git a\/GitExample.txt b\/GitExample.txt\nindex 30e6813..8c7c8d2 100644\n--- a\/GitExample.txt\n+++ b\/GitExample.txt\n@@ -1 +1,2 @@\n This is a txt file for Git Example.\n+One more line.\n<\/pre>\nTo check the status, run command git status<\/code>:<\/p>\nWXMs-MacBook-Pro:GitTutorial WXM$ git status\nOn branch master\nChanges to be committed:\n (use \"git reset HEAD ...\" to unstage)\n\n\tmodified: GitExample.txt\n<\/pre>\nUntil now, there\u2019s still difference between the index and the most recently commit. It can be proved by running git diff HEAD<\/code><\/p>\nWXMs-MacBook-Pro:GitTutorial WXM$ git diff HEAD\ndiff --git a\/GitExample.txt b\/GitExample.txt\nindex 30e6813..8c7c8d2 100644\n--- a\/GitExample.txt\n+++ b\/GitExample.txt\n@@ -1 +1,2 @@\n This is a txt file for Git Example.\n+One more line.\n<\/pre>\nHowever, after we commit the file and rerun the previous command again, it shows nothing.<\/p>\n
WXMs-MacBook-Pro:GitTutorial WXM$ git commit -m \"Add one more line\"\n[master cb3db9a] Add one more line\n 1 file changed, 1 insertion(+)\n<\/pre>\nAlso, the status is clear right now, if we run the command git status<\/code>, it shows everything is clear:<\/p>\nWXMs-MacBook-Pro:GitDiffExample WXM$ git status\nOn branch master\nnothing to commit, working directory clean\n<\/pre>\n4.6 git log command<\/h3>\n
In real life of development, thousands lines of code could be changed. We can not remember it exactly. So git log<\/code> should be useful right now, and it\u2019ll show all the change history we have made. We can try it with our own example here after we made three commits in our previous part:<\/p>\npcp352933pcs:GitTutorial WXM$ git log\ncommit 67713e5af45b67aa2628b12a73d4b493a16de159\nAuthor: Jun \nDate: Sun Apr 24 17:19:12 2016 -0500\n\n Love making changes\n\ncommit 47640c18cf433c6f6c7ba26b34f886688d34a1d3\nAuthor: Jun \nDate: Sun Apr 24 17:18:38 2016 -0500\n\n Made changes again\n\ncommit 1f50e80eb551e3ed7981251378d4609e30248d2f\nAuthor: Jun \nDate: Sun Apr 24 16:58:21 2016 -0500\n\n Add bad words\n\ncommit d90715179d20e10c5d88fc8d8a58972605fb38c0\nAuthor: Jun \nDate: Sun Apr 24 16:32:28 2016 -0500\n\n First time writing readme file\n<\/pre>\nThe above file shows every change we\u2019ve made with specific date and time. You should notice the long sequence of strings after the commit. That\u2019s the commit id, which corresponds to specific commit. Why it\u2019s not in 1, 2, 3\u2026 order? That\u2019s because Git is a distributed system. If every commit id is in order, when multiple changes happen, there should be conflict.
\nSometimes, the changes are quite a lot and what we want is just to check the changes. Then git log --pretty=oneline<\/code> could be utilized to show each commit in one line.[ulp id=’pzgfvmZhgslwSymm’]<\/p>\npcp352933pcs:GitTutorial WXM$ git log --pretty=oneline\n67713e5af45b67aa2628b12a73d4b493a16de159 Love making changes\n47640c18cf433c6f6c7ba26b34f886688d34a1d3 Made changes again\n1f50e80eb551e3ed7981251378d4609e30248d2f Add bad words\nd90715179d20e10c5d88fc8d8a58972605fb38c0 First time writing readme file\n<\/pre>\n4.7 Git undo operation<\/h3>\n
In some cases, we want to change our minds and revert the commit we have made, then Git<\/code> makes this easy to operate on. This is called git undo commit<\/code>. To make this happen, we add another line to the GitExample.txt, with \u201cBad words for others\u201d. Then we add the file to the stating area and to the local repository. The following is the process that we have done:<\/p>\npcp352933pcs:GitTutorial WXM$ git add GitExample.txt \npcp352933pcs:GitTutorial WXM$ git commit -m \"Add bad words\"\n[master 1f50e80] Add bad words\n 1 file changed, 1 insertion(+)\npcp352933pcs:GitTutorial WXM$ cat GitExample.txt \nThis is a txt file for Git Example.\nBad words for others.\n<\/pre>\nIf we want to go back to the previous version, git reset command could be used. What we use here is git reset –hard HEAD^. HEAD is means the commit of current branch. Symbol \u201c^\u201d means go back to the previous one version, \u201c^^\u201d means the previous two version and so on so forth. While it\u2019s hard to continue with multiple \u201c^\u201d symbols when there\u2019s hundreds and thousands versions.<\/p>\n
Then you can use the number directly. For example git reset –hard HEAD^ is the same as git reset –hard HEAD~1 and git reset –hard HEAD^^ is the same as git reset \u2013hard HEAD~2. Pay attention to the symbol \u201c~\u201d before the numbers and do not forget to add it.
\nFor our own example, right now the head is in 67713e5af45b67aa2628b12a73d4b493a16de159 Love making changes. If we want to go back to the previous version. Run the git reset –hard HEAD^ command and check the result.<\/p>\n
pcp352933pcs:GitToturialWXM$ cat GitExample.txt \nThis is a txt file for Git Example.\nBad words for others.\nI made changes again:)\nI love changing things.\npcp352933pcs:GitTutorial WXM$ git reset --hard HEAD^\nHEAD is now at 47640c1 Made changes again\npcp352933pcs:GitTutorial WXM$ cat GitExample.txt \nThis is a txt file for Git Example.\nBad words for others.\nI made changes again:)\n<\/pre>\nWe can see from the above, that after we run the git reset<\/code> command, it goes back to the previous version Made changes again. The 47640c1 is exactly the shortcut commit id for the previous commit.
\nThen if we want to go back to the initial status, we can go back twice with command git reset --hard HEAD~2<\/code><\/p>\npcp352933pcs:GitTutorial WXM$ git reset --hard HEAD~2\nHEAD is now at d907151 First time writing readme file\npcp352933pcs:GitTutorial WXM$ cat GitExample.txt \nThis is a txt file for Git Example.\n<\/pre>\nThen run git log<\/code>, it shows only the first version.<\/p>\npcp352933pcs:GitTutorial WXM$ git log\ncommit d90715179d20e10c5d88fc8d8a58972605fb38c0\nAuthor: Jun <wuxiaomin98@hotmail.com>\nDate: Sun Apr 24 16:32:28 2016 -0500\n\nFirst time writing readme file\npcp352933pcs:GitTutorial WXM$ cat GitExample.txt\nThis is a txt file for Git Example\n<\/pre>\nHowever, if one day we find that the lines we added are useful, could we go further and get it back? Yes, we can! If the terminal is not closed, we need to find the commit number which the version is. For example, the commit number for Love making changes version is 67713e5af45b67aa2628b12a73d4b493a16de159. Then we can use the git reset --hard<\/code> command with the commit id following it. Note that we can use the first few numbers of the commit id in most case.<\/p>\npcp352933pcs:GitTutorial WXM$ git reset --hard 67713e5a\nHEAD is now at 67713e5 Love making changes\npcp352933pcs:GitTutorial WXM$ cat GitExample.txt \nThis is a txt file for Git Example\nBad words for others.\nI made changes again:)\nI love changing things.\n<\/pre>\nYou see, it\u2019s back. However, make sure you really want to go back and force. In some cases, if you don\u2019t know the commit id, you won\u2019t come back to the newest version.
\nIn some cases, that you really want to come back to the newest version. Then git reflow<\/code> could be useful for you, which will track every command you\u2019ve made. Run the command and you\u2019ll get something magic.<\/p>\npcp352933pcs:GitTutorial WXM$ git reflog\nd907151 HEAD@{0}: reset: moving to HEAD^^^\n67713e5 HEAD@{1}: reset: moving to 67713e5a\nd907151 HEAD@{2}: reset: moving to HEAD~2\n47640c1 HEAD@{3}: reset: moving to HEAD^\n67713e5 HEAD@{4}: commit: Love making changes\n47640c1 HEAD@{5}: commit: Made changes again\n1f50e80 HEAD@{6}: commit: Add bad words\nd907151 HEAD@{7}: commit: First time writing readme file\n<\/pre>\nHere we have all the commit number to each commit and each reset\/undo operation. So you don\u2019t need to worry about where you\u2019re now.
\nTo make it more clear to understand, we can use the following figure to show how it work. The HEAD works as a pointer to point to specific version. For example, if HEAD is pointer to the last version. Then after using the reset command, we can go back the initial version.<\/p>\n
![\"git](\"http:\/\/examples.javacodegeeks.com\/wp-content\/uploads\/2016\/03\/git-undo1.jpg\")
<\/a>Git undo to version 1<\/figcaption><\/figure>
\n![\"git](\"http:\/\/examples.javacodegeeks.com\/wp-content\/uploads\/2016\/03\/git-undo.jpg\")
<\/a>Git undo to version 4<\/figcaption><\/figure><\/p>\nAs we can see from the previous figure, it’s quite easy for us to change to different versions of our code. It’s just an operation of command.<\/p>\n
4.8 git rm operation<\/h3>\n