What it does

Native Git integration syncs an unmanaged solution and its components to an Azure DevOps Git repository straight from the Solutions area, so app changes land in source control as readable files. Alongside it, Power Platform Build Tools give Azure DevOps and GitHub pipelines the tasks to export, pack, check and import solutions.

Key facts

• Git integration targets Azure DevOps Git repositories and is intended for development environments, not test or production. Downstream environments get builds and pipelines instead.
• Canvas app source lands as .pa.yaml files under \Src — one for the app, one per screen, and one per component in a \Component folder. These are the only files in the repository you should treat as source; the JSON files aren't stable between save and load cycles.
• Canvas apps only become available to commit once you publish. The repository always reflects the last published version.
• You can make minor edits to .pa.yaml in the repository and they're restored when you pull back into the environment. Treat anything in your branch as a published app.
• If the app contains PCF code components you can't edit its .pa.yaml files directly. Doing so stops the app running, and the recovery is loading a previous version in the maker portal.
• pac canvas pack and pac canvas unpack are deprecated. Microsoft now points you at Git integration for source-controlling canvas apps.
• Power Platform Build Tools version 2.0 is CLI-based and is the version being serviced. Version 1.0 is PowerShell-based and gets critical security updates only. You can't mix task versions in one pipeline.
• Build Tools connections support service principal via workload identity federation (recommended), service principal with client secret, or username and password. The last doesn't work with MFA.
• pac admin create-service-principal registers the app, creates the SPN and adds it as an environment admin user in one command. The client secret is shown once and can't be retrieved again.
• The Checker task outputs SARIF, which both VS Code and Visual Studio can display.

When to use / skip

Turn Git integration on for any development environment where more than one person builds, or where the client wants a recovery path that isn't "restore the environment". It's a few steps to enable and gives you diffs, history and short-lived dev environments you can rehydrate from source. Add Build Tools when you need a real build — compiled plug-ins, PCF controls, automated checker gates, deployment to another tenant. If the client's whole estate is low-code and single-solution, Git integration plus pipelines will cover them and a full DevOps pipeline is effort they won't get back.

Configuration decisions

• Which environments connect to Git — development only, and which repository and folder layout across teams.
• Whether code-first components are built by a pipeline into an unmanaged solution and imported, or deployed straight into the maker environment. Microsoft recommends the former, because the latter puts both source and compiled binary in the repository.
• Whether pull requests actually review app YAML, or whether the repository is a safety net and review happens in the environment.
• Which connection type Build Tools use, with workload identity federation as the default answer for any tenant enforcing MFA.
• Whether developer environments are long-lived or created and rehydrated from source per work item.
• Whether solution checker runs as a pipeline gate and at what severity it fails the build.

Gotchas

• Committing only happens on publish. A maker who saves without publishing thinks their work is in source control and it isn't.
• Merge conflicts under \Connections, \DataSources, \pkgs or CanvasManifest.json aren't safe to merge. Conflicts in .fx.yaml and .pa.yaml are fine; those four aren't.
• Two makers inserting a button in separate sessions both get Button1, and the tool won't accept duplicate control names. Naming controls immediately avoids a merge that can't be resolved.
• Editing YAML for an app containing PCF components breaks the app with no obvious warning at edit time.
• The Build Tools client secret is displayed once. Losing it means creating a new one and updating every service connection.
• Storing a compiled plug-in DLL and its source in the same repository leads to the two drifting apart, and the drift is invisible until a deployment behaves unexpectedly.

Consultant notes

• Set expectations about what a canvas app diff is worth. YAML is readable, but reviewing a screen's worth of layout changes in a pull request is not the same experience as reviewing C#. Sell it as history and recovery first, code review second.
• Push back gently on clients who want full Azure DevOps because it sounds more professional. Git integration plus pipelines covers most low-code estates with a fraction of the maintenance, and you can add DevOps later.
• The deprecation of pac canvas pack/unpack matters if you're inheriting an estate — plenty of existing pipelines are built on it. Flag the migration to Git integration as a piece of work rather than letting it surface as a broken build.
• Get the service principal created by the client's own admin, with the secret going straight into their key store. Handling it yourself creates an offboarding problem nobody wants to own.

---

Worth revisiting if Git integration extends beyond Azure DevOps repositories, or after the next Build Tools major version.