Interview Q&A / Git & GitHub

1. How big should a commit be?

   One logical change that builds and passes tests on its own. Small, focused commits are easier to review, revert, cherry-pick and bisect than a giant commit mixing several unrelated things.

   BeginnerQuick answer1 min read
2. What is the golden rule of rebasing?

   Never rebase commits that other people have already pulled. Rebase creates new commits with new hashes, so teammates who have the old ones end up with duplicated or conflicting history.

   BeginnerQuick answer1 min read
3. What kinds of files should you put in .gitignore?

   Generated, secret or machine-specific files: dependencies like node_modules, build output, logs, .env files, and editor or OS clutter. Source code and configuration the team needs must stay tracked.

   BeginnerQuick answer1 min read
4. What makes a good Git commit message?

   A short imperative summary line of about 50 characters, a blank line, then an optional body explaining why the change was made. Describe the reason, not just what the diff already shows.

   BeginnerQuick answer1 min read
5. What are the risks of relying on git stash?

   Stashes are local, easy to forget, and git stash drop or clear removes them. They are not on GitHub, so a disk failure loses them. For anything you care about, commit on a temporary branch instead.

   IntermediateQuick answer1 min read
6. When is cherry-pick a bad idea?

   Overusing it creates duplicate commits with different hashes, which later cause confusing conflicts when the branches are merged. Prefer merging or rebasing when you want the whole branch.

   IntermediateQuick answer1 min read