Programming foundations

Collaborate with Git and GitHub

Branch, commit, review PRs, write READMEs and keep a public portfolio employers can inspect.

~8 focused hours·beginner

Tools: Git, GitHub, GitHub CLI (gh), pre-commit, GitHub Issues/Projects

Market relevance — share of job ads asking for this
Prerequisite capability — not asked for directly, but needed for others.
What employers mean

You should be able to…

  1. Branch off main for every feature/fix instead of committing straight to main
  2. Write commit messages that explain why, not just what
  3. Open a pull request with a clear description, and respond to review comments
  4. Resolve a merge conflict without losing either side's changes
  5. Keep a public GitHub profile/README that a recruiter can skim in under a minute
  6. Use git rebase or squash to keep history clean before merging
  7. Tag releases and write a CHANGELOG for a project others depend on
Learn — free, link-checked

The few resources that matter

Practice

Public Portfolio Repo with a Real PR Trail

Take any small tool you've built (or the API/CLI from another capability) and push it to a public GitHub repo with a proper README (setup, usage, architecture diagram). Open at least 5 real feature/fix PRs against your own main branch over separate commits, each with a description and a self-review comment, and protect main with required status checks.

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

  • Public GitHub repo URL with visible PR history and a clean commit log
  • README that documents architecture and how to run/test the project
  • Screenshot or link showing branch protection rules enabled on main
Interview

Questions you'll get asked

  1. Walk me through what you do when you get a merge conflict on a shared branch.
  2. What's the difference between `git merge` and `git rebase`, and when would you use each?
  3. How do you undo a commit that's already been pushed to a shared branch?
  4. What makes a good pull request description that speeds up review?
  5. How would you structure commits for a large feature so reviewers can follow the story?
  6. What's in your .gitignore for a Python/Node project and why does it matter?
  7. Tell me about a PR review comment that changed how you wrote the code.