GitHub Platform Language

A GitHub Actions workflow is an automated process defined in a YAML file stored in the .github/workflows directory. Teams say "the CI workflow runs on every push to main" or "we have a release workflow that triggers when a tag is pushed." Key vocabulary includes "trigger" (the event that starts a workflow), "job" (a group of steps that run on the same runner), "step" (a single task within a job), and "runner" (the server that executes the job). Engineers say "the deploy job depends on the build job passing" to describe job dependencies.

Pull request language includes: "I have opened a PR for the authentication refactor," "this PR needs two approvals before merging," and "I left a blocking comment on the database migration." Reviewers say "requesting changes" when a PR needs revision, "approving" when satisfied, or "commenting" for non-blocking feedback. Teams use phrases like "the PR is ready for review," "please address the review comments," and "this is a draft PR — not ready for review yet." Merging strategies are described as "squash and merge," "rebase and merge," or "create a merge commit."

Common branching strategies and their English terminology include: "trunk-based development" (all developers commit to a single main branch with short-lived feature branches), "Git Flow" (using main, develop, feature, release, and hotfix branches), and "GitHub Flow" (feature branches that are merged directly to main after review). Teams say "we follow trunk-based development to reduce merge conflicts" or "we are deprecating the develop branch and moving to a simpler branching model." A "long-lived branch" is considered an anti-pattern in most modern workflows.

A CODEOWNERS file maps paths or file patterns to the GitHub users or teams responsible for reviewing changes. Engineers say "the CODEOWNERS file means that any change to /src/payments/ requires approval from the payments team" or "I need to add the security team to CODEOWNERS for the authentication module." When a required code owner has not reviewed, GitHub blocks merging with the message "review from code owners required." Teams discuss "keeping CODEOWNERS up to date" as a governance hygiene task.

Repository governance language includes "branch protection rules" (settings that prevent direct pushes to protected branches), "required status checks" (CI checks that must pass before merging), and "repository rulesets" (newer policy objects that apply across multiple branches). Teams say "we have enabled branch protection on main requiring two approvals and a passing CI run" or "we enforce signed commits on the release branch." The terms "owner," "maintainer," and "contributor" describe different levels of access and responsibility.

Effective issue titles are specific and actionable: "Login button unresponsive on Safari 17 when JavaScript is disabled" is preferred over "Login doesn't work." Descriptions follow a template including steps to reproduce, expected behaviour, actual behaviour, and environment details. Feature requests use language like "as a user, I would like to…" (user story format) or "proposal: add support for SAML authentication." Labels such as "bug," "enhancement," "good first issue," and "help wanted" are applied during triage.

Triage is the process of reviewing, categorising, and prioritising incoming issues. Teams say "we have a weekly triage session to review new issues" or "this issue needs more information before we can triage it." Labels used during triage include "needs-triage," "confirmed," "duplicate," "wontfix," and "stale." Maintainers close issues with phrases like "closing as duplicate of #123" or "closing as this is by design — the behaviour is intentional." Stale bots automatically comment "this issue has been inactive for 60 days and will be closed unless there is further activity."

Secrets are encrypted values stored at the repository, environment, or organisation level and injected into workflows at runtime. Engineers say "the API key is stored as a repository secret and referenced in the workflow as ${{ secrets.API_KEY }}" or "we use environment-level secrets so that production credentials are only available to the deploy-production workflow." The term "masked" refers to secrets being hidden in workflow logs. Variables (non-sensitive configuration) are described separately as "repository variables" or "workflow environment variables."

GitHub Projects is a project management tool integrated with repositories. Teams say "we track our sprint in GitHub Projects using a kanban board" or "the issue is in the 'In Progress' column on the project board." Items progress through columns such as "Backlog," "Ready," "In Progress," "In Review," and "Done." Teams say "let's move this to the next sprint" or "this epic has five linked issues." The term "iteration" is used for sprint-like time-boxed cycles within GitHub Projects.

The GitHub CLI (gh) allows developers to interact with GitHub from the terminal. Common phrases include "I use gh pr create to open a pull request without leaving the terminal," "gh issue list shows all open issues in the current repository," and "gh workflow run triggers a workflow manually." Teams document CLI usage in contributing guides with commands like "run gh pr checkout 42 to check out a PR locally for testing." The phrase "authenticate with gh auth login before running any commands" is standard in onboarding documentation.