History
If you have done any work with computers or on a computer file, at some point you had to save a file in some form or another. Most people might simply press ctrl+s to save work. But what if you need to keep track of the changes made to certain files or projects? Or better still, what if multiple people ore working on the same project, file, or collection of files and need to keep track of who changed what and when, and what the specific changes were? Version Control Systems (or revision control system) is the answer.
What is a version control system? A version control system or VCS is a system that records changes to your files or projects that can be used individually or share with members of a team (as you might have guessed). Prior to 2005 there were various VCSs all vying for a seat the preverbal table. Each had unique features, but most were closed-sourced and ran on client servers. This might work for a cooperate environment of a couple dozen or so people working on a single repository, but what of hundreds or even thousands working on a massive project? Enter Linus Torvalds.
Out of many… One
In the late 1990s Torvalds and various contributors were developing the Linux Kernel (the part of the operating system that acts as an intermediary between the computer hardware and the applications) and were struggling with revision management. Given the scale of such a project, one can only imagine. In 2002, the team adopted a VCS called BitKeeper, a commercial product, was free under certain conditions. For assorted reasons, the company behind BitKeeper decided to discontinue the free version. There were also grumblings from proponents of open-source software about using a proprietary tool to develop open source. [1]
After searching for another off-the-shelf solution to his problem yielded few options, Torvalds developed the first version of Git in 2005 (it is said) in a matter of days while taking a working holiday. His cited reasons for creating a new VCS were that he needed that could manage the number of contributions in a reasonable amount of time. Since then, Git has grown into the premier version control system with over 85% of developers using the software (according to this recent survey).
Further Reading: History of Git, The Road to Domination in Software Version Control, A Brief history of Version Control Systems
Git Basics
As a young student of programming, I have only ever used Git for revision control and, until recently, only heard the existence of others as whispers in the wind. So, I thought I might go over some of the basic and intermediate commands of Git for those just discovering version control yourself or even for those who want to expand upon the foundations they have already built. *For the remainder of the article, I will be operating under the assumption the reading has basic knowledge of terminal commands. If you need a refresher, check out this MDN article.
If you have done any work with Git/GitHub at all, even on solo projects, you know about the commands listed below:
// adds file to staging area (or index)
git add <filename>
// commits file to local repository
git commit -m “Commit Message”
// pushes commit to remote repository
git push <remote> <branch> (or...)
git push origin main
Let us quickly define some basic concepts:
main: default development branch
origin: default upstream repository
HEAD: pointer to the current branch reference
HEAD^: parent of HEAD
HEAD~4: great-great grandparent of HEAD
Practice makes perfect better
When I first started using version control, I saw all these commands (and a few others) and it was intimidating, but I soon realized the thing that makes Git so great is its simplicity. On the outside looking in, it may seem daunting, but the more you use it, the more people you collaborate with, and the more projects you work on the more practice you will get (no pun intended). Before proceeding further, one thing I would like to mention is that one of the things that better helped me get a grasp on this topic was a visual reference. I strongly recommend Learn Git Branching for this very reason.
Intermediate git
Let us now touch on a few more intermediate aspects of the Git workflow. Let us say you have created an app that automates some menial tasks and a few people started using your app because, like you, they also do not find joy in menial tasks. One of your end users notices a minor bug you may have overlooked. This bug does not break the app but nonetheless needs to be fixed. You do not want to take the app offline to fix it, so what do you do? Well, you might create a branch in your local repository called ‘bug-fix’ git branch bug-fix or git checkout -b bug-fix (the latter will create the new branch move into it with one command). Now you can fix the bug while working on this branch while your end users continue using the app. After you fix the bug you would want to merge bug-fix back into your main branch git merge main or you might want to organize your commits before you merge you might consider rebasing (this is an example of interactive rebasing) git rebase -i main which just gives you a more tidy commit history (*it’s important to note that rebasing should only be done while in local repo). These are just a few commands to do with Git. If you are still interested in learning more about Git, I have taken the liberty of providing additional resources below.
Resources
Think Like (a) Git
Commit Often, Perfect Later, Publish Once: Git Best Practices
Git Best Practices: Workflow Guidelines
Learn Git Branching
Top comments (0)