π Answer: Reference to original repository (especially in forks).
π Use Case: Keep your fork updated with original repo.
Mock Interview: GitHub (Real Company Style)
πΉ Round 1: Basics + Practical Understanding
β Q1: Explain your GitHub workflow in your current project.
π Strong Answer:
βWe follow a feature branch workflow. Each task starts with a new branch from main. After development, we push code and raise a pull request. CI runs automatically using GitHub Actions. After code review and approvals, we merge into main. Direct commits to main are restricted.β
π What interviewer checks:
Real experience
Collaboration understanding
CI/CD awareness
β Q2: What happens when you run git push?
π Strong Answer:
βIt uploads local commits from my machine (using Git) to the remote repository on GitHub, making them available to the team.β
π Follow-up trap: π βWhat if push is rejected?β
βοΈ Answer:
βIt usually means my branch is behind. I pull the latest changes, resolve conflicts if any, and push again.β
πΉ Round 2: Scenario-Based Questions
β Q3: You and another developer changed the same file. Your PR shows conflict. What do you do?
π Strong Answer:
βI pull the latest changes from main, resolve conflicts locally, test the code, commit the fix, and push again to update the PR.β
π Bonus point: Mention testing after conflict resolution.
β Q4: You accidentally pushed sensitive data (API key) to GitHub. What will you do?
π Strong Answer:
βFirst, I revoke the key immediately. Then I remove it from the repository, rewrite history if needed, and ensure it’s added to .gitignore. Going forward, I store secrets using GitHub Secrets.β
π What interviewer checks:
Security awareness
Real-world handling
β Q5: Your teammateβs PR broke the build. What should happen?
π Strong Answer:
βThe CI pipeline should fail automatically. The PR should not be merged until the issue is fixed. We enforce required checks before merging.β
π Extra credit: Mention branch protection rules.
πΉ Round 3: CI/CD + Automation (Very Important)
β Q6: How do you integrate automation tests with GitHub?
π Strong Answer:
βWe use GitHub Actions to trigger Playwright tests on every PR. The workflow installs dependencies, runs tests, and publishes reports.β
π Example flow:
PR created
Tests run automatically
Pass β merge allowed
Fail β fix required
β Q7: How do you ensure code quality before merging?
π Strong Answer:
βWe use a combination of:
Pull request reviews
Automated tests
Linting checks
CI validation
Only after all checks pass, the PR is merged.β
πΉ Round 4: Advanced Problem Solving
β Q8: Your main branch is broken after a merge. What will you do?
π Strong Answer:
βI would quickly identify the faulty commit and revert it using git revert. Then fix the issue in a new branch and raise another PR.β
π Important: Avoid rewriting history in shared branches.
β Q9: How do you handle multiple environments (dev, staging, prod)?
π Strong Answer:
βWe use different branches or deployment workflows. For example:
develop β dev environment
main β production CI/CD pipelines deploy automatically based on branch.β
β Q10: How do you manage large teams working on the same repo?
π Strong Answer:
βWe use:
Feature branches
Clear naming conventions
Code owners
Mandatory PR reviews
CI/CD checks
This ensures smooth collaboration and avoids conflicts.β
πΉ Round 5: Rapid Fire (Quick Checks)
β Difference between Fork and Clone?
π Fork = copy on GitHub π Clone = copy on local machine
β What is HEAD in Git?
π Pointer to the current commit/branch
β What is Rebase?
π Rewrites commit history to make it linear
β What is Stash?
π Temporarily saves uncommitted changes
β What is a Tag?
π Marks a release/version
πΉ Real Interview Challenge (Hands-On Thinking)
β Q11: Design a GitHub workflow for automation testing.
π Strong Answer:
βI would:
Trigger workflow on PR and push
Install dependencies
Run Playwright tests
Generate reports
Upload artifacts
Fail build if tests fail
This ensures only tested code gets merged.β
πΉ Final HR + Practical Question
β Q12: Tell me a real problem you faced in GitHub and how you solved it.
π Sample Answer:
βWe had frequent merge conflicts due to long-running branches. I suggested smaller PRs and frequent rebasing. This reduced conflicts and improved deployment speed.β