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