Git Basics Part 3

So far, In my git tutorials, I’ve talked mostly about version control on your own machine. With this last tutorial we will be moving to Github to store and keep a backup of any git repository you have. Github has some amazing tutorials to guide you through putting your git repository on Github, so they are a great resource if you are ever confused about Github or even git in general.

The first step in using Github is to create a Github account and a repository. Once you have your repository set up, you can go ahead with the default settings. Leave ‘Add a readme’ unchecked, if you already have a git repository on your machine. Once your repository is created, you should be able to find a link in this box, pictured below.

Copy that link, and paste it into this git command to link up your repository and the repository on Github.

onionchesse@hunger:$ git remote add origin <Github URL>

Leave the angle brackets out when copying in the url! If that goes successfully, you now have linked your git repository with the one on Github! You can issue a ‘git push’ to upload a change to Github. If you decide to make a change online, such as through the Github web UI, you can bring those changes into your repository on your computer with the ‘git pull’ command! It really is that simple. But yet, it isn’t.

The reality is that git is an easy to use program with very hard to use features embedded inside of it. Branches, Pull Requests, Rebases, and Merges are all advanced features that you should understand before actually attempting. You already did a great favor for yourself by learning the command line interface, which is really the only true way to learn git internals, to actually understand what it is doing. The first time you get a ‘merge’ conflict can be a frightening one, but that simply means that git wasn’t able to combine two commits (one from online, and one from your computer) without overwriting code! There are many tools online for fixing merge conflicts.

All in all, I wish you good luck with git, but with these guides, you should be well set off with the basics of git, enough to manage your own files from time to time! Take care, and don’t forget to commit!

– [onion] chesse

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
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
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

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 <>
Date: Fri Oct 24 23:22:21 2014 -0400

 Next commit

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

Git Basics, Part 1

Suppose you are using a computer, like you are doing right now. You probably use it most of the time to browse the web, but you also use it to create content. Suppose you are working on an essay, for example. Have you ever been in a situation where you were creating that essay, and you thought, ‘I wish I could just go back to how this essay was before today?’ No? How about that one time where you accidentally deleted all the files on your flash drive… Interested now? Git and its remote service, Github allow you to solve these problems in an extremely elegant fashion, by keeping track of versions whenever you tell it to. This has helped programmers around the world to collaborate on projects, independent of how well they know the developer!

Git is a very complicated but useful piece of software, and fully understanding it can take years of experience. However, this does not stop one from using it productively! To get started on windows, you can install git from here. Here are some terms important for you to learn, ones that you will be using every day when using git:

  1. Commit- In its simplest form, it is a version. When you want to save a version for future reference, or for backup. This can be as simple as a single addition or a large feature set (in a program). If you get confused, read commit as ‘change’
  2. Repository- Where the things you want to version control are. It is usually a folder on your computer. When you make a commit, files from this folder will be added to the repository, and will be kept version controlled. In git, every computer involved has its OWN FULL copy of the repository. To make changes, you commit then distribute them to other members.
  3. Push- A push is where you move commits from one copy of a git repository to another copy (usually on different computers).
  4. Pull- A pull is where you get new commits from another repository, to update your copy.
  5. Branch- This is a slightly advanced concept that describes a point where commits diverge. Suppose you make a commit (change). Then you reset your computer to before you made that commit, and make a different commit. The paths have diverged between these two commits, they are on different branches. Its ok if you dont understand this, I will talk about it more later!
  6. Rebase- A more advanced concept that I will talk about later. (It requires you to know about branches).

Also, keep in mind, git works best with pure text files (like code files). It works, but extremely inefficiently on other types of files. Next week, we will start with creating your first git repository, making a commit, and saving your code (or text) up on github!

– [onion] chesse