Mastering Git in Daily Workflow
Have you ever written a commit message like "final fixes" or "now it works"? If so, you know how quickly a project's git history can turn into chaos. In software development, writing clean commits and knowing how to troubleshoot Git isn't a cosmetic preference, it's a fundamental engineering practice. In this post, I’ve put together the essential commands and patterns to keep your repository history readable, maintainable, and professional.
1. Commit Standardization (Conventional Commits)
Standardized commits allow anyone on the team (including your future self) to understand what changed without opening a massive Pull Request.
The basic structure follows this format:
<type>(optional scope): <short description in present/imperative tense>
Common Commit Types:
feat: A new feature for the application.fix: A bug fix.docs: Documentation-only changes (README.md, inline docs, etc.).refactor: Code refactoring without changing functionality or fixing bugs.test: Adding or updating unit/integration tests.chore: Maintenance tasks, dependency updates, or CI/CD script tweaks.
Practical Example:
git commit -m "fixed login"
git commit -m "fix(auth): resolve NullPointerException when validating expired JWT"
2. Life-Saving Terminal Commands
Forgot a file or made a typo in your last commit?
If you haven't pushed to the remote branch yet, you can modify the last commit directly:
# Stage the forgotten file
git add .
# Add it to the last commit without changing the message
git commit --amend --no-edit
# Or update the last commit message
git commit --amend -m "fix(api): fix user search endpoint"
Need to save changes temporarily? (git stash)
If you are in the middle of a task and need to switch branches immediately to address a production issue:
# Save working changes with a descriptive label
git stash save "WIP: user registration screen implementation"
# View your saved stashes
git stash list
# Re-apply the last stash and clear it from the stack
git stash pop
Undoing local changes without losing control
Discard local changes in a file (before staging):
git checkout -- Application.javaUnstage a file (after
git add):git restore --staged Application.java
3. Rebase vs. Merge: Keep Your History Clean
While git merge creates a separate "merge commit" every time you integrate updates from the target branch, git rebase reapplies your feature branch commits on top of the target branch, producing a linear history.
# Updating your feature branch with main via rebase
git checkout feature/your-task
git fetch origin
git rebase origin/main
The Golden Rule: Never rebase public or shared branches (like
mainordevelop). Only rebase your personal local branches before opening a Pull Request.
Conclusion
Maintaining an organized Git workflow with clear commit messages and atomic commits (small, single-responsibility changes) simplifies code audits, enables automated release logs, and demonstrates architectural maturity in your software projects.
