Collaboration Features
Issues and pull requests
An issue tracks a bug, task, or idea and carries assignees, labels, milestones, and comments. A pull request (PR) proposes merging changes from one branch into another and is the centre of code review: reviewers can Comment, Approve, or Request changes. Draft PRs cannot be merged until marked ready. Simple merge conflicts can be resolved in the web editor; complex ones are resolved locally.
Merge methods
GitHub offers three: create a merge commit (preserves all commits plus a merge commit), squash and merge (combines everything into one commit on the base branch), and rebase and merge (replays commits without a merge commit). Questions often test the consequence: squashing collapses history and loses individual commit SHAs.
Conversation tools
@username mentions notify people, #123 links issues and PRs, and referencing a team uses @org/team. Code owners defined in CODEOWNERS are automatically requested for review when matching files change. Suggested changes let reviewers propose exact edits committable from the UI. Notifications arrive based on watch settings, participation, and mentions.
Fork workflows and security
Contributions from forks arrive from branches you do not control, so maintainers approve workflow runs and secrets are withheld from fork-originated runs by default. This is a frequent exam trap: it is not a bug, it is a safeguard.
Worked example
Your team requires one approval and a green CI check. You open a PR, CI fails, you push a fix commit, a teammate approves, and the required check passes - only then does the merge button unlock. Without both conditions the button stays disabled.