Part 10 of 11 · 3 min read
Working like a professional
The commands and habits teams use every day on top of the basics, how to write a good pull request, and how this topic comes up in interviews.
The basics are enough to work alone. On a team you will also use the following, most days.
What you will use daily at work
| Command | When you reach for it |
|---|---|
git fetch |
Download what others pushed without touching your files. git log main..origin/main then shows what is new. |
git pull --rebase |
Update your branch without adding a merge commit. Many teams set git config pull.rebase true once. |
git stash push -m "wip" |
Park unfinished edits so that you can switch branches. git stash list and git stash pop bring them back. |
git switch - |
Jump back to the branch you were on before. |
git diff --staged |
Read exactly what the next commit will contain. |
git commit --amend |
Fix the last message, or add a forgotten file. Only before you have pushed it. |
git cherry-pick <commit> |
Copy one commit onto another branch, for example a hotfix onto a release branch. |
git push --force-with-lease |
The safe way to push after rebasing your own branch. It refuses if someone else pushed in the meantime. |
git worktree add ../hotfix -b hotfix main |
A second folder with its own new branch, so that you do not have to stash. (Git refuses to check out main twice, so a new branch is needed.) |
git log -S"retry" -p |
Find the commit that added or removed a piece of text. |
gh pr create, gh pr checkout 123 |
Open a pull request, or check out someone else's, from the terminal with the GitHub command-line tool. |
Team habits. main is protected: no direct pushes, required checks, and at least one review. A CODEOWNERS file asks the right people to review the files they own. Commit messages often follow Conventional Commits (fix:, feat:). A pre-commit hook runs the formatter and linter before every commit.
Rarely needed. git gc, hand-editing files inside .git/, and git filter-branch (use git filter-repo instead).
A good pull request
- Small. Aim for a change a reviewer can understand in 15 minutes.
- Titled for the outcome. "Retry HTTP 429 with backoff" says more than "Update client".
- Described. Why now, what changed, how you tested it, and anything risky.
- Green. The automatic checks pass before a human looks at it (Level 0, module 7 builds these).
A short template for .github/pull_request_template.md:
## What and why
## How I tested it
## Risks / things to look at closely
- [ ] Tests added or updated
- [ ] No secrets or personal data in the diff
Interview angle
Answer in your head first, then open it.
What is the difference between merge and rebase?
Merge preserves history with a merge commit. Rebase rewrites your commits onto a new base for a linear history, so do not rebase shared branches.
You committed an API key. What now?
Revoke and rotate it first, then remove it and clean the history. Deleting the line alone is not enough.
revert versus reset?
Revert adds a new commit that undoes an old one, which is safe for shared history. Reset moves the branch pointer and can discard work.
What is the staging area for?
It lets you choose exactly which changes go into a commit, so each commit holds one purpose.
How do you recover a commit after git reset --hard?
Look it up in git reflog and reset to it.