Git & GitHub interview questions 76-100: GitHub Collaboration, Repository Rules, Issues, Releases & Actions CI/CD.
Open a question for the full answer, code and interview guidance.
A protected branch is a branch governed by repository rules that restrict how changes can be made. Protection can require pull requests, reviews, status checks, signed commits, linear history, or other conditions before changes are accepted.
GitHub rulesets provide centralized rules that can target branches or tags and enforce repository policies. Depending on configuration, they can require pull requests, reviews, status checks, signed commits, deployment success, or restrictions on updates and deletions.
Required status checks are automated checks that must reach an acceptable result before a protected change can be merged. They are commonly produced by CI workflows that build the application, run tests, perform linting, or execute security checks.
A CODEOWNERS file maps repository paths or patterns to users or teams that are responsible for reviewing those areas. GitHub can automatically request matching code owners when a pull request changes owned files.
A GitHub issue is a collaboration item used to track work such as bugs, enhancements, tasks, questions, or planning discussions. Issues can contain descriptions, comments, labels, assignees, milestones, and links to related development work.
Labels categorize issues and pull requests, for example bug, enhancement, documentation, or priority categories. Assignees indicate who is responsible for or actively working on an item.
GitHub supports closing keywords in pull request descriptions or commit messages when they reference an issue in an appropriate repository context. Common keywords include closes, fixes, and resolves.
A GitHub release is a published distribution point associated with a Git tag. It can include release notes, generated notes, links to source archives, and uploaded binary assets.
Semantic Versioning uses a version format such as MAJOR.MINOR.PATCH. In the standard model, major versions represent incompatible API changes, minor versions add backward-compatible functionality, and patch versions contain backward-compatible fixes.
GitHub Actions is GitHub's automation platform for repository workflows. Workflows can build code, run tests, perform static analysis, package applications, publish artifacts, deploy software, or automate repository tasks.
A workflow is an automated process defined in a YAML file under .github/workflows. It contains triggers and one or more jobs, with each job containing steps that run commands or reusable actions.
Events determine when a workflow should run. Common triggers include push, pull_request, workflow_dispatch, schedule, release, and other repository activity.
A workflow contains one or more jobs. A job runs on a configured runner and contains an ordered sequence of steps. Steps can execute shell commands or invoke reusable actions.
A runner is the machine or environment that executes a GitHub Actions job. GitHub provides hosted runners for supported operating systems, and organizations can also configure self-hosted runners.
actions/checkout is an official GitHub action commonly used to place repository content into the runner's workspace so subsequent workflow steps can build, test, or inspect it.
A typical .NET CI workflow checks out the repository, installs the required .NET SDK, restores dependencies, builds the solution, and runs tests. Production workflows may also cache dependencies, upload test results, or package artifacts.
Continuous Integration, or CI, is the practice of integrating changes frequently and automatically validating them with repeatable checks such as builds and tests.
CD can refer to Continuous Delivery or Continuous Deployment. Continuous Delivery keeps software in a deployable state and may require a manual approval for production, while Continuous Deployment automatically releases qualifying changes to production.
Secrets are encrypted values stored in GitHub for use by workflows without hard-coding sensitive credentials in the repository. They can be configured at repository, environment, or organization scope depending on the workflow design.
Configuration variables store non-sensitive configuration values that workflows can reference. Secrets are intended for sensitive values and receive additional protection and masking behavior.
Artifacts are files produced by a workflow that are uploaded and retained by GitHub for later download or use. Examples include compiled packages, test reports, logs, coverage reports, or deployment bundles.
Caching stores reusable dependency or build data so later workflow runs can avoid downloading or regenerating the same content. Good caching can reduce CI execution time and external network usage.
A matrix strategy runs variations of a job across combinations of configured values, such as operating systems, runtime versions, or target environments.
The needs keyword creates a dependency between jobs. A dependent job waits for the required job or jobs and normally runs only when the required jobs complete successfully, subject to workflow expressions and conditions.
A basic pull-request CI workflow should run automatically for relevant pull requests, check out the exact proposed code, configure the required toolchain, restore dependencies, build the project, and execute automated tests.