Git and GitHub interview questions

Basics

1. What is the difference between Git and GitHub?

Git records versions locally and supports branches and merges. GitHub hosts repositories and adds collaboration features such as pull requests and checks. A tester can commit an automation fix offline, then share it when a remote becomes reachable.

2. What belongs in a test automation repository?

Commit test code, dependency lock files, non-secret configuration and small deterministic fixtures. Keep generated reports and local browser state out unless there is an explicit reason to version them. A saved login session can contain credentials even when its filename looks harmless.

3. What are the working tree, index and repository?

The working tree contains editable files; the index holds the next proposed snapshot; commits record snapshots in repository history. Staging a locator change does not automatically stage edits made afterwards. Review both staged and unstaged differences before committing.

4. How do you inspect changes before a commit?

Check status, inspect the working-tree diff, then inspect the staged diff. This catches an accidental fixture change alongside a genuine assertion fix. A green test run does not prove that every staged file belongs in the patch.

5. Why do testers use branches?

A branch names a line of development, letting a tester develop a new checkout test without changing the shared main branch immediately. Keep the branch focused so review and failure investigation stay manageable. A long-lived branch still needs regular integration.

6. What makes a useful test-code commit?

It explains one coherent change and why it matters, such as asserting the tax calculation after a checkout fix. Include supporting fixture changes in the same commit if the test needs them. Avoid mixing formatting across the whole suite with a product regression test.

7. Does a clone include every remote branch as a local branch?

A normal clone obtains repository history and remote-tracking references, then checks out an initial local branch. Remote-tracking references are not independent editable local branches. A shallow or single-branch clone deliberately fetches less, which can matter in CI.

8. How do fetch and pull differ?

Fetch updates remote-tracking information without integrating it into the current branch. Pull fetches and then integrates according to its options and configuration, commonly through merge or rebase. Inspect the incoming changes before integrating a risky shared-fixture update.

Integration and review

9. What is merge versus rebase?

Merge combines histories and may create a merge commit; a fast-forward simply advances the branch reference. Rebase replays commits on another base and changes their identities. Rebase a private branch when team policy allows it; do not rewrite shared history casually.

10. What is a merge conflict?

Git cannot automatically reconcile overlapping changes, for example two edits to the same login helper. Resolve the intended combined behavior, stage the resolution and finish the operation. Removing conflict markers alone is not evidence that the test still checks the right thing.

11. How do you resolve a conflict in a test?

Read both changes and the related product behavior before choosing a resolution. If one branch renames a selector and another strengthens the assertion, preserve both intentions. Run the affected tests and inspect the final diff rather than accepting an entire side blindly.

12. When would you abort an integration?

Abort when the intended resolution is unclear or the wrong target branch was selected. Git provides separate abort operations for merge and rebase. Preserve unrelated work before starting integration; an abort is not a substitute for a backup of uncommitted changes.

13. What should a pull request for test code explain?

Describe the regression, the expected behavior and how the test was exercised. Include whether it failed before the product fix and passed afterwards if that was actually checked. A reviewer should be able to distinguish a test improvement from a change that merely weakens assertions.

14. Which checks should protect a test repository?

Use checks that fit the suite: formatting or lint, compile/type checks, fast tests and an appropriate integration smoke suite. Require review for shared helpers and execution configuration. A required check should report reliably even when a workflow skips irrelevant files.

15. What is the difference between revert and reset?

Revert makes a new commit that undoes an earlier change, preserving the published sequence. Reset moves a reference and, depending on mode, can also alter the index or working tree. Prefer a reviewed revert for an already shared bad assertion change.

16. When is cherry-pick useful?

It applies the change introduced by selected commits onto the current branch. A tester might carry a regression test into a maintained release branch. Check dependencies first: a test using a helper introduced later will not become portable just because the cherry-pick succeeds.

Repository hygiene and CI

17. What does .gitignore do?

