Respect .gitignore in workspace sync

[Jeff_brown_hso]

Currently the .gitignore file is, well, ignored. Ideally we would have a way of using gitignore to avoid committing local developer objects e.g. sandbox lakehouses that developers use for testing out different load patterns.

[DanielSDavis]

This is so critical. We have things all the time that we want to keep in one workspace that isn't part of the push to github. Also it'd be useful to use so we can turn OFF behavior. .schedule files come to mind. I don't my nightly loads in Production running every night in development branches, but if I delete the schedule it just recreates it.

[YevgenyM]

Agree. really needed. To avoid committing local developer objects

[RobSewell]

This is really important to ensure that seasoned developers do not make mistakes and think that the .gitignore file will stop their scratch pads, notes, test files, or worse case secrets being synced to the remote repository

[Stolt_Data]

This is source control 101

[merrillaldrich]

Absolutely required!

[rabinjais7]

this is must. i want to keep my ms fabric git source control tab without any red marks. it makes confusing for new developers. i just want a space in workspace where people can create their notebooks, pipeline and do their work untill its finished and these should not be tracked in git ui and it should not be committed too.

[CraigRG]

Fabric git is clunky enough. How do you not respect .gitignore? seems pretty simple.

[DanielSDavis]

@CraigRG, Nailed it. .schedules was the biggest thing we ran into lately, by .py files are a nightmare too. With schedules if you create your schedules in a lower branch as "inactive" when you git-push to higher branches they are still inactive. If you change their status in higher branches (like production) they register as changes and affect future pulls to your lower branches. Add to that the fact that we (like most seasoned developers) have protected branches, when our production branch adds a .schedules file that isn't in the repo it flags the workspace as in an unsynced state, which we can't push back to github. We implemented a workaround by using a yaml file for the schedules and dynamically building the .schedule file as part of our PR process (github actions). Even that was a pain because when it lands in Fabric, they take the ingestion then rebuild the file. CRLF endings in JSON were different than in github so it was changing the files. The same thing happens with Notebooks. The are converted to and from a .py file into a .ipynb file and stored as a base64 string, so every single time you try to sync your branch character interpolation happens. You have to become an expert in character encoding, github action scripts, and the Fabric API to work around all the nuance. Just insane.