javascript #git #github #webdev
Most developers know git add, git commit, and git push. That is not what teams evaluate in senior candidates.
What actually signals seniority is workflow. Branching strategy, commit structure, pull request discipline, and automation. Here are six Git patterns that real JavaScript teams expect.
Short Lived Feature Branches Instead of Long Running Branches
Many developers keep feature branches alive for weeks. That guarantees painful merges.
Senior teams keep branches short lived and merge fast.
Before
# Branch lives for weeks
git checkout -b feature/complete-search-system
# dozens of commits over 2 weeks
git commit -m "search work"
git commit -m "more search changes"
git commit -m "fix search"
After
# create small feature branch
git checkout main
git pull origin main
git checkout -b feature/search-filter
git commit -m "feat(search): add filter component"
git push origin feature/search-filter
Branches should live hours or a couple of days. If a feature takes longer, split it into smaller PRs. This keeps merge conflicts close to zero and lets teams deploy continuously.
Rebasing Your Branch Before Opening a Pull Request
Developers often open pull requests with messy merge commits from main. That makes reviews painful.
Senior developers rebase their branch before review so the diff only shows their changes.
Before
git pull origin main
# creates merge commit
Merge branch 'main' into feature/search
After
git fetch origin
git rebase origin/main
# resolve conflicts if needed
git add .
git rebase --continue
git push --force-with-lease
Rebasing keeps history linear and makes code review dramatically easier. Reviewers see only your work instead of merge noise.
Commit Messages That Explain the Change
Commit messages are not a formality. They are long term documentation.
Senior projects use Conventional Commits.
Before
git commit -m "fix bug"
git commit -m "update"
git commit -m "changes"
After
git commit -m "feat(search): add debounced input with 300ms delay"
git commit -m "fix(auth): prevent refresh loop when session expires"
git commit -m "perf(dashboard): lazy load charts to reduce bundle by 45KB"
Good commit messages tell the next developer exactly what changed and why. They also power automation such as changelogs and semantic versioning.
Clear commits also make collaboration easier when your team is reviewing code, which is exactly what experienced engineers focus on when improving review quality and team velocity as discussed in the guide on giving and receiving effective code review feedback.
Interactive Rebase to Clean Up Commit History
Development commits are messy. That is normal.
Senior developers clean them before opening a pull request.
Before
git log
abc123 WIP
def456 fix typo
ghi789 WIP search logic
jkl111 forgot to import hook
mno222 working now
After
git rebase -i HEAD~5
Interactive rebase editor:
pick abc123 feat(search): add search component
squash def456 fix styling
squash ghi789 implement filtering logic
squash jkl111 import missing hook
pick mno222 test(search): add unit tests
Resulting history:
feat(search): add search component with filtering
test(search): add unit tests
Instead of chaotic commits, reviewers see a logical development story.
Automating Quality Checks with Git Hooks
Relying on CI to catch lint errors after pushing wastes time. Senior teams stop bad commits locally.
Using Husky and lint staged makes this automatic.
Before
git commit -m "feat(search): add filter"
git push
# CI fails because eslint errors exist
After
Install tools.
npm install --save-dev husky lint-staged
npx husky init
Add configuration.
{
"lint-staged": {
"*.{ts,tsx}": [
"eslint --fix",
"prettier --write"
]
}
}
Hook configuration.
# .husky/pre-commit
npx lint-staged
Now broken code cannot even enter Git history. The commit fails instantly.
A Minimal CI Pipeline That Runs on Every Pull Request
Manual testing does not scale. Every serious project runs automated checks.
Before
Developers push code and hope everything works.
After
name: CI
on:
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [20, 22]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: npm
- run: npm ci
- run: npm run lint
- run: npm test
- run: npm run build
Every pull request now runs linting, tests, and build verification automatically.
No reviewer has to ask whether the code compiles or if tests pass.
Squash Merging Pull Requests to Keep Main Clean
Some teams merge every commit from a branch. That pollutes main.
Senior teams squash merge.
Before
commit 1 WIP
commit 2 fix typo
commit 3 debugging
commit 4 still debugging
commit 5 final fix
After
GitHub squash merge produces a single clean commit.
feat(search): add debounced search filter (#128)
The pull request keeps the detailed history. The main branch stays readable.
That makes debugging production issues far easier months later.
Git is not just version control. It is the communication layer of a software team.
Senior developers treat commits as documentation, pull requests as collaboration, and CI as a safety net. When someone reviews your GitHub profile, they are not only evaluating code quality. They are evaluating how you work with others.
Start applying these patterns to your repositories today. Your Git history will immediately look like the work of someone who has shipped software in a real team.
Top comments (0)