kb/collab
Pull request and code review as a real process, without the pain: branch protection rules and CODEOWNERS to gate changes. How to resolve merge conflicts in an IDE and with `git mergetool`. The strategies for merging a PR are a merge commit, a squash, or a rebase.
A mode in which a PR merges automatically once all required reviews and checks pass. Enable it with `gh pr merge --auto` or the "Enable auto-merge" button in the UI. Frees you from manually clicking "merge" after receiving an approve and a green CI run.
A set of rules that GitHub/GitLab/Bitbucket applies to any attempt to modify a protected branch. Blocks direct pushes, requires a PR with an approval, requires green CI, and blocks force-pushes. Without these rules anyone with write access can overwrite main with a single commit.
Reading and discussing another developer's code before merge. The primary goal is sharing context, not finding bugs (bugs are a side effect). A good review improves the code and spreads knowledge of the system across the team.
The `.github/CODEOWNERS` file maps paths in the repo to teams or individuals. When a PR touches those paths, the owners are automatically assigned as reviewers. Combined with branch protection, it blocks merge until they approve.
A PR state that signals "work is not done, do not review yet." CI runs on draft PRs, but reviewers are not assigned automatically and the merge button is blocked. Promote to a regular PR with `gh pr ready` or the "Ready for review" button.
A web inbox at `github.com/notifications` plus email alerts for repo events. Watch raises the subscription level. Filters like `is:unread reason:mention` cut through the noise. The main hygiene habit is reviewing your watch list periodically at `/notifications/subscriptions`.
An organization is a container for multiple users and repositories with shared billing, security settings, and teams. A team is a named group of users within an organization used for batch access grants. A user can be a member of many organizations at the same time.
GitHub offers three buttons to merge a PR: Create a merge commit (--no-ff, with a merge commit), Squash and merge (one squashed commit with no parent from the branch), and Rebase and merge (rebase + fast-forward with no merge commit). Teams pick one for the whole project.
A request to merge a branch into the main branch after passing review and CI. On GitHub/GitLab/Bitbucket it is the standard mechanism for collaborative work. Technically it is not a Git command but a hosting feature built on top of branches and commits.
The file `.github/PULL_REQUEST_TEMPLATE.md` is pre-filled into the description field of every new PR in the repo. It standardizes the structure: what/why/how to test/checklist. Saves reviewer time and reduces re-review because the author self-checks before submitting.
External checks (CI, security scan, code coverage) attached to a commit that report a green or red status to GitHub. In [[branch-protection]] you can mark specific checks "required"; without them merge is blocked.