Git it right
Published: 2022-09-25 12:00:23

---
title: Git it right
published: true
date: 2022-09-25 11:47:04 UTC
tags: 
canonical_url: 
---

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.