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
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
clonethe repository back to your computer and continue working on your project.
git clonecreates 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
masterfor tracking (I will soon explain
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 initcommand initialises an empty git repository, change directory to the folder where your code resides and type the command
git initand 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 initcommand) add your remote repository by using the following
git remote add origin remote <repository URL>and replace
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 branchWhen 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 branchenables 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
masterto the branch
my_new_featureand 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
masterbranch free from experimential code. To analyse the previous command,
git checkoutswitches the branch and using the
-bargument creates a new branch. So if we want to switch back to
masterthen 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
push… but wait.. what happen to
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
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
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
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
remoterepository 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.