Stupid tricks to solve Git problems

Here are some trivial, unconventional, but, hopefully, useful tricks for Git.

Create aliases for typos

It’s not uncommon to make mistakes when typing command lines, but why not take it into account by creating specific aliases.

For example, I’ve noticed I usually invert or miss letters when I’m tired.

To fix that, I like to open the ~/.gitconfig file that contain the generic configurations for Git on my machine and look for the [alias] section to add the following:

[alias]
  chekcout = checkout
  checout = checkout
  chkeout = checkout
  chkcout = checkout
  fethc = fetch
  fecht = fetch
  puhs = push

Problem solved ^^. Of course, it’s important to analyze your own mistakes to add the appropriate aliases that will ease your life.

Split the repo

There are dedicated commands like git repack to combine existing packs (~ git objects) or git gc --aggressive to manually trigger the garbage collection, or even git reflog to browse Git references.

Other strategies may force you to rewrite the “holy” Git History. While it might work, it’s a significant risk.

Don’t do it in “YOLO mode.”

Instead, you may split the repository into smaller repositories to run magic tricks (like git filter-branch commands).

Don’t trash the original repository too quickly. Just keep it for a while, and if everything works as expected, you might think about deleting it.

Squash your merges

It’s usually fine to squash commits when merging modifications into the main branch of the project:

git checkout main
git merge --squash {your_branch}
git commit

All commits from {your_branch} will be merged into a new single commit.

This allows for cleaner history in the default branch.

Don’t overuse this technique, though. In my experience, it’s fine on the main branch, but if you want to merge your code into “intermediary” branches like “develop,” use classic merges instead.

Prevent nasty rebasing errors

Warning: remember the title of this post: “stupid tricks.”

One of the best ways to prevent nasty rebasing errors is to avoid using git rebase:

¯\_(ツ)_/¯ 

It might seem lame, but I don’t care. Rebasing is perfectly fine as a global pull strategy, but if you start rebasing branches in other branches without knowing what you’re doing, you will get lots of issues.

I’ve seen similar situations ending up in hard restores and other emergencies so many times.

Prevent stupid checkout errors

Okay, I’m not gonna tell you to avoid the checkout command this time!

It’s almost impossible, as Git uses it for anything and everything.

However, a classic mistake is to start your branch from an old commit-sha (the main branch but not updated with the latest commits), which can ultimately lead to nasty regressions when merging your code.

Indeed, Git is a decentralized technology. It’s easy to forget to pull the latest changes before using the following shortcut to create a new branch:

git checkout -b {my_new_branch}

So, the “magic” tricks here consists of keeping vigilance.

In other words, always pull before starting new branches.

It gets more complicated when the project uses “intermediary” branches like “develop”.

Don’t worry, though, as there are software, configurations, and platforms (e.g., GitHub, GitLab, Bitbucket) that can help you configure solid workflows to automate some checks.

Working with pull requests can help you spot weird cases.

Wrap up

I hope you enjoyed my stupid Git tricks.