Source Control / Git Integration - Naming conflict and ID persistence after renaming items

[AntoineW]

Hello Community,

I am encountering a synchronization issue with Microsoft Fabric Source Control (GitHub integration) regarding item renaming.

Scenario:

1. I created a Dataflow Gen2 named Dataflow1.

2. I created a second Dataflow (initially Dataflow2).

3. I renamed Dataflow1 to Dataflow1_test.

4. I renamed the second Dataflow to Dataflow1.

Issue: When committing to GitHub, the folder structure does not reflect these changes correctly:

• The original Dataflow (now Dataflow1_test in the UI) still appears as Dataflow1 in the Git repository.

• The new Dataflow (now Dataflow1 in the UI) was committed with a folder name containing a random unique identifier that doesn't match the expected name.

It seems the Git integration is prioritising the initial internal ID or the 'Logical Name' created at birth rather than the updated 'Display Name'.

Questions:

• Is this a known limitation of the current Fabric Git integration?

• Is there a way to force the repository to sync the Folder Names with the UI Display Names?

• How can we safely manage "name swapping" without breaking the link between Fabric and GitHub?"

Thank you in advance 🙂

[deborshi_nag · Accepted solution]

Hello @AntoineW 

This has been raised in the past on a post in the forum. Here's the link. 

Solved: Re: GIT integration: azure devop - fabric - Microsoft Fabric Community

This is not a limitation, but a behavior with Fabric and GIT integration. It relates to this - 

When you save a new item in Git, Git integration automatically creates a directory for that item. Once created, Git integration never changes the name of a directory. Even if you change the name of the item, the directory name stays the same.

Git source code format - Microsoft Fabric | Microsoft Learn

The workaround for this is in the original post - 

“Save As → Commit → delete old → Commit”

[v-ssriganesh]

Hello @AntoineW,

We hope you're doing well. Could you please confirm whether your issue has been resolved or if you're still facing challenges? Your update will be valuable to the community and may assist others with similar concerns.

Thank you.

[v-ssriganesh]

Hi @AntoineW,

Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks to @cengizhanarslan & @deborshi_nag for sharing valuable insights.

Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.

Thank you for being part of the Microsoft Fabric Community.

[cengizhanarslan · Accepted solution]

Every Fabric item (Dataflow Gen2, Lakehouse, etc.) gets a stable internal ID at creation time. Renaming in the UI only changes the display name, not the underlying identity. When you later create another item and give it the old name, Fabric avoids a collision in Git by materializing it with a generated identifier instead of renaming existing folders. As far as I know the only way is to create the new item with the final desired name --> Commit it --> Delete the old item and its Git folder in a controlled change.

[deborshi_nag · Accepted solution]

Hello @AntoineW 

This has been raised in the past on a post in the forum. Here's the link. 

Solved: Re: GIT integration: azure devop - fabric - Microsoft Fabric Community

This is not a limitation, but a behavior with Fabric and GIT integration. It relates to this - 

When you save a new item in Git, Git integration automatically creates a directory for that item. Once created, Git integration never changes the name of a directory. Even if you change the name of the item, the directory name stays the same.

Git source code format - Microsoft Fabric | Microsoft Learn

The workaround for this is in the original post - 

“Save As → Commit → delete old → Commit”