user data function with source control behavior

You see a commit on main because the UDF’s connection binding changes when you switch from the feature branch lakehouse to the main branch lakehouse. That binding lives in the UDF’s serialized metadata in Git, so Fabric records a diff and asks for a commit. This is expected for items with external connections, while items without connections do not create this extra diff. Microsoft’s docs confirm UDFs store and version their connections, and lakehouses have tracked logical identifiers in Git. 

What to check

1. In the repo, inspect the PR or latest commit for the UDF folder. Look for a connections or settings file where only a connectionId or logicalGuid changed.

2. Confirm the lakehouse in the feature branch and main branch resolves to different workspace-scoped connection IDs, even if the display name matches.

Why this happens
• Connections are workspace scoped.
• Branching to a new workspace gives the lakehouse a different bound ID.
• When you update main, Fabric rebinds the UDF to main’s lakehouse connection and writes that change to Git, creating the commit.

Ways to avoid surprise commits
• Keep connection names consistent across branch workspaces and let Fabric rebind silently, then accept the one-time commit on main. Future cycles tend to be clean if bindings remain stable.
• If isolation is not required, avoid creating a separate lakehouse per feature branch. Use one lakehouse with the same logical guid across branches or move isolation to tables or folders.
• Make code-only changes in the feature branch, and create or rebind the connection only after merging into the main branch. This removes the connection diff from the feature PR.
• For stricter ALM, pair Git branches to separate workspaces and treat connection rebinding as a deliberate step in your pipeline. Document it in your branching guide.