Git
Code
Track changes, work on branches and keep a reviewable history of code or prompts.
All capabilities · Programming foundations
Collaborate with Git and GitHub
Branch, commit, review PRs, write READMEs and keep a public portfolio employers can inspect.
Explore 3 tools for this projectMarket relevance
Which roles ask for this — and how often
Share of job postings in India, per role, that name this capability.
Prerequisite capability — not asked for by name, but needed for others. Needed for: Ship faster with AI coding assistants, Automate builds, tests and deploys with CI/CD, Publish a portfolio employers can verify.
What employers mean
You should be able to…
- Branch off main for every feature/fix instead of committing straight to main
- Write commit messages that explain why, not just what
- Open a pull request with a clear description, and respond to review comments
- Resolve a merge conflict without losing either side's changes
- Keep a public GitHub profile/README that a recruiter can skim in under a minute
- Use git rebase or squash to keep history clean before merging
- Tag releases and write a CHANGELOG for a project others depend on
Learn — free, link-checked
The few resources that matter
Read · beginner · 20 min · docs.github.com
Creating a pull request
The exact mechanics of opening a clean PR that reviewers can act on — what recruiters actually look at on your GitHub profile. — GitHub Docs
Read · beginner · 30 min · roadmap.sh
Git and GitHub Roadmap
A visual checklist of exactly which Git/GitHub skills to learn in order, so you don't waste time on commands you'll never use. — roadmap.sh
Watch · beginner · 70 min · youtube.com
Git and GitHub for Beginners - Crash Course
Hands-on crash course covering branches, merges and PRs — enough to collaborate on a real repo by the end. — freeCodeCamp.org
Tools for practice
Choose a tool for the job
Start with one tool for each part of your project. You don’t need to learn them all.
3 tools to explore
GitHub
Code · Plan & explain
Publish a project, review changes and explain how someone can reproduce your work.
GitHub Actions
Test · Deploy
Run checks and deployment steps automatically when project code changes.
Practice
A reviewable PR trail on a repo a stranger can run
Take a small tool you have already written and turn its remaining work into a real collaboration history. Push it public with a README someone else could follow from a clean clone, protect main so nothing lands without a PR, then ship the next five changes as five branch-scoped PRs — each with a description, your own review comments, and fix commits that answer them. Rebase at least one messy branch into a history that reads as a changelog before merging it.
Start from
A small tool of your own — the triage CLI or ticket API from an earlier capability, or any script over 100 lines with work left in it
Milestones
- Push the tool public with a runnable README and turn on branch protection · ~1.5h
- Slice the remaining work into five branches and open the first two PRs · ~1.5h
- Self-review each PR with real comments, then answer them in follow-up commits · ~1.5h
- Rebase one branch into a clean history and merge the whole set · ~1.5h
Done when
- Repo has a README with setup instructions that a stranger could follow to run the project
- At least 5 merged PRs, each on its own branch with a descriptive title and body
- main branch is protected — direct pushes are blocked, PRs are required
- At least one PR shows a resolved review comment thread or a rebase to clean up history
Prove it
Evidence a recruiter can check
- Five merged PRs, each on its own branch, each with a description and a review thread you opened and resolved
- The rebase, before and after: a branch's fixup-heavy commit graph squashed into commits that read as a changelog
- Branch protection on main — required checks on, direct pushes off, shown in the settings page
- Setup steps in the README verified from a fresh clone, listed as the exact commands you ran
Signal it
Ran a public repo on a reviewed PR workflow — five branch-scoped PRs with resolved review threads, protected main with required checks, and a rebased history that reads as a changelog.
Interview
Questions you'll get asked
- Walk me through what you do when you get a merge conflict on a shared branch.
- What's the difference between `git merge` and `git rebase`, and when would you use each?
- How do you undo a commit that's already been pushed to a shared branch?
- What makes a good pull request description that speeds up review?
- How would you structure commits for a large feature so reviewers can follow the story?
- What's in your .gitignore for a Python/Node project and why does it matter?
- Tell me about a PR review comment that changed how you wrote the code.