Question 1

How do you resolve a merge conflict? Walk through it.

Accepted Answer

(1) git status shows the conflicted files; (2) in each file I find the markers and understand the intent of both changes — talking to the author if needed; (3) write the correct result and remove markers; (4) git add + commit; (5) run the tests — a resolution can be wrong, compiling isn't enough. Key message: conflicts are a communication matter, not just technical.

Question 2

What's the difference between merge and rebase? (at a basic level)

Accepted Answer

Merge creates a merge commit joining two lines — history stays branched, nothing is rewritten. Rebase "replays" your commits on top of main — history becomes linear, but commits are recreated. Golden rule: never rebase a shared (pushed, used-by-others) branch. Follow the team convention — most use "rebase feature branches, merge/squash into main".

Question 3

Should automated tests live in a separate repo or with the product code?

Accepted Answer

Know both sides. Together (same repo): tests change in the same PR as code, no version-sync problem, devs see and run tests — the preferred approach for unit/component/e2e. Separate repo: makes sense when the QA team releases independently or tests span multiple products (cross-system). Show you'd ask about context — team structure and deployment cycles drive the choice.

Branches and merging

📚 Sources and documentation