Git & GitHub interview questions 101-125: Advanced GitHub Actions, Repository Internals, Submodules, LFS & Diagnostic Tools.
Open a question for the full answer, code and interview guidance.
A GitHub Actions environment represents a deployment target such as development, staging, or production. Environments can be used to scope deployment configuration and apply protection rules before a job is allowed to access that environment.
Environment protection rules add controls around jobs that target a GitHub environment. Depending on repository capabilities and configuration, deployment can be gated by reviewers, waiting periods, branch or tag restrictions, or other protection mechanisms.
Workflow permissions control what the automatically provided GitHub token can do. Permissions can be set at workflow or job level for capabilities such as reading repository contents or writing certain repository resources.
GITHUB_TOKEN is an automatically generated token made available to workflow jobs for authenticated operations against the repository and GitHub APIs. Its effective capabilities depend on repository settings and the workflow's permissions configuration.
Reusable workflows allow one workflow to call another workflow so common CI or deployment logic can be maintained centrally. They reduce duplication across repositories or multiple pipelines within an organization.
A composite action packages multiple workflow steps into a reusable action. It is useful when the same sequence of shell commands or actions must be reused without defining an entire reusable workflow.
workflow_dispatch is an event that allows a workflow to be started manually. It can define inputs so the person starting the workflow can choose values such as an environment or deployment mode.
A workflow can use the schedule event with POSIX cron syntax to request execution at configured UTC times. Scheduled workflows are useful for maintenance, periodic tests, reports, or dependency tasks.
Expressions use the ${{ ... }} syntax to evaluate workflow data. Contexts expose structured information about the workflow run, repository, event, matrix, jobs, steps, variables, secrets, and other supported values.
The if condition controls whether a job or step should run. It can inspect event data, previous step outcomes, matrix values, inputs, or other supported contexts.
Concurrency controls how multiple workflow runs or jobs in the same logical group are handled. It can prevent overlapping deployments or cancel an older in-progress run when a newer run supersedes it.
A self-hosted runner is a machine managed by you or your organization that executes GitHub Actions jobs. It can provide custom hardware, software, network access, or operating-system configuration that hosted runners do not provide.
A Git submodule lets one repository record a reference to a specific commit of another repository. The parent repository tracks the submodule path and the referenced commit rather than embedding the other repository's full history as ordinary files.
A repository with submodules can be cloned with --recurse-submodules so Git initializes and checks out the recorded submodule commits. If the repository was cloned normally, submodules can be initialized and updated afterward.
Git Large File Storage, or Git LFS, is an extension designed for versioning large binary files without storing every large file version directly as a normal Git blob in the main repository history. Git stores small pointer files while LFS manages the associated large content.
A bare repository contains Git repository data without a normal checked-out working tree. It is commonly used as a central repository that developers push to and fetch from rather than edit directly.
The .git directory contains the local repository's metadata and object database. It includes references, configuration, logs, the index, objects, and other internal data required for Git history and operations.
Git's object database is built primarily around blobs, trees, commits, and annotated tag objects. Blobs store file content, trees describe directory snapshots, commits connect a tree to parent history and metadata, and tag objects can provide annotated references.
A blob stores file content without a filename. A tree maps names to blobs or other trees and therefore represents a directory snapshot. A commit points to a root tree and records metadata such as parent commit references, author information, committer information, and a message.
Git identifies stored objects using cryptographic hashes calculated from object content and metadata framing. Users commonly work with abbreviated object IDs when they are unambiguous.
git bisect helps locate the commit that introduced a regression by performing a binary search through commit history. You mark a known bad commit and a known good commit, then test the commits Git selects.
git blame shows which commit and author last changed each line of a file. It is useful for finding the historical context of a line so you can inspect the relevant commit or discussion.
git grep searches text in files known to Git and can search the working tree or specified revisions. It is fast and useful for locating symbols, strings, configuration values, or references across a repository.
git clean removes untracked files from the working tree. Because those files are not tracked by Git, Git may not be able to restore them after deletion.
git worktree allows multiple working trees to be attached to one Git repository, making it possible to check out different branches in separate directories at the same time.