Module 3: Git and ADO

Most Wasteology source lives in Azure DevOps (ADO) repositories. If you've used GitHub before, the concepts (branches, commits, pull requests) all transfer — what's specific to Wasteology is how you authenticate and what a PR has to pass before it can merge. This module covers both.

HTTPS remotes and the PAT push pattern

ADO repos here are cloned over HTTPS, not SSH, and pushing requires a Personal Access Token (PAT) rather than an SSH key or interactive browser login. Every ADO-managed project's .env carries an ADO_PAT key for exactly this purpose.

The canonical push pattern avoids ever letting git prompt interactively for credentials — it passes the PAT through an inline credential helper instead:

ADO_PAT=$(grep ADO_PAT .env | cut -d= -f2 | tr -d '"')
BRANCH=$(git rev-parse --abbrev-ref HEAD)
git -c credential.helper= \
    -c "credential.helper=!f() { echo username=x; echo password=${ADO_PAT}; }; f" \
    push -u origin "${BRANCH}"

The -c credential.helper= at the start clears whatever global credential helper (e.g. a store helper) might otherwise fire and prompt for input — the inline helper that follows always supplies the token non-interactively. You'll see this pattern used verbatim across Wasteology repos rather than each one improvising its own.

Where the PAT lives

The PAT is a per-project .env value, never committed to the repo and never pasted into a PR description or chat message. If you don't have one yet for a repo you need to push to, ask whoever manages ADO access for that project rather than reusing someone else's.

Opening a pull request

Once your branch is pushed, you open a PR the same way you would on any git host — through the ADO web UI, or via the two slash commands most Wasteology repos provide for this:

Command	Purpose
/git-update	Stage → commit → authenticated push → create PR, for feature branches
/pull_request	Push the current branch and create a PR, with auto-complete wired through the ADO REST API

These wrap the same push pattern above plus the ADO REST API call to open the PR — they exist so the exact non-interactive credential pattern doesn't have to be retyped by hand every time.

Required branch policies

A pull request in most Wasteology repos has to clear branch policies before it's allowed to merge — automated gates, not just a human reviewer's opinion. The one you'll hit in nearly every repo is lat check (from Module 2): it validates every wiki link and every @lat: code reference in the repo's lat.md/, and it runs offline and deterministically — no LLM key needed, because it's checking link structure, not doing semantic search. That's what makes it safe to configure as a required status check rather than an advisory one: a PR that renames or deletes something a lat.md section points at simply cannot merge until the documentation is fixed to match.

The distinction between "advisory" and "required" matters: a check that merely reports a problem without blocking anything isn't a real gate — it relies on someone remembering to look at it. A required status check is enforced by ADO itself; the merge button doesn't work until it's green.

🗑️

Wastey says

Depending on the repo, branch policy may also require a minimum number of reviewers, or other project-specific checks (tests, linting) alongside lat check. The lat check gate is the one piece you'll see consistently across Wasteology repos, which is why it's the one called out here by name.

Hands-on lab

This is a dry run — you don't need to actually merge anything.

1. In a repo you have push access to, create a new branch off the current default branch:

   git checkout -b onboarding/dry-run-pr

2. Make a small, harmless change (fixing a typo in a comment is fine) and commit it.
3. Push it using the PAT pattern above (or /git-update if the repo has the command).
4. Open a PR — either through the ADO web UI or /pull_request. Write a real title and a short description of what changed and why, as if this were a real change (even though it's a dry run).
5. Look at the PR's checks/policies tab. Identify which checks are running, and which (if any) are marked as required. If lat check is one of them, that's the gate this module described.
6. Close the PR without merging once you've inspected it (or ask a teammate to walk through reviewing it with you, if you'd like real practice with the review side too).

Practice: the PAT push pattern

pushing a branch — PAT read from .env, no interactive prompt

$ git -c credential.helper= -c "credential.helper=!f() { echo username=x; echo password=${ADO_PAT}; }; f" push -u origin "${BRANCH}"▋

Order the PR flow

Put a Wasteology ADO PR through the right order, from pushed branch to merged:Put in order

1Open a PR (ADO web UI, /git-update, or /pull_request)

2A human reviewer approves

3lat check runs as a required branch policy

4Merge

5Push the branch (PAT credential-helper pattern)

Knowledge check

What does the canonical ADO push pattern's `-c credential.helper=` accomplish?

It disables git entirelyIt clears any global credential helper first so the inline PAT helper is the only one that fires, avoiding an interactive promptIt stores the PAT permanently in git config

Why is lat check safe to run as a required (blocking) branch policy rather than just advisory?

Because it always passesBecause it's offline and deterministic — it validates link/reference structure without needing an LLM callBecause it only runs once a week

What's the practical difference between an 'advisory' check and a 'required' status check on a PR?

None — both behave identicallyA required check is enforced by ADO itself and blocks merge; an advisory one only reports, relying on someone noticingAdvisory checks run faster

Next up: Module 4 — The Data Platform.