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...
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.
