Git & GitHub Engineering Team Readiness Assessment

Pick the statement that is true of your team today, not the one you are working towards. Each area scores 0 to 3; the result names where to start and links the free lesson for it.

Note

Scored in your browser. Nothing is stored or sent. There is no email gate and no account.

1Git workflow consistencyHow consistent is the way engineers on the team use Git day to day?

Each engineer has their own habits; nobody could describe a shared workflow.There is an informal convention that senior people follow and new joiners pick up by watching.The workflow is written down, and most pull requests follow it.The workflow is written down, enforced where it can be (rules, templates, CI), and reviewed when it stops fitting.

2Branching and historyWhat does the history on your main branch look like?

Nobody looks at it. Merge commits, "wip" commits and reverted reverts.Mostly readable, with occasional force-pushes to shared branches that cause a scramble.A chosen merge method, short-lived branches, and rewriting shared history is understood to be off limits.Bisectable, revertable history: one considered commit per change, and the team could explain why it chose that shape.

3Pull request practiceHow are pull requests reviewed?

Approval is a formality; review quality depends entirely on who is asked.Reviews happen, but with no template, no shared checklist and no expectation of running the change.A template, a review checklist, and at least one meaningful review before merge.Template, checklist, required checks and reviews enforced by rules; small pull requests are the norm and review turnaround is measured.

4Code ownershipHow does a pull request reach the right reviewer?

The author guesses, or asks in chat.A CODEOWNERS file exists but nobody is sure it works, and reviews still go to the wrong people.CODEOWNERS routes review for the important directories and is kept current.CODEOWNERS is ordered correctly, owner approval is required by rule for critical paths, and it is reviewed when teams change.

5Branch rules and rulesetsWhat stops a bad change reaching the default branch?

Nothing. Anyone with write access can push to main.Branch protection on main, set up once, with admins exempt.Protection or rulesets on main and release branches: required checks, required reviews, no force push, admins included.Rulesets applied consistently across repositories, with a documented break-glass procedure instead of standing exemptions.

6CI with GitHub ActionsHow much do you trust a green check?

There is no CI, or it is red so often that nobody reads it.CI runs tests; failures are sometimes merged anyway because "it looked flaky".CI is required to merge, runs what developers run locally, and a red check is fixed before merging.Required, fast (caching, concurrency), matrixed where the code claims compatibility, with artifacts kept from failures.

7Secrets and tokensWhere do credentials live, and who can read them?

In the repository, in .env files, or in a shared document.In repository secrets, readable by every workflow, with no idea which ones are still used.Environment-scoped secrets with required reviewers; workflow permissions declared explicitly.Secret scanning and push protection on; secrets inventoried and rotated; least-privilege tokens per job.

8Cloud authentication from CIHow does a workflow authenticate to your cloud provider?

A long-lived access key stored as a secret, created by someone who may have left.A long-lived key, rotated occasionally, scoped more broadly than it needs to be.OIDC for new workflows; some long-lived keys remain.OIDC everywhere, with trust policies conditioned on repository and environment, and no long-lived cloud keys in GitHub.

9Dependency and supply-chain securityHow do you know what your pipeline pulls in?

We do not. Actions are pinned to tags or branches; dependencies update when someone remembers.Dependabot is on for some repositories; alerts are triaged when there is time.Dependency review on pull requests; third-party actions pinned to commit SHAs; alerts triaged on a schedule.An action allow-list, SHA pinning kept current automatically, dependency review required, and provenance on what you build.

10Developer onboardingWhat happens in a new engineer’s first two weeks with Git and GitHub?

A link to some documentation and a hope.A buddy shows them around; what they learn depends on the buddy.A written onboarding sequence covering the workflow, tools and rules, with someone checking in.A sequenced programme with reading, hands-on exercises and checkpoints that both the engineer and their manager can see.

11AI-assisted engineering governanceHow does the team handle AI-generated code and agent pull requests?

No policy. Some people use Copilot heavily, some not at all, and nobody reviews differently.AI use is allowed and unguided; AI-authored pull requests are reviewed like any other.Repository instructions exist; reviewers know agent pull requests need the test diff read first.Written policy on what may be automated, repository instructions maintained, agent PRs reviewed with a specific checklist, and a person accountable for every merge.

12Infrastructure change through GitHow does an infrastructure change reach production?

Someone runs a command from their laptop.Changes are in Git, applied by hand after merge, with drift nobody measures.Plan on the pull request, apply on merge, in a pipeline; environments promoted deliberately.Declarative state reconciled continuously; drift detected and reverted; git revert is a real rollback path and everyone knows its limits.

Show resultsAnswer all twelve to see results.

Frequently asked questions

Is anything sent anywhere?

No. The assessment is scored by JavaScript in your browser. Nothing is stored, nothing is transmitted, and there is no account. If you want to keep the result, use the copy-as-text option under the results.

How accurate is it?

It is a five-minute self-assessment, so it can tell you where to start and not much more. The result bands are deliberately coarse. For a per-engineer view with scoring guidance, the team programme includes a 19-skill assessment.

Who should answer it?

Whoever knows how the team actually works — usually a lead or a senior engineer. Answering for how you would like the team to work produces a flattering score and a useless result.