Welcome back to GRC Building Blocks, where we slow down the vocabulary that experienced practitioners and engineers can use without realizing someone else may be hearing it for the first time.
So far, many of our Building Blocks have lived comfortably inside traditional GRC: policy, standards, controls, evidence, frameworks, and audits.
GRC Engineering expands the vocabulary.
If you come from compliance, audit, privacy, risk, or another non-development background, engineering conversations can suddenly fill up with repos, commits, branches, pushes, pulls, PRs, and merges.
You do not need to become a software engineer to follow the conversation. You just need a useful mental model and enough vocabulary to know what is happening.
Let's learn to speak a little Git.
First: Git and GitHub are not the same thing
A useful beginner shortcut is:
Git tracks the work. GitHub gives people a place to collaborate around it.
They are closely related, which is why people sometimes use the names casually, but they are not interchangeable.
The project has a home: the repository
A repo is useful to think of as the project's workspace plus its memory.
That matters to GRC practitioners because a repository can tell us quite a bit about how technical work happens even when we do not understand every line of code inside it.
Commits create the history
Imagine an engineer changes a configuration so administrator access requires MFA and records that work with a message such as:
Require MFA for privileged access
The commit becomes part of the project's history.
A commit tells us that a change was recorded. It does not, by itself, prove that the change was reviewed, approved, tested, or deployed. Those are separate questions.
Branches give work somewhere safe to develop
Suppose the current application is stable, but the team wants to add a new evidence-export feature.
Instead of changing the primary version directly, someone might create:
feature/evidence-export
Work can happen there until the team is comfortable bringing it back into the main project.
Clone, push, and pull describe movement
A few terms make much more sense once you picture where the repository lives.
Clone means creating a local copy of a repository, including its files and history.
Push sends local commits to a remote repository such as GitHub.
Pull brings remote changes down and integrates them into the local branch.
A simple mental picture:
local computer → push → GitHub
GitHub → pull → local computer
One warning for beginners: pull and pull request are not the same thing.
A pull request is where the process becomes visible
A pull request can become a surprisingly rich record.
Depending on the project, you may be able to see:
- the actual changes being proposed
- who authored them
- reviewers and approvals
- discussion about the change
- automated test or security-check results
- whether the work was ultimately merged
That should already sound interesting to someone working in assurance.
A PR can make parts of the technical change process observable.
Merge brings the approved work together
Our simplified workflow now looks something like:
Clone → Branch → Change → Commit → Push → Pull Request → Review → Merge
You do not need to memorize the sequence yet.
The important thing is understanding the story: someone worked on a separate line of the project, recorded their changes, shared them, asked for review, and eventually incorporated the accepted work.
Watch the workflow in seven minutes
Seeing these ideas move is often easier than reading ten more definitions. This short beginner video gives a fast visual introduction to Git and GitHub without assuming you already work as a developer.
Do not worry about remembering every command shown in the video. For now, concentrate on recognizing the concepts and the direction work is moving.
Why should a GRC engineer care?
Because increasingly, the systems we need to understand, govern, and assure are built this way.
Imagine reviewing a security change and being able to open its pull request. You might see the proposed change, the author, reviewers, approval discussion, automated checks, and the point when the work was merged.
You may not understand every line of code.
That is okay.
You can still understand the process around the code.
Git and platforms such as GitHub help make technical activity traceable. Commits preserve change history. Branches separate work. Pull requests create review records. Automated checks can attach results to the same workflow. Together, those mechanics can turn technical happenings that might otherwise be difficult to observe into events and evidence that can be reviewed later.
That is one of the ways tools like Git enable GRC Engineering: they help make technical work auditable.
We will add more engineering vocabulary in future Building Blocks. For now, if you can follow the story from repository to commit to branch to pull request to merge, you already understand more of the engineering conversation than you did a few minutes ago.
Need to revisit a definition? Start with Git in the GRC Terms Explorer, then follow the related concepts across the workflow.