How lakehouses are differentiated when working with Git enabled workspaces?

[sgbadvity]

I am trying to understand how the Git branches are useful when a Notebook code changes need to be merged to base workspace from private workspaces. 

Let's say, I have a base workspace where a Lakehouse(lh_bronze) is created and included a file with datatype schema info of source tables. 

When I create a feature branch on top of the base branch, will I have access to the schemas file from my private workspace? 

What happens if I create a new Lakehouse with same name(lh_bronze) in my private workspace and create a new table in it? Will it reflect in base branch lake house after the feature branch changes merged to base branch through a pull request?

[spencer_sa · Accepted solution]

Certainly with DevOps git, when you have a lakehouse in source control you literally get a stub entry with the metadata for the lakehouse and nothing about the  data within it - including table or schema definitions.
If your schema file is in a lakehouse, it will not be in Git (DevOps), and will therefore not be brought into a feature branch.
If your schema file is however a notebook that defines the tables (akin to a DDL/DML SQL script), then this will be kept within Git.  You may wish to be careful about how you define the lakehouse/default lakehouse in this case to ensure that you don't end up creating tables in a lakehouse you're not expecting.

"What happens if I create a new Lakehouse with same name(lh_bronze) in my private workspace and create a new table in it? Will it reflect in base branch lake house after the feature branch changes merged to base branch through a pull request?"

Nope - as above, table structures, table data, and lakehouse files are currently not moved with pull requests.

The way we are thinking doing this is having the table schema creates as notebooks, using a script to repoint the default lakehouses, and having explicit workspace->workspace copy processes.