As I talked about last week, git is a extremely powerful version control system, mainly used for archiving code. Lets start to understand git, by plunging in and creating our first repository! Lets first create our repository by creating an empty folder in the command line, and cd’ing inside of it.
onionchesse@hunger:$ mkdir GitRepo onionchesse@hunger:$ ls GitRepo onionchesse@hunger:$ cd GitRepo onionchesse@hunger:$ ls
The output of the last command is nothing, as there is nothing inside this new folder. Lets turn this folder into a git repository with the ‘git init’ command.
onionchesse@hunger:$ git init Initialized empty Git repository in ~/GitRepo
Cool! Everything inside this folder will be version controlled from here on forth, in the form of commits. The most useful command that you can learn with git is ‘git status’. It will tell you about the current status of the git repository, such as untracked files, changes not committed, and other problems.
onionchesse@hunger:$ git status On branch master Initial commit nothing to commit (create/copy files and use "git add" to track)
As you can see, git is telling us there is ‘nothing to commit’, or no files to track. Lets start by creating an empty test file with ‘hello world’ inside of it:
onionchesse@hunger:$ echo 'Hello W0rld!' > test onionchesse@hunger:$ ls test onionchesse@hunger:$ cat test Hello W0rld!
Now we have a file that we can version control. In git, you have to add files to a ‘staging’ area before you can commit them, to prevent git from tracking unwanted files. Lets add this file to the git repository and commit it! (By the way, the -m flag adds a message to the commit, to help you keep track of commits.)
onionchesse@hunger:$ git add test onionchesse@hunger:$ git status On branch master Initial commit Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: test onionchesse@hunger:$ git commit -m 'My First commit!' 1 file changed, 1 insertion(+) create mode 100644 test onionchesse@hunger:$
And now we have a file that will be version controlled in the future! Lets make a new version by changing it, then recommiting!
onionchesse@hunger:$ echo 'Hello World is for noscopers' > test onionchesse@hunger:$ git add -u onionchesse@hunger:$ git commit -m 'Next Commit.' [master 746f282] Next commit 1 file changed, 1 insertion(+), 1 deletion(-)
The -u flag to add is extremely useful! It adds all files that have been changed. This DOES NOT add new files, however. Lets prove that git is actually keeping versions, by showing history, differences and reverting back to that first commit.
onionchesse@hunger:$ git log commit 746f282f549b76ad8cff8a7f7bac76576cb47c50 Author: onionchesse <firstname.lastname@example.org> Date: Fri Oct 24 23:22:21 2014 -0400 Next commit commit 0866cdda0d3bd822b96addf5b0221063f4482f3a Author: onionchesse <email@example.com> Date: Fri Oct 24 23:19:53 2014 -0400 My first commit! onionchesse@hunger:$ git reset --hard 0866cdda0 HEAD is now at 0866cdd Next commit onionchesse@hunger:$ cat test 'Hello W0rld!
The reset command reverts the entire history of the repo back, to a specific version. The –hard flag tells git to overrwrite all changes, to go back to how it actually was at that revision. The string at the end is the version number, which you can spot (the start of) in the output in git log! It sometimes is difficult to remember actually what happened in each release. You can find the differences with the ‘diff’ command. Lets revert back to that second commit and try it out.
onionchesse@hunger:$ git reset --hard 746f2 HEAD is now at 746f282 Next commit onionchesse@hunger:$ git diff 0866cdda0 diff --git a/test b/test index 1b63bde..eb9b174 100644 --- a/test +++ b/test @@ -1 +1 @@ -Hello W0rld! +Hello World is for noscopers
The git diff takes in a version number to compare to. As you can see, between these two versions, ‘Hello W0rld!’ was “subtracted” and ‘Hello World is for noscopers’ was “added”. This continues to work across many version numbers as well.
If this doesn’t seem to useful, its about to get extremely useful in Git Basics Part 3, where i’ll talk about collaboration between developers, and branches! In the meantime, practice using git in this simple way! Maybe github may start to make a little more sense than your first time looking at it…
– [onion] chesse