Image of Git started with the best version control system

ADVERTISEMENT

Table of Contents

Introduction

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 break down Git and highlight 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 S-V-N. 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 a VCS

Being the only person working on a software project, it is still possible to make use of Git. Git can serve as a backup system if your local files 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. The command git clone creates a copy of an existing repository. 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 - usually called master by default - for tracking. I will soon explain the term 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 it.

The git init command initializes an empty Git repository. To use it, change directory to the folder where your code resides and type the command git init - and Voilà! - you have created a Git repository.

Now, if you have not found a place to store your code, I can recommend Github, Gitlab, or Bitbucket as they all offer free repositories to store your code using cloud based technology. These cloud platforms will 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 a cloud hosting service. Now inside your project root (where you ran your git init command) add your remote repository by using the following command:

git remote add origin remote <repository URL>

Just replace <repository URL> with the URL of your remote repository.

Note: A remote repository URL usually ends with .git extension.

After that and next up, is the command git add .. This command adds all files in the current directory into the staging area, to prepare it for inclusion in the next commit. The . (period) is a wildcard that essentially translates to "all". It is also possible to stage individual files, for example by using the form git add file.txt. This will add the file file.txt to the staging area ready to be committed.

So you're ready to commit? A commit is made using the command:

git commit -m "First commit".

A commit always requires a commit message (the part in quotes after the -m flag). This allows the developer to describe what has been added to the remote repository. You can think of a commit as a set of file changes that get stored in your local Git repository.

Last but not least, we want to push the new changes (represented by one or more commits) in the local repository up to the remote repository (the repository you created using a service like 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 master. The term origin represents the remote repository. Give that some time to sink in... and do not worry about branches I will explain more about them soon, but the key concept here is that all your files are now on the remote repository and you're ready to continue adding/committing/pushing your changes to your heart's content.

A team player extends a branch

When working on a team of programmers, it is heavily advised against having everyone work on the same master branch. The git branch enables each programmer to develop in isolation. A branch is a single line of development. Assume you are working on a project and would like to add a new feature to the project. It is a good idea to develop the feature in its own branch. Try this by using the command git checkout -b my_new_feature. This command creates a new branch called my_new_feature and switches the working directory to point to the new branch. Now 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 experimental code.

To analyze 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 can execute the command git checkout master without any flags.

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 pushed a flashy new feature that you need to use in your branch. 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. In your local project root, execute the command git pull. This does essentially does two things:

  1. Fetches the feature/changes from the remote repository into your local repository
  2. Merges the feature/changes into your currently active local branch

Next up in your Git crash course is the git merge command. The command to integrate 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 two lines of development (or chains of commits), my_new_feature is one and master is the other. Now we want to merge the two lines of development so we just have one. 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

Analyzing what has happened, the feature branch has been merged with the master branch by replaying the changes made on the feature branch and recording 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 minimize 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 touching the mainline code on the master branch.

Conclusion

Ok that's nice, but why Git?

My answer:

  1. "It's so damn fast!" - Git is smart and efficient. It was created specifically to perform version control operations on large numbers of files with great performance.
  2. "It is used EVERYWHERE!" Re-usability is truly an amazing thing, especially in software. This is how distributed teams of developers can build so fast, by leveraging existing 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.

Building on existing technology allows you to create new and interesting software. Another programmer can build upon the giant you have created... and the cycle continues.

If you're interested in taking your Git skills to the next level, we recommend picking up a copy of Pro Git.

Thanks for reading and happy coding!

Final Notes