Git Survival Kit: Essential Commands for Troubled Times

Introduction

Ah, Git - the ultimate tool for managing chaos in your codebase.

Throughout my programming career, I've found myself in some pretty sticky situations.

From the "Oh shit!" moments to the "How did I even do that?" revelations, I will show you some bad Git situations I've gotten myself into and how I've gotten out of them.

So grab your coffee, turn on your RGB keyboard, and let's take this journey through the highs and lows of Git adventures!

We'll uncover hidden gems that will rescue you from the brink of madness and turn you into a Git rockstar.

When you need to fix your current commit

This happens often: you commit your code and then run a test or lint. You soon realize that you must make a small change and add a file to your commit.

You may have re-read your commit message and thought this didn't make sense.

For all these cases, you need to use git commit --amend.

# To amend the commit message
git commit --amend

# To amend and include additional changes
git add [file]
git commit --amend

# To amend and include additional changes without changing the message
git add [file]
git commit --amend --no-edit

This tool allows you to keep a clean and neat project history.

Enjoy it only in your local copy to avoid complications. It would be best if you never amended commits that have been pushed to a public branch.

When you need to rewrite the history

While we focus on delivering tasks daily, our Git commits reflect chaos. So, at the end of the day, all we need to do is rewrite the Git history tree.

I will show you the git rebase interactive, your new bestie. This command is a Git time machine!

Make sure you're in the branch you want to rebase, and then run the following command:

git rebase -i [commit-hash]

With Git interactive rebase, you can split, drop, squash, reorder, fix up, edit, and reword your commits.

If during the process you have conflicts to resolve, you can use the command:

# To add some files if you need.
git add [file]

git rebase --continue

On the other hand, if you give up on changing the history, you can run:

git rebase --abort

It adapts effectively to different needs, but I recommend not using it in shared branches. It's best suited for personal or feature branches where you have control over the commit history.

When you need to undo a bad commit

You may want to undo some commits and code again or not. In this case, you just need to git reset.

It allows you to undo changes in your Git repository. It can be used to reset the current HEAD, the staging area, and the working tree to a specified state.

Here are some common scenarios where you might use git reset:

If you want to discard all local changes and return to the last commit:

git reset --hard HEAD

Always double-check before using git reset --hard, as it may cause you to lose your work.

Or, if you need to remove commits from history:

git reset --hard HEAD~1

If you need to undo the last commit, but keep the changes staged:

git reset --soft HEAD

It's a powerful Git command, but you should be careful whenever you use it.

When resetting shared branches, please proceed with caution, as it can cause complications for your colleagues.

Another tip is to consider creating a backup branch before running git reset. You can also use git stash to temporarily save changes before resetting them.

When you need to undo a bad commit, but you need to keep the history

Sometimes we mustn't delete the track of our mistakes. The bad commit is in the main branch and everybody has seen it.

In this case, the only thing to do is to keep calm and use git revet.

It will create a new commit that undoes the changes made in a specific commit or a range of commits.

This way, you preserve the original commit history while adding a new commit that reverses the bad changes.

Here's a simple example:

git revert [commit-hash]

If you need to revert a range of commits, you can use:

git revert [start-commit-hash]..[end-commit-hash]

If you need to make some adjustments, you can use this command to stage changes without committing.

git revert -n [commit-hash]

This's a safe Git command to undo changes. It's beneficial for collaborative projects.

However, I recommend always reviewing the reverted changes before pushing them. Another excellent practice is to provide a clear commit message explaining why the revert was needed.

When you don't know where the bug is

Occasionally, you find a bug in the latest codebase version and know an older version that works fine, but you don't know when the bug was inserted.

There is an easy way to identify which commit introduced the issue.

You can use a git bisect. This Git command is a powerful debugging tool. It uses the binary search algorithm to find the commit that introduced the bug.

Here's a basic workflow using Git bisect:

# Start the bisect process
git bisect start

# Mark the current state as bad (has the bug)
git bisect bad [bad-commit-hash]

# Specify a good/broken commit range
git bisect good [good-commit-hash]

# Git will now automatically check out commits and ask if they're good or bad

# Finish the bisect process and restore the original HEAD
git bisect reset

This clever technique speeds up the process of locating problematic commits compared to manual ones.

It's useful when you're trying to track down bugs or regressions introduced over time.

Conclusion

And there you have it - the final chapter in our Git survival guide!

If you find Git confusing, don't worry! You're not alone. Even advanced Git users still encounter tricky situations and don't always know how to navigate them.

Remember, mastering the Git command isn't just about survival — it's about taking control of your coding adventures.

You now have powerful tools to navigate even the most chaotic codebases.

So here's to you, fellow coder! I wish your commits to be smooth, your merges conflict-free, and your branching always logical.

Happy coding, Git rockstars!