Sep 2, 2023 3 min read Pull & Rebase

[P&R#5] Git - Revisited

I've been using Git for some time now. If someone were to ask me whether I knew how to use it, I suppose my answer would be yes - I could say, with some degree of confidence, that I knew at least enough to get by with my work.

However, recent events had made me question my understanding of Git. When I was at Thoughtworks University, the recommended workflow was trunk-based development. Despite the fact, when my team began working on the project, I had inadvertantly defaulted to using the Git Flow workflow. It was only after my peers began running into merge conflicts and the trainer felt compelled to step in that I realised how naive my understanding of Git was. I learnt, that to understand alternative Git workflows, I needed to revisit what I knew to be true about Git.

Tips for working with Git

In this article, I'd like to share some of the tips I've learnt about this version control tool.

Tip 1: Use git log --graph --oneline to display merges and commits on different branches, with only the <hash> and <title> of each commit.

The output of git log is as such:

One issue with this display is that the terminal becomes cluttered with information. Some of this information - author, detailed commit history etc. - may be irrelevant if we're simply looking to glance at an overview of the commit history.

An alternative is to use git log --graph --oneline.

This command displays the merges and commits on the different branches. Furthermore, it only shows the <hash> and commit <title> for each commit.

Tip 2: git reflog is a safety net. Use it to go back to commits that may not be referenced by any branches or tags.

Let's say you had performed a git reset --hard to some commit in the past, and you now realized that some important changes in the subsequent commits had been lost. If you perform a git log, you would not be able to see those subsequent commits in your commit history. Don't panic! There's still a way to recover those changes.

When you run git reflog, you shall see the output of the reference log of the HEAD reference. This will also display the information of the old state of branches, allowing you to go back to that state if necessary.

From here, you can simply pick out the commit that had the changes that you lost before, and perform a git reset to that commit.

Tip 3: Consider using a GUI tool like GitHub Desktop to build commits from parts of a file.

It's possible to build commits from parts of a file using git add --patch.

This method would require you to key in multiple commands to stage your changes in hunks. Personally, I can't comment on this much as I've not used it in the past. However, at the superficial level, this method of committing changes from parts of a file appears to be rather tedious.

An alternative method which I'm advocating for is to use a GUI tool. Here's an example of using GitHub Desktop.

To select the changes to add to a commit, one simply needs to check/uncheck the line changes in the file.

Reflections

What team workflow makes sense for my team/project/organization? Should I merge or rebase my changes? Do these have to be mutually exclusive? Are some workflows more inclusive than others? How so?

In search of these answers, I've learnt so much more about Git and team workflows that I didn't think I would before I began. I hope this inspires you to learn more about Git too.