GitHub

GitHub's server refuses the push. The remote rejects the ref update with a protected-branch error, nothing lands on main, and your local commits are untouched — you push a topic branch and open a pull request instead.

It links the pull request to issue 142 and closes that issue automatically when the pull request is merged into the repository's default branch. Merging into any other branch links but does not close.

GitHub repositories have five access roles: Read (view and clone), Triage (manage issues and pull requests without pushing), Write (push code), Maintain (most repository settings, no destructive ones), and Admin (full control, including visibility, transfer and deletion).

It forces the pull request branch to contain the base branch's newest commit before merging, so the required checks proved green on that exact combination. Without it, checks only prove the branch was green against an older base.

The last matching line in the file wins, and only that line's owners apply. Ownership is never additive across rules, so an earlier specific rule loses to a later broad one — write general patterns first and specific ones last.

Approve endorses the pull request and counts toward any required approvals. Request changes records a blocking objection that stays until the reviewer approves or the review is dismissed. Comment leaves feedback with no verdict either way.

By default approvals survive a new push and keep counting. Inline comments on lines that changed are marked outdated and collapse. A repository can opt in to dismissing stale approvals on every push, and anyone with write access can dismiss a review manually with a reason.

A suggested change is a review comment containing a fenced suggestion block with replacement lines. Anyone with write access to the pull request's branch can apply it in one click, creating a commit on that branch that credits the reviewer as co-author.

Say what you can honestly review and push back on the size. Then work systematically: read the description and tests first, review commit by commit, use the file filter and viewed checkboxes, hide whitespace, and batch findings into one review separating blocking issues from notes.

Measure first: pull time-to-first-review and review size from the pull request data rather than trusting impressions. Then attack the causes — oversized changes, unclear reviewer routing, no agreed turnaround, and manual work that automation should be doing.

GitHub Actions is GitHub's built-in automation and CI/CD system. A workflow is a YAML file in the repository's .github/workflows directory that declares the events triggering it and the jobs to run when one occurs.

GITHUB_TOKEN is a credential GitHub mints at the start of each Actions job, scoped to that one repository. It expires when the job finishes, and at most after 24 hours, so there is nothing to store or rotate.

With OIDC the job requests a short-lived signed token from GitHub and exchanges it for temporary cloud credentials. Nothing long-lived is stored in GitHub, so there is no key to leak, rotate, or exfiltrate from a workflow.

Set an organization-level Actions policy that permits only GitHub-authored, verified-creator, and explicitly allow-listed actions, require third-party actions to be pinned to a full commit SHA, and default GITHUB_TOKEN permissions to read-only.

Put a closing keyword and the issue number, such as "Fixes #123", in the pull request description or in a commit message. When that pull request merges into the repository's default branch, GitHub closes the linked issue.

A GitHub Project stores extra data per item — status, priority, estimate, iteration, target date — as typed fields that labels cannot express, and renders the same items as a table, a board, or a roadmap with independent filters, grouping and sorting per view.

A GitHub issue form renders real input widgets — required text boxes, dropdowns and checkboxes — so the reporter cannot submit an empty or half-filled report. A Markdown template only pre-fills editable text that anyone can delete.

Use a GitHub milestone when the question is "is this batch of work done yet" — it holds one due date and shows a completion percentage. Use labels for everything an issue can be several of at once, like type or component.

Lean on the project's built-in workflows first — auto-add items by filter, then set Status when an item is added, a review is requested or approved, a pull request merges, or an item closes. Reach for an Action or the GraphQL API only for what those cannot express.

A GitHub release is a platform object wrapped around a tag: it adds a title, release notes, uploadable binary assets, draft and prerelease flags, a stable download URL, and API and feed access. The tag itself stays a plain Git pointer.

Draft keeps a GitHub release private to users with push access and does not create its tag until published. Prerelease publishes it but marks it unstable and excludes it from Latest. The latest marker controls which single release the Latest badge and endpoint resolve to.

Ask GitHub to generate notes (generate_release_notes on the API, --generate-notes on the CLI) and shape the output with a .github/release.yml file, whose changelog block groups merged pull requests into categories by label and excludes chosen labels or authors.

Ship v1.2.1. A published version is a fact other people have already fetched and cached, so replacing its contents makes two different artifacts share one name. Burn the bad version, mark it clearly, and move Latest to the good one.

Trigger a workflow on pushes of tags matching your version pattern, grant it contents: write, build the artifacts, then create the release from the pushed tag with generated notes and upload the artifacts as assets before publishing.

A Dependabot alert is GitHub telling you that a package your repository depends on has a known vulnerability. It comes from matching the repository's dependency graph, built from committed manifests and lockfiles, against the GitHub Advisory Database.

GitHub secret scanning matches known credential formats across a repository's commits and raises alerts after the fact. Push protection applies the same detection at push time and rejects the push, so the credential never reaches the repository at all.

Default setup is a GitHub-managed configuration enabled from repository settings with no workflow file: GitHub picks languages, queries and triggers. Advanced setup commits a workflow you own that calls the CodeQL action, so you control build, queries, packs and paths.

Security updates are driven by Dependabot alerts and open a pull request that bumps a vulnerable package to the lowest patched version. Version updates keep dependencies current on a schedule you declare in .github/dependabot.yml, whether or not anything is vulnerable.

Either remove the secret from every commit in the push and push again, or follow the unblock URL and bypass with a reason. Bypassing lets the credential land, creates an alert, and is recorded — so the credential must then be treated as leaked.

Classic PATs carry coarse scopes across every repository the user can reach. Fine-grained PATs pin one resource owner, selected repositories, per-permission access and an expiry. GitHub App installation tokens belong to the app, expire hourly, and are the right choice for automation.

GitHub signs each webhook with the secret you configured: X-Hub-Signature-256 holds a hex HMAC-SHA256 of the raw request body. Recompute that HMAC over the exact bytes received and compare it in constant time, rejecting the request when it differs.

Primary limits are the published hourly request quota for your credential, reported in x-ratelimit-* response headers. Secondary limits are anti-abuse throttles on burst, concurrency and content creation, returned as 403 or 429. Back off on both; never retry straight away.

A GitHub webhook pushes an HTTP POST to your server the moment an event happens, so you learn about it immediately and spend no request quota. Polling burns rate limit, adds latency, and can miss changes that happen between two polls.

Choose GitHub's GraphQL API when one round trip should return exactly the fields you need across related objects, or for surfaces only it exposes, such as Projects v2. You give up simple HTTP caching, several REST-only endpoints, and request-count rate limiting.