It controls which untracked paths Git ordinarily ignores. It does not stop tracking files already committed. For a report accidentally tracked earlier, remove it from tracking deliberately and review that change; adding an ignore pattern alone is insufficient.

18. What should happen if a secret is committed?

Revoke or rotate the exposed credential using the owning service, then coordinate cleanup according to repository policy. Deleting it in the latest commit does not remove earlier copies. Keep test credentials in the approved secret store, with only placeholder names in code.

19. What is a tag used for?

A tag names a particular point in history, often a release tested by QA. An annotated tag carries metadata and a message; a lightweight tag is a reference without that tag object. Record the actual tested commit as well as the release label.

20. What is a detached HEAD?

HEAD points directly at a commit rather than a branch. This is useful for reproducing an old failure, but new commits need a branch reference if they should remain easy to find. CI checkouts can be detached without indicating an error.

21. How do hooks help testers?

Local hooks can run fast validation before a commit or push. They are not centrally enforced simply by existing in one developer’s clone, and local checks can be bypassed. Keep authoritative validation in CI and keep slow browser suites out of the normal commit loop.

22. What GitHub events can start a test workflow?

Common events include push, pull_request and workflow_dispatch. Select branch and path filters carefully so a change to shared test configuration still runs the suite. Do not assume that a local successful run proves the workflow’s event permissions or secret handling.

23. Why is pull_request_target risky for test execution?

It runs in the base repository context and may have privileged access. Executing untrusted pull-request code in that context can expose those privileges. Use an unprivileged test workflow for contributed code and separate any trusted metadata automation.

24. Why can CI test a different commit from your laptop?

A pull-request workflow can use a proposed merge reference rather than the feature branch tip. Also check checkout depth, submodules and generated dependencies. Record the checked-out SHA in artifacts when investigating a failure.

Practical scenarios

25. How can you practise a branch-and-merge workflow locally?

This isolated shell example was run in a temporary directory. It uses a deliberately fake local author, changes no global Git settings and needs no GitHub account. The final command printed assert status == 200 and assert total >= 0.

mkdir qa-git-demo
cd qa-git-demo
git init -q -b main
git config user.name "QA Example"
git config user.email "[email protected]"
printf 'assert status == 200\n' > checks.txt
git add checks.txt
git commit -qm "Add status check"
git switch -qc test/total
printf 'assert total >= 0\n' >> checks.txt
git add checks.txt
git commit -qm "Add total check"
git switch -q main
git merge --ff-only test/total
cat checks.txt

26. A test fails after integration. How do you investigate?

Identify the first failing commit, compare test and application changes, and reproduce with the same data and dependencies. A binary search through history can help if the failure is reproducible. Do not classify every integration failure as a conflict: Git only detects textual problems.

27. Two branches both modify a shared page object. What would you do?

Agree the helper’s contract before integration and inspect every call site affected by it. Resolve selectors and return behavior together, then run representative consumers. A helper that now waits for navigation may break tests that intentionally remain on the same page.

28. Should generated reports be committed?

Usually store them as CI artifacts linked to a commit and run instead. Large changing reports create noisy diffs and can contain sensitive URLs or screenshots. Version a small sanitized report fixture only when a test explicitly exercises a report parser.

29. How would you handle a failed push after rebasing?

First check whether someone else updated the remote branch. Agree whether rewriting that branch is allowed; a lease-protected force push reduces accidental overwrites but is still a history rewrite. Do not use an unconditional force push to silence a rejection.

30. How do you describe your Git usage in an interview?

Walk through a real test change: branch, red test or reproduction, implementation, local checks, pull request, review and CI evidence. Explain a conflict or rollback with the decision you made. Do not claim that opening a pull request proves release readiness.

Likely follow-up: What did you inspect before merging? Explain the diff, the test result and the unresolved risks separately.

Practise it

Put a small test for ShopLite in a disposable repository. Review its staged diff and write a pull-request description locally; no hosted account is needed for the branch exercise.