git is one of the most important tools for a developer nowadays and this
applies pretty much regardless of what language you work on.
However, it seems that nobody explains what git is to new developers at any point. I’ve had to mentor many devs of different levels of experience, and I’ve consistently noticed that nobody had taught them what git is or how to use it.
Many courses seem to cover git, but only cover very advanced topics: branching, tags, git-flow, and alike. This is pretty much like teaching a medicine student how to do heart surgery on their first week – sure, it’s important, but it’s definitely not the first topic you want to cover (nor will they be able to actually assimilate this skill during their first week anyway).
What is it for? ¶
Have you ever used Google Docs (or Word, or whatever). If you go to the “File” menu, and pick “Version history” you can see a list of all changes made through time. There’s a list of dates and times, and as you click each one, you can see the changes made.
Git is a tool for saving this sort of history for your code.
Git allows you to grab all your code at a given time, and freeze a copy of the whole thing. You can, in future, roll back to this version, see how you code has changed, and leave messages for yourself “this version doesn’t crash on startup!”. Each of these versions is called a “commit”.
So what’s a commit? ¶
As I said before, each version is a “commit”. Internally, git doesn’t copy everything, rather, a commit is just a list of differences of what’s changed between this version and the last.
Say you have this code in your “version 1” (and you’ve committed this):
def do_stuff(obj): obj.do_something() print('done!') return True
And you have this code in “version 2”:
def do_stuff(obj): obj.do_something() return True
When you commit “version 2”, git merely records “this version deleted line #3
somefile.py). When you ask it to show this commit, it’ll render it
something like this:
@@ -1,4 +1,3 @@ def do_stuff(obj): obj.do_something() - print('done!') return True
Notice that tiny
- at the beginning? That means “this line was deleted”.
(side note: git doesn’t literally store this, it’s more efficient, but you
don’t need to know this).
A bit more formally, a commit is a set of changes applied to a codebase, with an attached human-friendly message.
How do I create a new commit ¶
So, let’s assume you’re working on some files with code (maybe an assignment?). The first thing you want to do it initialise a git repository.
This basically means “tell git to set up it’s stuff here”. A repository is basically a directory, but you can push it (“copy it to a remote machine”), or pull it (“copy commits from a remote machine”).
Initialising is done running
git init with the official/cli client, but your
IDE may have some other way of doing it.
Once you’re working on a repository, you need to follow a few steps to create a commit:
git addto add files you want to save to your commit. Technically, you add the changes in the files, not the files themselves, and you can (should) add changes individually to make sure your changes are what you think they are (you can use
git add -pto do this).
- Keep in mind that you’re adding changes – so if you removed a file, you can
git add myfile.pyto remove it. To help wrap your mind around it, consider that you’re “adding changes”. In this case, “the changes” is deleting a file.
git committo create the commit. Git will prompt you for a messages, and that brings me to the next topic…
The importance of commit messages ¶
If you work on a same codebase for days/weeks/months, you’ll many times want to look back. “Oh, how was this code written when it worked for any input?”, or “Why did I write this line, what was I thinking?”.
So the key to writing commit messages, is to quickly describe what you did, and why you did anything that might not seem obvious. When you work with a team, they’ll appreciate the attention to detail. When you work alone, your future self will thank you even more.
Sometimes we don’t leave comments like “added this check because otherwise X and Y happen” because they sound like too many or too much. A commit messages is the perfect place for this. It’ll never be in the way, but will forever be findable.
As you use git and continue working on more complicated codebases, you should learn to appreciate the ability to look back and figure out how and why you did things.
Final words on commits ¶
Think of commits as checkpoints. Did you break everything and lose? No problem,
yo can go back to the last checkpoint. Or use
git diff to see exactly what
you’ve change since you did it.
You can also use
git stash. It remove all the changes you’ve made, so you can
test your last commit and see if something worked (or not). This is great if
you want to figure out if you’ve broken something, or if it was always broken.
git stash pop will restore everything to the way it was before.
Want to know more? ¶
Thee intention with this article is to teach what git is for, and why you should care. If I’ve achieve my goal, you’ll probably want to learn more and incorporate it into your workflow – learning it pays off pretty fast, and you’ll save so much time so fast that it’s a great investment early in one’s career as a developer.
A great starting guide is the official git book. It’s pretty short (in under 30 pages you’ll have everything you need to know and lots more!), and very hands on: