What it does

Two routes to getting solutions into Git. Unpack an exported solution zip into files and commit those, or use native Git integration in Power Apps, which syncs solutions between a Dataverse environment and an Azure DevOps Git repository from inside the maker experience.

Key facts

• Two file formats. XML is the legacy one — Other\Solution.xml plus Other\Customizations.xml, verbose diffs, no multi-solution repos, no canvas apps, no modern flows. YAML is the current one, compact, minimal diffs, supports multiple solutions in one folder, canvas app .msapp files and modern flows.
• Native Git integration always writes YAML. There's no option.
• If you want to pack or unpack that source manually with SolutionPackager or pac solution pack, the folder has to follow the YAML structure.
• SolutionPackager is no longer the recommended tool. Its capabilities are in the Power Platform CLI under pac solution — unpack, pack, clone, sync.
• Native Git integration is for developer environments. Test and production get managed solutions built from source and deployed by pipelines, not by syncing.
• Solutions in source control come from unmanaged solutions in a maker's environment. Managed solutions are built from source and deployed downstream.
• With YAML, solution objects aren't duplicated per solution — they're stored once and shared across solutions in the same repository and folder.
• Unpacking doesn't overwrite files whose contents are identical, and it honours the read-only attribute, so only genuinely changed files get checked out. /clobber overrides that; /allowWrite shows you the impact without writing anything.
• Manual editing of extracted component files isn't supported, other than the specific sections covered by the "when to edit the customizations file" guidance.
• Committing code-first objects deployed directly into a maker environment stores only the compiled artifact — the plug-in DLL, the bundled JavaScript — so you end up with the binary and the source both in the repo. Microsoft's recommendation is to build code-first objects through a solution build process and import the resulting unmanaged solution instead.

When to use / skip

Native Git integration is the right starting point for most clients now. It's a few steps to enable, makers can use it without learning the CLI, and it puts source control in front of the people who were previously treating the dev environment as the source of truth. Use CLI-based unpack and pack when you already have a pipeline, when you need control over the build, or when the repo predates YAML. What you shouldn't do is run both against the same solution and hope they agree. And be clear with the client about scope: this is developer environment tooling. If someone proposes syncing production to Git, that's a misunderstanding of what it's for.

Configuration decisions

• YAML or XML. For anything new, YAML — the XML format only makes sense for repositories that already use it or tooling that can't read YAML.
• Native Git integration versus CLI-driven unpack in a pipeline, decided by who does the committing and whether you need a custom build.
• Which files go into source control, since not every extracted file should — the solution component file reference tells you which.
• How code-first objects get in: built through the solution build process (recommended) or deployed straight into the maker environment (convenient, and it duplicates the artifact).
• Whether dev environments are long-lived or rehydrated from source, which is one of the real payoffs of having source as the source of truth.

Gotchas

• Picking XML now and migrating later means restructuring the repository. Choose the format up front.
• Two developers editing the same view means a genuine merge conflict in a single file, and Git can't resolve solution XML or YAML semantics for you. The fix is human — talk, agree, re-export, overwrite.
• Order matters when reconciling. Export and extract before you make further customisations in the dev environment, and get latest before you submit, or you'll overwrite someone.
• Binaries and source both ending up in the repo is easy to do and confusing to unpick. It happens the moment someone drops a plug-in assembly straight into an unmanaged solution.
• pac solution unpack, clone and sync don't currently support the YAML format the way pack does. Check before you build a pipeline around a specific verb.

Consultant notes

• Turning on native Git integration is the cheapest ALM improvement available for a client whose source of truth is currently "the dev environment". Do it early and the rest of the conversation gets easier.
• Set the expectation that source control does not remove the need to talk to each other. Decomposition into separate files means non-conflicting changes merge cleanly; two people editing the same form still need a conversation.
• Get the fusion team's build process agreed before the first plug-in lands. Retrofitting the build-then-import pattern after six months of direct deployments means cleaning duplicated artifacts out of history.
• Short-lived dev environments are the underrated benefit. Once source is authoritative you can spin an environment up, work, and throw it away — which solves storage pressure and stale-environment problems at the same time.

---

Revisit when the CLI's unpack, clone and sync verbs pick up full YAML support.