Git it right

Being in a computer programming school, there are a lot of tools we use to aid with turning code into software as writing code is just one aspect of software development. One such tool is Git.

Git for whatever reason seems to be surrounded by a lot of fear, a typical pattern Ive noticed among students is that we learn it by doing the usual every day *add , commit* and push, but Git has so much more to offer! Especially when it comes to collaboration, the way Git works seems magical to most beginners (myself included). In this article, however, I wont be unpacking Git at the low level, this isnt a comprehensive guide, as I learn more about Git and its wonders I may write very detailed, in-depth articles about how it works, for now, this article shall serve as a quick guide so to speak.

In this article, Ill briefly go through a few handy Git features/commands that you might want to start using as often as you can if you arent already.

A better way to commit

If youre reading this Im assuming youre familiar with staging your changes and making a commit (hopefully with a meaningful commit message). A wise developer on Youtube once told me:

git commit often and youll thank me later

a typical way of doing this is:

git add .
git commit -m "Introduced some changes for demo purposes"

Thats all well and good, but theres a quicker way of doing this. You can achieve both by running:

git commit -am "Introduced new blah blah blah"

This will stage all changes made (modifications) to files, and make a commit with the given commit message, pretty handy right! It is important to note, however, that this will only work if the changes were made to files that Git is aware of (i.e modifications). Say for example you create a new file and try running the above handy command, it will most likely not work, also take note that it will stage all the changes made so if youre trying to only stage a specific file for the commit you should not run this command.

Couple changes and fix commit message typos

Zoning when writing code is exciting and it's what we often strive for and crave as developers, it's a state of deep focus and implementation of ideas with almost no awareness of one's surroundings and time itself. Most of the commits made in the zone arent very well thought out as youre rushing to put whats in your head through the keyboard, a good example of this is writing commit messages that arent very descriptive:

git add .
git commit -m "updates"

I find this to make not only your job difficult when refactoring but most importantly the job of other developers in your team, especially when reviewing the code for merging. I think it's good practice to describe the changes introduced and why they were introduced, that way you dont have to dig through the commit to figure out exactly what changed and why, and how it adds value to the overall codebase:

git add .
git commit -m "Fixed issue **x** with feature **y...** feature now does **x,y,z** instead of **a,b,c**"

That's a little bit better, it's lengthy but useful, whoever reads commits that look like this rarely has to dig in and see the changes, even if they do that, they have a pretty good idea of what the changes were just by reading the commit message.

But what if youre not staging everything? what if you make a lot of changes to a lot of files but not all of those files or changes are directly related?

Well in that case youd ideally have to make multiple commits by only staging the related changes you made:

git add file1 file2 file3
git commit -m "Server now communicating through file2 because **x,y,z**"

Cool! but let's say you make this commit, but later realize that the changes you made in file7 go together with changes made in file1, file2, and file3 and you forgot to stage file7 together with the others, what then?

You can easily modify your previous commit:

git add file7
git commit --amend --no-edit

This will stage file7 and couple it with the other files on your previous commit, the -no-edit flag tells Git that you dont want to change the commit message, running without that flag allows you to change the commit message as well. This feature is also handy if youve made a typo or your commit message isnt descriptive enough:

git commit --amend "a better commit message"

Saving changes for later

Have you ever made changes or created a feature that only kinda works or just breaks things when combined with the rest of the codebase? Usually, that happens when you start working on something but dont have an idea of how to complete the whole thing or you realize that it needs some other changes that are being made by your teammate.

You dont really have to wait for those changes to exist to start working on your end of the feature, you can make the changes right away but dont commit them at the time of making:

git stash

Stashing is, well, exactly what it sounds like! It takes all of your unstaged changes and stashes them **somewhere, allowing you to continue working as if those changes were never made, right up until you need them, in that case, youd have to:

git stash pop

Then Bam! the changes you made 2 days ago and stashed appear seemingly out of nowhere.

It is worth noting that if you stash a lot it might be difficult to spot which changes happened when, and which ones you need from your stash. A good way of doing it is:

git stash save my secret

This will give you the ability to reference your changes later when you need to pop them from the stash (I suggest giving your stashes definitive names).

Needless to say, you can stash as much stuff as you need by saving with different names, then when you finally need the changes, run:

git stash list
git stash apply 1

The stash list will show you everything in your stash listed with the names you gave when saving, then you can pop something from the list using apply with the corresponding list index starting from zero.

Time travel

What happens if you forget to stash and you commit and push your changes and go to bed? Well, your team will probably eat you alive on standup the next morning but dont worry too much, Git has some nifty time travel features.

One such feature is revert :

git revert 33r5f6

This allows you to go back to a specific point in time in your repository (preferably before you introduced chaos).

To do this, youll have to see the commit log by running:

git log

Youll see a bunch of commits with details of who made them and at what time, these commits can be referenced by their IDs (the long random character gibberish on each commit). From there, you can copy the id referencing the commit you want to time travel back to and paste it on the git revert command. This feature is kinda like undo in Git, but it doesnt remove the bad commit from the commit history, it simply removes the commit from staging and allows you to make changes (that will hopefully be a fix).

Another time travel handy feature is reset :

git reset 33r5f6

It works very similarly to revert but if you give it the flag -hard it will not only un-stage commits, it will skip giving you a chance to rectify your mistakes and go back to before you even made the changes!

git reset --hard 33rf6

It is considered to be pretty wild and personally, I have caused a good 2-hour panic with this command, but Im glad to have done it because now I know that even though it's considered a dangerous command to run, Git can allow you to go back to before you went back in time! Crazy right!?

But that's an article for another time.

Thank you so much for giving this article a read, I hope you found it helpful in some way, and if so, please let me know and share it with others you think might find it insightful.