🌍 Git & Version Control · subject

Git & Version Control Hosting Platforms and DevOps Integration Syllabus

The Hosting Platforms and DevOps Integration syllabus for Git & Version Control in full: 4 chapters and 15 topics, every one listed below, plus 51 Hosting Platforms and DevOps Integration flashcards with answers.

4Chapters
15Topics
51Flashcards

Hosting Platforms and DevOps Integration syllabus: all 4 chapters

Expand any chapter to see its topics and sub-topics.

  1. GitHub Essentials

    4 topics
    • Repositories, Organizations, and Teams
    • Issues, Projects, and Milestones
    • GitHub CLI and Codespaces
    • GitHub Actions Overview
  2. GitLab and Bitbucket

    3 topics
    • GitLab Repositories and Pipelines
    • GitLab CI/CD Basics
    • Bitbucket and Atlassian Integration
  3. CI/CD with Git

    4 topics
    • Continuous Integration Concepts
    • Triggering Pipelines on Push and PR
    • Automated Testing and Status Checks
    • Continuous Deployment Strategies
  4. Security and Governance

    4 topics
    • Signing Commits with GPG and SSH
    • Secret Scanning and Dependency Alerts
    • Branch Protection Rules and CODEOWNERS
    • Audit Logs and Access Control

Git & Version Control Hosting Platforms and DevOps Integration flashcards — 51 questions with answers

  1. In Git hosting platforms, what is a repository?

    A repository (repo) is a storage location containing a project's files together with the complete version history (the Git object database and refs), enabling tracking, branching, and collaboration on that project.

  2. On GitHub, what is an Organization and how does it differ from a personal account?

    An Organization is a shared account that owns repositories collectively rather than by one person. It provides centralized ownership, member management, teams, and granular access control, whereas a personal account is owned and controlled by a single user.

  3. What is a Team within a GitHub Organization, and what is its main purpose?

    A Team is a group of organization members that can be granted repository permissions collectively and @mentioned. It simplifies access management and can be nested to mirror org structure and cascade permissions.

  4. List the standard repository permission (access) levels GitHub grants to collaborators/teams.

    Read, Triage, Write, Maintain, and Admin, in increasing order of privilege.

  5. What is the difference between a public, private, and internal repository?

    Public repos are visible to everyone; private repos are visible only to explicitly granted users/teams; internal repos are visible to all members of the enterprise but not the outside public.

  6. On GitHub, what is an Issue used for?

    An Issue is a trackable unit for reporting bugs, requesting features, or discussing tasks. It supports labels, assignees, milestones, comments, and cross-references, and can be closed automatically by commits/PRs.

  7. What is a Milestone in issue tracking, and what does it group?

    A Milestone groups related issues and pull requests toward a shared goal or release, tracks their completion percentage, and can carry a due date.

  8. What are GitHub Projects (the Projects boards) used for?

    Projects are customizable planning boards (table, board/Kanban, or roadmap views) that organize and track issues and pull requests across repositories using custom fields, statuses, and automation.

  9. Which keywords in a commit message or PR description will automatically close a linked issue when merged to the default branch?

    close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved (e.g., "Fixes #42").

  10. What is the GitHub CLI (`gh`) and one common use?

    `gh` is GitHub's official command-line tool for interacting with GitHub from the terminal—e.g., creating and reviewing pull requests (`gh pr create`), managing issues, releases, and running workflows without the web UI.

  11. What is a GitHub Codespace?

    A Codespace is a cloud-hosted, containerized development environment (a dev container running on a VM) that provides a ready-to-code VS Code workspace configured for a repository, accessible from the browser or locally.

  12. Which file customizes the environment of a GitHub Codespace or dev container?

    The `devcontainer.json` file (typically in a `.devcontainer` directory), which defines the container image, features, extensions, ports, and setup commands.

  13. What is GitHub Actions?

    GitHub Actions is GitHub's built-in CI/CD and automation platform that runs workflows in response to repository events, defined as YAML files that execute jobs made up of steps on runners.

  14. In GitHub Actions, define the hierarchy: workflow, job, step, and action.

    A workflow contains one or more jobs; each job runs on a runner and contains ordered steps; a step either runs a shell command or invokes an action (a reusable unit of code).

  15. Where must GitHub Actions workflow files be stored?

    In the `.github/workflows/` directory of the repository, as `.yml` or `.yaml` files.

  16. In a GitHub Actions workflow, what does the `on:` key specify?

    It defines the events that trigger the workflow, such as `push`, `pull_request`, `schedule` (cron), `workflow_dispatch` (manual), or `release`.

  17. By default, do jobs in a GitHub Actions workflow run in parallel or sequentially, and how do you enforce order?

    Jobs run in parallel by default; you enforce sequential ordering with the `needs:` key, which makes a job wait for the listed jobs to complete successfully.

  18. On GitLab, what defines a CI/CD pipeline, and in which file?

    A GitLab pipeline is defined in the `.gitlab-ci.yml` file at the repository root, specifying stages and jobs executed by GitLab Runners.

  19. In GitLab CI/CD, what is the relationship between stages and jobs?

    A pipeline is divided into ordered stages; jobs in the same stage run in parallel, and a stage begins only after the previous stage's jobs succeed (unless configured otherwise).

  20. In GitLab CI/CD, what executes the jobs defined in `.gitlab-ci.yml`?

    GitLab Runners—agents (shared, group, or project-specific) that pick up jobs and run them using an executor such as Docker, Shell, or Kubernetes.

