GitHub, Branches and Pull Requests

Work on a feature branch, push it to GitHub and open a pull request into main for review and CI; only the main pipeline releases.

GitHub hosts Git repos and adds collaboration tools: pull requests (PRs), reviews, issues, Actions. New GitHub repos default to the main branch (older material says master).

Feature branch workflow:

sequenceDiagram
  participant Dev
  participant GH as GitHub
  participant CI as CI pipeline
  Dev->>Dev: git switch -c feature/login, commit
  Dev->>GH: git push -u origin feature/login
  Dev->>GH: gh pr create --base main
  GH->>CI: run build + test (no release)
  CI-->>GH: green check
  GH->>GH: review, approve, merge into main
  GH->>CI: main pipeline: build, test, release

Step	Details
Create a branch	From the latest `main`, named after the work: `feature/login`, `fix/cart-total`
Push	`git push -u origin feature/login`
Open a PR	Base = `main`, head = `feature/login`, clear title + description
Review & CI	Reviewers comment; CI must be green (status checks)
Merge	Merge commit, squash or rebase; delete the branch after merging

Branch protection on main: require PRs, at least one approval, passing status checks, no force pushes.
In CI/CD: a push to main triggers the full pipeline (with release); feature-branch pipelines only build and test, without release.
The GitHub CLI gh opens and lists PRs from the terminal (run gh auth login first).

Traps: committing straight to main and skipping review; letting feature branches run production deploy stages; opening a PR with base and head swapped.

Command	Meaning
`gh pr create --base main --head feature/login --title "Add login" --body "Login form with validation"`	Open a PR
`gh pr list`	List open PRs
`gh pr merge 7 --squash`	Merge PR number 7

Writing a good pull request

Keep it small: a few hundred changed lines at most, so reviewers can read it properly.
Describe what changed, why, and how it was tested; link the issue (Closes #42 closes it automatically when merged).
Open it early as a draft PR to get feedback before the work is finished.
Use a PR template (.github/pull_request_template.md) so every PR answers the same questions.

Reviewing well

Reviewers check correctness, readability, tests, and security, not personal style that a linter could enforce. GitHub lets you Comment, Approve, or Request changes; suggestions can be applied with one click. A CODEOWNERS file assigns reviewers automatically by path, for example /infra/ @example-org/platform-team.

Merge methods compared

Method	Result on `main`	Fits
Merge commit	All branch commits plus a merge commit	Keeping full history
Squash and merge	One commit per PR	Clean history from messy branches
Rebase and merge	Branch commits replayed linearly	Linear history with each commit kept

Repositories can allow only some methods and require a linear history.

Automation around PRs

GitHub Actions workflows in .github/workflows/ run tests on every PR and report status checks.
Required status checks and rulesets prevent merging until CI and reviews pass.
Dependabot opens PRs that update vulnerable or outdated dependencies.
Secret scanning and push protection stop credentials from being committed.

Forks and contributing to open source

Without write access, you fork the repository to your account, push a branch there, and open a PR from the fork to the original. Keep the fork current with git remote add upstream https://github.com/example-org/my-app.git and git pull upstream main. GitLab calls the same thing a merge request, and Azure Repos also uses pull requests.