Git started with the best version control system
Table of Contents
- What do I need?
- A single programmer still needs a VCS
- Git up and running
- A team player extends a branch
- But why don't we just all work on one branch?
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
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.
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>
<repository URL> with the URL of your remote repository.
Note: A remote repository URL usually ends with
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
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 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:
- Fetches the feature/changes from the remote repository into your local repository
- 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:
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.
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
Ok that's nice, but why Git?
- "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.
- "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!
Recommended product: Decoding Git Guidebook for Developers