Fairly new to the world of software? You've probably realized that there's a lot to take in, and it's hard to decide where to begin. But one tool that you are guaranteed to use, no matter which domain of software you end up working in, is version control. And the most widely used version control system is perhaps Git.
While this article is meant to focus on the 'how' when it comes to using Git, it's helpful to know the 'why' and 'what' too, so we will be starting with those. But if you prefer to cut to the chase, feel free to click here.
What is version control, and why use it?
Think about collaborative editing tools, say Google docs, and what makes it really helpful. Apart from making collaboration easy (the fact that the project rests in the cloud makes sure changes made by different people in different parts of the world get updated in real-time), they also provide a short version history. That is, who made what changes and when.
When it comes to software, several more needs arise. Codebases can be extremely large, the tiniest of changes can break the entire project, there might be a need to turn back the clock and take a look at a previous version, and changes made by one member of a team may need to be approved by a few others before it gets reflected in the main codebase. Version control takes care of all of this and more. It's a tool that helps software teams manage changes to source code over time.
Some helpful points to note
- Git vs. GitHub
In case you were wondering, they're not the same. There are several differences but the most fundamental one is that GitHub is a service built around Git, with a few additional features. More specifically, it is among the many Git hosting platforms. It uses Git; it's not an alternative to it.
Git's competitors include Mercurial, Subversion, and more, while GitHub's competitors include Atlassian's BitBucket, GitLab (both of which are built around Git too), among others. Since GitHub is quite popular among the student community, this article pays some special attention to it now and then.
So Git is to GitHub what a patty is to a burger. Not my best analogy, but I think it makes my point.
- GUI and CLI
There's a graphic user interface (GUI) that Git offers- you can download their desktop app. But what most developers prefer is working with Git simply on the command line (CLI), so this article is focused on that.
Getting started with Git
Installing Git is, quite obviously, the first step. You can find help here.
So now that you've installed Git, let's go through the most common things you'd have to do, chronologically.
Initializing a git repository
Simply use:-
git init
You've now initialized a local git repo. This is good enough if you happen to be the sole contributor to the project. However, if you want to work with a team, a remote repository becomes necessary. This is often where Git hosting services like GitHub, GitLab, and more come into the picture. In GitHub, for example, click on 'New', and a new remote repo will be initialized, and a URL will be provided. What you must then do is head back to the command line, and add the remote repo URL.
git remote add origin https://github.com/SomeOne/demo.git
But something that you would have to do more often is work on a project that someone else owns. So you wouldn't need to initialize a project or repo at all. What you need is cloning.
Cloning a repo
git clone <repo's https> <repo name-optional>
This sets up a copy of the repo on your local system.
Once you've done this, make sure you move into the repo with a simple cd command
cd <repo name>
Cloning vs. Forking
All I'm going to say is this: cloning is offered by Git while forking is something specific to GitHub. But this question warrants a detailed explanation, and I don't want to overwhelm the beginners, so when you think you're ready, read this.
Creating a new branch and switching to it
A branch in git can be thought of as a particular version of the repo. The 'main' branch is the primary version, but in addition to this, you can create many more using this command:-
git checkout -b <branchname>
This creates a new branch and also switches you to it.
But why do we need branches?
Sure, a small personal project doesn't call for multiple branches - the 'main' branch would be enough - but branches can be immensely helpful for large teams and projects. Think about it- multiple team members making changes to a single branch would be chaotic (it's inevitable to some extent, and results in merge conflicts, a term you'll surely come to hate :) ). And so branches help to compartmentalize and organize work, keeping the main branch relatively clean. Also, this mechanism of maintaining different branches for different team members or different features can give the owner more control.
Switching to an existing branch
You'll obviously need to shift from one branch to another (existing) branch every now and then. Here's how you do that.
git checkout <branchname>
Pulling changes from main/master
When you need to get the latest version of main:-
git pull origin main
'main' vs. 'master': what's the difference?
In short, both signify the same thing: the primary branch or primary source code repository. Many Git repos, as well as Git hosting platforms like GitHub, have been calling this 'master'. However many are increasingly turning to 'main' for an interesting reason.
Adding files and committing changes
Finally, we come to actually making changes and committing code to a repo.
The first step is to add the files where you've made changes/additions. This is also called tracking. To add a specific file:-
git add <file path>
To add all the files in the current directory:-
git add .
To add all files in the entire repo:-
git add --all
Once you've added the necessary files, you can commit.
git commit -m "your message here"
You'll see that the commit is assigned an ID. This can help us move back in time, view more details about a commit, and is pretty useful.
"just some tiny changes" isn't a good commit message
I must confess that I never really paid much attention to how a good commit message should look, up until recently, when a friend turned my attention to it. My advice to you would simply be - try to keep your commit messages uniform and unambiguous. But for the perfectionists reading this, there's a whole lot on commit messages out there.
Pushing your changes to a branch
The final step of sending your changes to the remote repo is pushing it.
git push origin <branchname>
Creating a pull/merge request
So you've created a separate branch for your work, and now you've pushed all necessary changes to it. To get it merged with main, and you will most often need to ask for the admin/owner's approval (when working for a company or working on an open-source project) to do so. This is formally called a 'pull request' or 'merge request'.
Pull request vs. Merge request
Again, both terms essentially denote the same thing. It's just that different Git hosting platforms use different terms. GitHub and BitBucket, for example, use the term pull request, while GitLab and others use merge request.
Some additional commands
You can skip this if you think you've had enough of Git at the moment- you can (and will!) always learn these and more as you go. If you're still here though, here's a brief look at a few more things Git allows you to do: view past history and undo changes.
Enter the following command to view your logs. The commit ID, especially, is useful if you want to ask for further information about a commit, or undo it.
git log
To undo any commit on the current branch, use:-
git revert <commit ID>
Note that it only removes changes made by this particular commit, not all commits from this one onwards.
What if you want to destroy all local changes because you've made a blunder? You could try undoing each commit you've made, but an easier and cleaner way to simply move back to main is:-
git reset --hard origin/main
You're all set
And that brings us to the end of this article. Again, it only explains a fraction of the things you can do with Git. It's my belief that you can learn more along the way, once you start working on a project. So au revoir, and hope you found this useful!