Git Basics, Part 2

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 <onionchesse@y0l0.com>
Date: Fri Oct 24 23:22:21 2014 -0400

 Next commit

commit 0866cdda0d3bd822b96addf5b0221063f4482f3a
Author: onionchesse <onionchesse@y0l0.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

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s