Hey devs! 👋 I'm Thabsheer, a 24-year-old developer from Bangalore. After messing up our team's git repo multiple times in my past(yeah, I'm looking at you, force push 😅), I've learned some proper git workflows that saved my life(and work). Let me share what I wish someone had told me when I started.
The Day I Broke Production
So there I was, confidently typing
git push --force
because Stack Overflow said it would fix my issues. Narrator: It did not fix the issues. Instead, I managed to overwrite our main branch and got some angry Teams messages from our senior dev. That's when I realized I needed to actually understand git workflows properly.
The Basics We Already Know
I'm assuming you already know these commands (if not, no worries, we all start somewhere!):
git add .
git commit -m "feat: added something cool"
git push
git pull
The Good Stuff: Workflows That Actually Matter
1. Feature Branch Workflow (The Lifesaver)
This is what helped me stop breaking things. Instead of working directly on main:
# Create a new feature branch
git checkout -b feature/auth-fixes
# Make your changes and commit
git add .
git commit -m "fix: resolved login issues"
# Update your branch with latest main changes
git checkout main
git pull
git checkout feature/auth-fixes
git rebase main
# Push your changes
git push origin feature/auth-fixes
Pro tip: Always rebase before creating a PR. Trust me, your reviewers will thank you.
2. Fixing Mess-Ups (Because We All Make Them)
The "Oops Wrong Branch" Scenario
# Save your changes without committing
git stash
# Move to correct branch
git checkout correct-branch
# Apply your changes here
git stash pop
The "My Commit Message is Embarrassing" Fix
Do this if you want to fix your last commit message.
# Fix the last commit message
git commit --amend -m "fix: proper commit message"
# Fix older commit messages (interactive rebase)
git rebase -i HEAD~3 # Shows last 3 commits
3. The Life-Saving Git Aliases
Add these to your .gitconfig file (took me 6 months to discover these exist 🤦♂️):
[alias]
st = status
co = checkout
br = branch
unstage = reset HEAD --
last = log -1 HEAD
undo = reset --soft HEAD~1
4. When Things Go Really Wrong
Ever had that moment when you realize you just committed sensitive data? Here's what to do:
# Remove the file from git history
git filter-branch --force --index-filter \
"git rm --cached --ignore-unmatch path/to/sensitive-file" \
--prune-empty --tag-name-filter cat -- --all
# Then force push (only time it's okay!)
git push origin --force --all
Things I Learned the Hard Way
- Never force push to main branch (learned this one after that incident I mentioned 😅)
- Always pull before starting new work
- Commit messages matter - your future self will thank you
- Rebase is your friend, merge is also your friend - just know when to use which
Daily Git Workflow I Follow Now
- Morning:
git pull origin main
- Create feature branch for new task
- Regular commits with proper messages
- Rebase with main before PR
- Push changes and create PR
- Address review comments in new commits
- Squash commits before merging
Conclusion
Look, I'm still learning (aren't we all?), but these workflows have saved me from many embarrassing situations. The key is to understand what you're doing rather than blindly copying commands from Stack Overflow (guilty as charged!).
Have you ever broken your team's repo? Drop a comment below - let's share our git horror stories! 😄
Resources That Helped Me
- Git documentation (yes, I finally read it 😅)
- My team's angry Teams messages
- Stack Overflow (but with caution!)
P.S.: If you found this helpful, follow me for more real-life dev stories and tutorials. Thanks for reading!
Top comments (0)