How I Use Git in My Day-to-Day

Everyone in the coding world knows what Git is, but we rarely talk about using it daily. Most people treat Git like a "save button," but it’s actually a communication tool. Your Git history is a self-reflection of your mind as you problem-solve and a gateway for your teammates to understand your thinking. From the first cup of coffee to the final PR, these are the routines and commands I use to save my neck if I make a critical mistake during a coding binge.

The Morning: Pruning and Pulse Checks

I start my day by clearing the stale branches of yesterday.

• ▸Pruning: I'll run git remote prune origin to clear out branches that have been merged and deleted on from GitHub (or your choice of version control). If your local list has 50 branches, you’re going to lose focus and maybe the branch you want.

• ▸The Pulse Check: I always run git status. It’s not about being forgetful; it’s about context switching. If I see "changes in flight" from the night before, I’ll either commit them immediately or stash them.

• ▸The Fetch: A quick git fetch --all ensures that if a teammate asks for a code review, I already have their latest work ready to go.

---

Branching: Setting the Contract

Unless I’m building on top of a teammate’s unmerged feature, I always branch off dev. I treat the branch name like a flyer to the ticket—I want to know exactly what the work is for at a glance.

• ▸

  My Preferred Schema: git-username/AT-123-login-validation This tells the team:

  • ▸who (git-username)
  • ▸why (ticket number)
  • ▸what (concise name) is happening without them ever opening Jira.

---

Commits: The Power of "Atomic"

This is where teams either thrive or struggle. I like Atomic Commits. A commit should be the smallest unit of work that still builds. If I’m fixing a UI bug and notice a typo in a logic file, I make two separate commits. Why? Because if the UI fix breaks the build, I want to be able to revert that specific change without losing the typo fix.

• ▸

  The Message: Avoid the "WIP" or "Update". Your message should explain the intent.

  • ▸Bad Message: Fixed stuff
  • ▸Good Message: Refactor LoginFragment to use shared validation logic

---

The "Oh No" Section: Rewriting History

Everyone makes mistakes. The difference is knowing how to fix them before anyone sees.

• ▸

  The Quick Fix: If I committed a typo or I pushed code that I shouldn’t have, I don't make a new commit. I use git commit --amend --no-edit to shove the fix into the previous commit.

• ▸

  The Cleanup: If my branch looks like a graveyard of “WIP” and "typo fix," I use Interactive Rebase. This lets me surgically go back into my commits and polish up commits as I see fit.

• ▸The Safety Net: If I accidentally delete a branch or do a hard reset to the wrong hash, I use git reflog. It’s a secret ledger of every move your HEAD has made. It’s the secret "undo" button no one tells you about.

---

The PR: The Final Hand-off

The Pull Request is your final product. I make mine Reviewer-First:

• ▸The Title: [AT-123] Add Biometrics Toggle to Settings
• ▸The Context: Link the ticket and provide a 3-sentence "why."
• ▸Visual Proof: For mobile or web, include a screenshot or screen recording when possible.
• ▸The Self-Review: I am always my first reviewer. I check for failing tests, typos, or stray logs before tagging a teammate.

---

Conclusion

That’s my day-to-day. It’s a mix of discipline and knowing when to use commands to keep things tidy. By spending an extra 10% of your time on Git hygiene, you save your team 50% of the headache during code reviews.

---

TL;DR

• ▸Digital Housekeeping: Prune merged branches daily.
• ▸Atomic Commits: Keep logic simple and concise per commit.
• ▸Naming Schema: username/{ticket-number}-{brief-description}.
• ▸Commit Refining: Use git commit --amend and git rebase -i.
• ▸The "Undo" Button: git reflog is your best friend.
• ▸Reviewer-First PRs: Include screenshots/videos for UI changes.

---