Quick primer on Git and GitHub

If your interviewer asks you to explain GitHub and you start babbling about terminals you will still pass if you know the right words. Keep it simple and useful. Git is the version control tool that lives on your machine. GitHub is the remote hosting and collaboration layer that sits on top of Git and adds pull requests issues project boards and access controls.

What GitHub actually does

It hosts repositories and gives teams ways to review code run checks and track work. Think of it as the social network for your code with badges that make merge buttons feel important.

How Git differs

Git handles commits branches merging and history locally. GitHub gives you the remote storage and workflow features that let multiple humans accidentally rewrite history together.

Pull requests explained with no nonsense

A pull request is a formal request to merge changes from one branch or fork into another. It is the place where code review discussion happens tests run and design trade offs get argued over in polite developer language.

What to mention when asked

• Purpose of a pull request. Review feedback and automated checks before merging.
• Typical flow. Create a branch implement changes open a pull request get reviews address comments and merge when green.
• Why history matters. Clean commits and good messages make reviews painless and postmortems playable.

Fork versus branch and when to use each

Short answer. Use a branch for work inside the repo and a fork for contributions to someone else s project. If you are working on the same team a branch is faster. If you are contributing to open source fork and send a pull request from your fork.

Handling merge conflicts without melodrama

Conflicts happen. Here is a reliable workflow that actually works during interviews and on real projects.

1. Fetch the latest from the remote with git fetch or git pull
2. Create or switch to your local branch with git checkout -b or git checkout
3. Merge the target branch into your branch with git merge or rebase if your team prefers
4. Open conflicted files and pick the correct changes then save the files
5. Stage and commit the resolutions with git add and git commit
6. Push the resolved branch to the remote with git push

When asked explain why you chose merge or rebase and what you did to verify the result. A quick test run and a clear commit message go a long way.

Code review and PR etiquette

Review comments should be focused on code and impact. Explain trade offs give examples and avoid vague statements. If you get feedback show that you understand it and either accept it or explain the trade off politely.

Issues and project boards made tolerable

Issues track bugs features and tasks. Project boards give you a Kanban view for planning and prioritization. Use clear issue titles labels and links to pull requests so no one has to play detective later.

Access control and protected branches

Use teams and role based permissions to grant the least privilege required. Protect important branches with required reviews passing checks and restriction rules so nobody accidentally deploys a half baked idea.

How to prepare for a live coding session or PR review

• Create a tiny demo repo that shows your approach and trade offs
• Keep commits focused and messages clear
• Write a concise pull request description that explains intent tests and known limitations
• Be ready to defend design choices with real examples not buzzwords
• Practice walking through the repo like you are narrating a tour that only slightly judges the audience

Final tip Bring a small demo and a calm attitude. Interviewers prefer clarity and practical context over jargon. If you can explain how you fixed a merge conflict without blaming anyone you will do fine and maybe even impress someone with a love of branch hygiene.