Navigating the vast landscape of Git commands can sometimes feel like venturing into a bustling marketplace where everyone seems to know the most popular stalls: pull
, commit
, push
, rebase
, stash
, and checkout
. These commands are the cornerstone of everyday version control tasks, often forming the basis of a developer's Git journey. But amidst this bustling crowd of common commands, have you ever paused to wonder, "What else can Git do?" Have you ever caught yourself in the quiet moments, pondering the existence of lesser-known Git commands that could potentially transform your workflow?
Join us as we navigate through these unexplored corners of Git, revealing commands that may have eluded your attention but can significantly enhance your mastery of version control.
git switch
: a fresh approach to branch managementWhile git checkout
remains a versatile command for various purposes, it also comes with the potential to inadvertently discard changes or create confusion. Enter git switch
, introduced in Git version 2.23 as a dedicated tool for branch management.
Unlike the all-encompassing nature of git checkout
, git switch
focuses solely on simplifying branch-related operations. Its purpose is straightforward: to provide a clearer and safer way to switch branches, reducing the risk of errors and data loss.
git switch
?If you've ever felt the unease of accidentally losing your work while using git checkout
, git switch
offers a more reassuring alternative. This command offers explicit error messages and is designed to minimize the chances of unintentional changes.
Here are some examples of how you can use git switch
effectively:
git switch -c my-new-branch
, using the current commit as its base.main
branch using git switch main
git switch -
git bisect
: tracking bugs downIn software development, locating a bug can be akin to finding a needle in a haystack. But fear not – the git bisect
command is here to help. It's like a guided missile for tracking down the elusive bug.
Here's how it works:
Identify Known States: First, you need to identify a "good" commit (when the code worked) and a "bad" commit (when the bug surfaced).
Start Bisecting: Begin the process with:
git bisect start
Mark Known Commits: Tag the known "good" and "bad" commits:
git bisect good <good-commit>
git bisect bad <bad-commit>
Navigate Commits: Git will automatically guide you to a commit between the two states. You test your code there. To see which commit you're at:
git log -n 1 --oneline
Continue the Hunt: Based on your test, you mark the commit as "good" or "bad":
git bisect good # or git bisect bad
Repeat Until Found: Git will automatically move to the next commit within the narrowed range. You repeat the process until you've pinpointed the bug's source.
End the Hunt: When you've found the problematic commit:
git bisect reset
This concludes the process and takes you back to the clean state and the previous HEAD
before you started the bisect
process.
git notes
: Enhancing Commit ContextGit notes provide a versatile way to attach supplementary information to a commit without altering the commit itself.
Imagine you and your team found yourselves in a Git repository with less-than-ideal commit messages. Often, commits lack the necessary clarity to explain their purpose effectively. This feature allows you to enrich commits with essential context without the need to modify or rewrite commit SHA1.
Stored locally within .git/refs/notes
, Git notes remain separate from the main commit data. By default, they are not pushed to the remote repository. However, this can be changed by pushing them in a manner similar to git tag
:
git push origin refs/notes/commits
To retrieve existing notes from a remote repository:
git fetch origin refs/notes/commits:refs/notes/commits
You can easily add notes to existing commits using the git notes add
command:
git notes add -m "Introduce irreversible migrations at this point" <commit-sha1>
m
is optional. If omitted, your default text editor will open, allowing for a more detailed explanation.<commit-sha1>
, the HEAD
commit will be assumed.Removing notes is straightforward:
git notes remove <commit-SHA1>
To list all existing notes:
git notes list
For a more in-depth insight into specific notes:
git notes show <commit-SHA1>
Unfortunately, GitHub no longer displays git notes
in its UI. This adjustment, in my opinion, reflects the limited usage of these commands. By making this change, GitHub appears to be fostering a culture of encouraging developers to consistently produce improved commits without the temptation to revisit or dwell on the details of previous commits.
git diff
+ git apply
Consider a common scenario: a pair programming session happens to address a specific problem. During this interaction, the most experienced developer takes the lead, demonstrating a viable solution by implementing essential changes.
As the collaborative session unfolds, these changes become crucial building blocks for the solution. To facilitate the smooth continuation of this collaborative effort, Git provides two essential commands: git diff
and git apply
.
Once the demonstration is complete, and the necessary changes are in place, you can encapsulate these modifications within a concise patch file:
git diff > ~/Downloads/pair_programming_session.patch
The other developer can then seamlessly incorporate these modifications into their local codebase using:
git apply pair_programming_session.patch
In this manner, Git offers an efficient mechanism for transferring insights and progress gained from collaborative coding sessions, ensuring that developmental strides are effectively communicated.
I understand that consistently learning new tools and programming languages can be challenging. However, it's important to recognize that git
serves as a tool for delivering your work. Thus, make it a practice to regularly peruse the official documentation and keep your git
CLI updated to fully leverage its capabilities and embrace new features.
Have you ever considered integrating these commands into your workflow? I hope you've found something useful or at least identified a command to avoid using.
Also published here.