Show the other 31 Hosting Platforms and DevOps Integration flashcards
  1. In GitLab CI/CD, what is the purpose of the `script:` keyword in a job?

    `script:` lists the shell commands the runner executes for that job; it is the only required keyword for a job to run.

  2. In GitLab CI/CD, what does the `artifacts:` keyword do?

    It specifies files/directories produced by a job to be saved and passed to later stages or downloaded, such as build outputs or test reports.

  3. In GitLab, what is the difference between `only`/`except` (or `rules`) keywords?

    They control when a job runs. `only`/`except` filter by refs, branches, or event types (legacy), while `rules` is the newer, more expressive mechanism using conditions (`if`, `changes`, `exists`) to include or exclude jobs.

  4. What is Bitbucket, and who develops it?

    Bitbucket is a Git-based code hosting and collaboration platform developed by Atlassian, offering repositories, pull requests, and Bitbucket Pipelines for CI/CD.

  5. In Bitbucket Pipelines, which file defines the CI/CD configuration?

    `bitbucket-pipelines.yml` in the repository root.

  6. How does Bitbucket integrate with the broader Atlassian ecosystem?

    It integrates natively with Jira (linking commits, branches, and PRs to issues), Confluence (documentation), Trello, and Bamboo/Pipelines, enabling smart commits that transition Jira issues from commit messages.

  7. What is a Jira "smart commit," and give an example.

    A smart commit is a commit message with special syntax that acts on a linked Jira issue, e.g., `PROJ-123 #time 2h #comment fixed bug #close` logs work, adds a comment, and closes the issue.

  8. Define Continuous Integration (CI).

    CI is the practice of frequently merging developers' code changes into a shared mainline, where each integration is automatically built and tested to detect integration errors early.

  9. What core problem does Continuous Integration aim to solve?

    "Integration hell"—the difficulty and bugs that arise when developers work in isolation for long periods and merge large, divergent changes infrequently.

  10. Distinguish Continuous Integration, Continuous Delivery, and Continuous Deployment.

    CI automatically builds/tests every change. Continuous Delivery keeps the code always in a deployable state with release requiring a manual approval. Continuous Deployment automatically releases every passing change to production with no manual gate.

  11. What events are most commonly used to trigger CI pipelines?

    A `push` to a branch and the opening/updating of a `pull_request` (merge request); also scheduled runs, tags, and manual dispatch.

  12. Why trigger a pipeline on a pull request rather than only on push to main?

    To validate proposed changes before they merge—running tests and status checks on the merge result so broken code is caught prior to entering the protected/default branch.

  13. In GitHub Actions, what is the difference between the `pull_request` and `pull_request_target` triggers regarding security?

    `pull_request` runs in the context of the PR's fork with a read-only token and no access to secrets by default (safer for untrusted code), whereas `pull_request_target` runs in the base repository's context with secrets access, which is riskier for forked PRs.

  14. What is a status check on a pull request?

    A status check is an automated pass/fail (or pending) report—from CI, tests, linters, or external services—attached to a commit/PR that indicates whether the change meets required conditions before merging.

  15. What is the role of automated testing within a CI pipeline?

    It automatically executes unit, integration, and other test suites on each change to verify correctness, prevent regressions, and provide the fast feedback that gates merges and deployments.

  16. What is a "required status check" in branch protection?

    A status check that must pass (report success) before a pull request can be merged into the protected branch; if it fails or is pending, merging is blocked.

  17. Name three common continuous deployment strategies.

    Blue-green deployment, canary deployment, and rolling deployment (also feature flags / dark launches).

  18. Describe a blue-green deployment.

    Two identical production environments (blue = current, green = new) run in parallel; traffic is switched from blue to green once the new version is verified, enabling instant rollback by switching back.

  19. Describe a canary deployment.

    The new version is rolled out to a small subset of users/servers first; metrics are monitored, and if healthy the rollout gradually expands to 100%, otherwise it is rolled back—limiting the blast radius of failures.

  20. Describe a rolling deployment.

    Instances are updated to the new version incrementally in batches, replacing old instances gradually so the service stays available, without needing a full duplicate environment.

  21. Why sign commits, and what two mechanisms does Git support for it?

    Signing cryptographically proves a commit's author and integrity (verified authorship, tamper-evidence). Git supports signing with GPG keys and with SSH keys (and X.509/S-MIME).

  22. Which Git config and flag enable signing a commit with GPG?

    Set the key with `git config user.signingkey <KEYID>` and sign with `git commit -S` (or enable `commit.gpgsign true` to sign automatically).

  23. How do you tell Git to use an SSH key instead of GPG for signing commits?

    Set `git config gpg.format ssh` and `git config user.signingkey <path-to-ssh-public-key>`, then sign with `git commit -S` (or `commit.gpgsign true`).

  24. What does a "Verified" badge on a GitHub commit indicate?

    That the commit's signature was validated against a key the author registered with GitHub and matches the committer identity, confirming the commit is genuinely from that person and unaltered.

  25. What is secret scanning on a hosting platform?

    An automated feature that inspects commits and repository contents for exposed credentials (API keys, tokens, passwords) using known patterns, alerting maintainers—or blocking the push (push protection)—when a secret is detected.

  26. What are Dependabot / dependency alerts?

    Automated alerts that notify maintainers when a project depends on packages with known security vulnerabilities (from an advisory database), often accompanied by automated pull requests to bump to a patched version.

  27. What are branch protection rules?

    Configurable constraints on important branches (e.g., main) that enforce policies such as requiring pull request reviews, passing status checks, signed commits, linear history, and preventing force pushes or deletion.

  28. What is the purpose of a CODEOWNERS file?

    It defines individuals or teams responsible for specific files/paths using glob patterns; matching owners are automatically requested for review on pull requests touching those paths, and can be required for approval.

  29. Where can a CODEOWNERS file be located in a GitHub repository?

    In the repository root, in the `.github/` directory, or in the `docs/` directory.

  30. What is an audit log in the context of an organization or repository?

    A chronological, tamper-resistant record of significant actions and events (member changes, permission changes, repo creation/deletion, settings changes) used for security monitoring, compliance, and accountability.

  31. What access-control model do platforms like GitHub use to limit what members can do, and what principle should guide its configuration?

    Role-based access control (RBAC) via roles/permission levels assigned to users and teams, guided by the principle of least privilege—granting only the minimum access needed for a task.

Git & Version Control Hosting Platforms and DevOps Integration FAQ

What is in the Git & Version Control Hosting Platforms and DevOps Integration syllabus?

Git & Version Control Hosting Platforms and DevOps Integration is split into 4 chapters: GitHub Essentials, GitLab and Bitbucket, CI/CD with Git and Security and Governance. Together they contain 15 topics.

How many chapters are in Git & Version Control Hosting Platforms and DevOps Integration?

4 chapters, containing 15 topics. The largest chapter is GitHub Essentials, with 4 topics.

Are there flashcards for Git & Version Control Hosting Platforms and DevOps Integration?

Yes — a 51-card Hosting Platforms and DevOps Integration deck, printed in full in the flashcards section of this page and available in the Examius app with spaced repetition. The free plan covers one exam of your choice, including its flashcards; Examius Pro, a one-time purchase, unlocks every other exam and deck.