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.