Welcome to Azure DevOps: Where branch policies meet reality
Let's talk about Git in Azure DevOps. Not GitHub. Not GitLab. Not Bitbucket. Azure DevOps. You know, the one with a UI that looks like it was designed during a coffee break in 2013 and hasn't been touched since.
You open your repo. You see branches. Lots of them. Why is there a dev-john-temp2? Who knows. Why is someone pushing straight to main on a Thursday? Because nobody locked it down. And what's the branching strategy? "Yes."
Welcome to the wild west of Git in Azure DevOps.
The Good
- It is Git under the hood. That means everything Git can do, it can technically do here.
- You can integrate pipelines, permissions, and work items without duct tape.
- Branch protection policies exist—you just have to find them.
- Merge strategies are flexible if you squint hard enough.
The Bad
The patience required to navigate Azure DevOps UI (circa 1432)
- The repo UI is functional if you have the patience of a monk and the eyesight of a hawk.
- Pull request UX is... present. You want side-by-side diffs, comment threading that doesn't glitch, and file-level visibility? Try again.
- You'll spend more time arguing over PR approvals and auto-complete conditions than actually reviewing code.
The Workarounds That Actually Work
- Lock down
mainearly. Make pushing to it feel like crossing a moat full of lawyers. - Define a branching strategy and enforce it. GitFlow, trunk-based, feature branches—pick one, write it down, enforce it in policy.
- Use templates for PR descriptions. Because "fixed stuff" isn't a change log.
- Automate where human discipline will fail. Auto-tag, auto-format, auto-reject commits that don't follow the rules. Humans will forget. YAML won't.
Horses for Courses (Or: Stop Driving a Tank to Work)
Your overengineered pipeline trying to fit into a two-person team's workflow
You wouldn't drive a tank to your office job unless you're in the business of demolishing traffic lights. So why are you building hyper-granular, micro-managed pipeline monoliths for a team that can barely get through a code review without bikeshedding the formatting?
Pick tools and processes that match the maturity of your team. Not the architecture you saw in a conference keynote. Not what the vendor demoed with six SREs and three weeks of prep time.
If you've got a small, scrappy team with one DevOps person and a few analysts, maybe don't go full Terraform + Argo + GitOps + OPA policies on day one. Azure DevOps with some solid YAML and RBAC is more than enough. Get good at walking before you script a moon landing.
In short: don't overengineer for f***'s sake.
Final Thoughts
Finding inner peace with Azure DevOps (results may vary)
- Use a real IDE. Don't rely on the DevOps web editor unless you enjoy pain. VS Code, JetBrains, even Notepad++ with Git integration will do a better job. Manage your Git lifecycle locally, push when it's clean, and review in something that doesn't crash when you open a JSON file.
- Understand the pipeline YAMLs. Azure DevOps uses some seriously powerful YAML under the hood. You get variable substitution, file templates, conditional logic—it's more expressive than most people give it credit for. If you're copying pipeline files from Stack Overflow, read the docs first. There's gold in there.
- Use service principals. Don't shove connection strings and access keys into YAML. Use Azure's service principals and managed identities to push to Azure resources securely. It's safer, scalable, and doesn't leave secrets lying around like it's 2010.
Azure DevOps is like a Leatherman multi-tool: awkward in the hand, but it gets the job done—eventually. Git is Git. What you build on top of it is either a beautiful CI/CD experience or a never-ending PR thread that ends in despair.
So document your workflow. Automate what you can. And maybe—just maybe—don't name your branch final_final2_cleanthisoneup.
Because nothing says "we don't understand Git" like 27 open branches and no working pipeline.