Git is always a great start

It’s true, the best things in life are free. git is arguably (but not many argue) one of the greatest version tracking technologies available today. In this post I will look at breaking down git and highlighting some of its prime features as a version control system. git was originally authored by the founder of Linux, Linus Torvalds. A Software beast who can push out code faster you can say svn. Linux is an operating system kernel which manages the sharing between computer hardware and software. There are many Linux distributions available which add to the Linux kernel, to name drop the popular kids; Debian, Ubuntu, Arch, Redhat, Fedora and the list goes on.

What do I need?

Basic command line skills are needed if you want to get every drop of goodness that git offers. I encourage doing a quick google search and being aware of basic shell commands such as changing into a directory, listing directory contents and running programs from the command line. If that is too much hard work, then downloading a tool such as Atlassian’s SourceTree offers a nice graphical user interface to interact with your git repository.

A single programmer still needs VCS.

Being the only person working on a Software project, it is still possible to make use of git. It can serve as a backup system if your local fles on your computer somehow get misplaced or damaged, then it’s very easy to download or clone the repository back to your computer and continue working on your project. git clone creates a copy of where your code is centrally located, for example your code could be located in a Github, Gitlab, or Bitbucket repository. With the clone command you will copy the files from the remote branch and save them to a local branch master for tracking (I will soon explain master).

Git up and running.

The benefits of making things from scratch usually outweigh the hassle. Creating a new git repository is in the same boat, and by doing it a few times will help you get a “feel” for knowing how to use it. The git init command initialises an empty git repository, change directory to the folder where your code resides and type the command git init and Voilà! you now have created a git repositry. Now if you have not found a place to store your code, I can recommend Github, Github or Bitbucket as they all offer free repositories to store your code using cloud based technology to hold your project code so it can be always available for when you need it most. Ok! I will now assume you have set up a repository on an internet hosting service. Now inside your code folder (where you have run your git init command) add your remote repository by using the following git remote add origin remote <repository URL> and replace with the URL of your remote repository Note: A remote repository URL usually ends with .git

After that and next up, is git add .. This command adds all files in the current directory to be staged for a commit. The ‘.’ is a wildcard that essentially translates to ‘all’. It is also possible to stage individual files, for example by using git add file.txt command will add the file ‘file.txt’ to the staging area ready to be commited. So your ready to commit? git commit -m "First commit. A commit always requires a message to send with the command, this describes what has been added to the remote repository. You can think about commit as you’re getting the files prepared and ready to be sent off to the remote repository.

Last but not least, we want to push the changes of the local repository up to the remote repository (the repository you have created on eg. Github). Now enter the command, git push origin master and there you go! All your code is now up on the remote repository. We are pushing all the files in our local branch master to the remote branch origin.. give that some time to sink in… and do not worry about branches I will explain more of that soon, but the key concept here is that all your files is now on the remote repository and you’re ready to continue adding/commiting/pushing your changes until your heart is content.

A team player extends a branch

When working in a team of programmers, it is “heavily advised against” that everyone works directly on the master branch as it can become messy. git branch enables the programmer to develop in isolation. A git branch is a single line of development, so say you are working on a project and you would like to add a new feature to the project, then it is a good idea to develop the feature in a branch. Try this by using the command git checkout -b my_new_feature. You have now switched branches from master to the branch my_new_feature and you’re ready to start developing your new feature inside that branch. The benefits of this are that you can do whatever you want inside that branch and it keeps the master branch free from experimential code. To analyse the previous command, git checkout switches the branch and using the -b argument creates a new branch. So if we want to switch back to master then we must execute the following command git checkout master.

So you think you’ve got the hang of it? If yes then great, otherwise that’s okay just give yourself a long coffee break and try again. It is worth the effort. So far we have covered the git commands clone, init, add, commit, checkout, push… but wait.. what happen to pull? The git pull command is effectively the opposite of the push command. For example, just say your mate is working on the same repository as you and just pushed a flashy new feature that you need to use to then create something really cool. They message you on Slack, “Yo the feature has been pushed up to the repo now, ready 2 roll!”, now it is time to pull. You are still in your code directory so now execute the following command git pull which does essentially does 2 things; 1. Fetches the feature/changes to the remote repository && 2. Integerates the feature/changes into your local branch master (providing you have checked into master).

Next up in your git crash course, merge. The command to integerate changes from one branch into another. So you’ve just finished your new feature on your current branch my_new_feature and you want to merge it into the master branch. Perform the checkout command, git checkout master so your current branch is master. You can represent this visually below:

A---B---C my_new_feature
D---E---F---G master

Great so we have 2 lines of development, my_new_feature is one and master is the other. Now we want to actually merge the 2 lines of development so we just have 1. To do this, we now execute the following command git merge my_new_feature.

A---B---C my_new_feature
/ \
D---E---F---G---H master

Analysing what has happened, the feature branch has been merged with the master branch by replaying the changes made on the feature branch and records the result in a new commit. But why don’t we just all work on one branch? Software projects can become complex in a relatively small period of time. And the complexity will continue to increase over time as more and more features/bugs are added to the project, so we want to minimise time wasted sorting out the things that aren’t actually writing code. Branching helps your Software project by being able to effectively develop new ideas without that is origin/master.

Ok that’s nice, but why git?

My answer “It’s so damn fast“ - git is smart and will be able recognise that you already have some files in the remote repository so git will not re-upload those files. This bypasses the need to re-upload an entire project every time a little change is made.

Second answer “It is used EVERYWHERE“ - re-usability is truely amazing, especially in Software. This is how we can build so fast, by leveraging exisisting technology and building on top of it. Here’s a quote churned out like nothing else 3… 2… 1….

If I have seen further it is by standing on the shoulders of giants.

What it actually means in Software - Using exisisting technology to build on allows you to create new, and interesting Software. And another programmer can use the giant you have created to build upon.. and the cycle continues.