Source Control in BI: Necessary, Painful, or Both? – Ep. 475

Source control in BI is necessary, painful, and—for many teams—still aspirational. Mike and Tommy dig into the practical challenges of git workflows for Power BI and Fabric, from branching strategies and merge conflicts to TMDL formatting and Tabular Editor’s save-to-folder patterns.

News & Announcements

• Microsoft SQL Community Conference Announced — Microsoft announces a combined SQL + Fabric community conference, signaling the convergence of the SQL and Fabric ecosystems.

Main Discussion: Source Control for BI

Why It’s Hard

BI artifacts weren’t designed for git:

• Binary formats (PBIX) don’t diff or merge
• TMDL/PBIR are newer text-based formats but still have learning curves
• BI developers often come from Excel/SQL backgrounds, not software engineering
• Merge conflicts in model definitions can be confusing and risky

The Tools Landscape

Mike and Tommy walk through the current options:

• Git + TMDL — Microsoft’s text-based format for tabular models. Clean diffs, human-readable, but requires adoption of new tooling
• Tabular Editor Save-to-Folder — Splits model definitions into individual files for better git tracking. The parallel development docs are essential reading
• PBIR (Power BI Report format) — Text-based report definitions that work with git
• Fabric Git Integration — Connects workspaces to repos, but has its own quirks around branching and sync

Branching Strategies

They discuss how traditional git branching (feature branches, main, release) maps to BI work:

• Feature branches work well for isolated measure or table changes
• Merge conflicts are most painful around shared model metadata
• Code review for DAX and model changes is valuable but culturally unfamiliar to many BI teams

Practical Advice

• Start with TMDL or save-to-folder before attempting full git workflows
• Use Tabular Editor as the bridge between BI-friendly interfaces and git-friendly file formats
• Don’t skip branching basics — understand merge, rebase, and conflict resolution before adopting Fabric git integration
• Small, frequent commits reduce merge conflict pain dramatically

Looking Forward

Source control adoption in BI is accelerating—driven by Fabric’s git integration and the PBIR/TMDL formats. Teams that invest in these workflows now will have a significant advantage as semantic models become critical infrastructure for AI and cross-platform analytics.

Episode Transcript

Full verbatim transcript — click any timestamp to jump to that moment:

0:00 Morning and welcome back to the explicit measures podcast with Tommy and Mike. Hello everyone and good morning. Good morning Mike. Happy Tuesday.

0:33 It is a Tuesday. how are you doing Tommy these days? what? I’m doing pretty good. Feel a little older. It’s just another day. did you ever listen to They Might Be Giants? They Might Be Giants. This is a podcast or is it a movie? That was a band. I feel like that’s right up your alley, too. They Might Be Giants. I don’t know what What genre is this fitting in? I I don’t Oh, sorry about that. I had to take something on the keyboard. Not that genre. Not that genre. Not that music. I guess it was indie, but they were humorous. Like, so if

1:06 You ever watch Tiny Tunes or Malcolm in the Middle, they the ones who did the theme song to Malcolm in the Middle. Yeah. Yeah. So, but one of their songs is you’re getting even older now. And now you’re even older. And it’s probably the best. No. Anyways, I just feel older today. Okay. Okay, let me write let me write this name down, Tommy. So, I’m going to go listen to this and then I can react to it later. What’s the name of it again? They might be Giants. They Might Be Giants. Okay, putting that down so I can figure out if I like it or not. Okay. Never heard of

1:38 Them. Not sure about that song, but I will check them out. I do like funny music. I do like I actually, to be honest, most of my day is probably consuming music. , most of I’m sitting on my computer. When I’m not on a call, I have some music or something running in my ears. Is that what you do, Tom? Do you listen to music throughout the day? Does that help you focus or not? Talk radio, sports podcast, something that’s just doesn’t matter because if I like the song, then I get into it. , what music do you listen to? Everything. I listen to a lot of things. Most of my stuff is the EDM electronic dance music, preferably without any

2:12 Lyrics. I don’t know how you can do any work with someone talking in in the background and focus on anything. As soon as someone talks, my mind instantly goes towards thinking about what they’re talking about and I can’t really focus. incredibly easy. Well, yeah, I can’t do what you’re doing. My brain does not work that way. Well, let me ask let me ask a question here. So, let’s get into our main topic today. Today, our main topic is source control inside BI. Is it necessary? Is it painful? Or is it a little bit of both? maybe a bit of a rhetorical

2:45 Question there, but we’ll we’ll unpack this topic today. also with this, we have some news recently, just actually just yesterday, the announcement just came out. Microsoft Fabric is down in Atlanta. So we have the FabCon in Atlanta. We also now have a new conference showing up. The Microsoft SQL Community Conference is now also participating in Atlanta. So we’re going to have [clears throat] Fabcon and SQL Con all in the same area. So, , this is a post that was made by Arun talking about this new conference

3:19 And, , I just want to throw that out there and let people know that there’s a new conference coming down and we’ll hope to see you there for both these things. So, it’s the SQL community conference, not to be com , related with the SQL pass or SQL Saturdays, right? Oh, I don’t this is a Microsoft sponsored version of SQL. So this is SQL Server 2025 is what they’re talking about. It represents a fundamental shift in how they’ve been building SQL. It’s a huge reimagining of what they’re thinking SQL is doing with

3:52 Vector search, AI model management, rag patterns. all these other AI based things are now being added into the SQL space. And so they’re going to join up with the fabric community and have a whole bunch of additional people there at another conference. So this will be interesting. Tommy. , I have been to a conference in Atlanta a long time ago. There’s a huge convention center right next to their stadium downtown. , and yeah, easily you could have two conferences happening at the same time at this conference center. It’s just massive.

4:24 , also note here at the bottom of the article there’s a discount code. , if you get early access registration through November 14th, and I’ll put the code here in the chat window as well. You can get $200 off of your tickets if you register now sooner than later. Dude, that’s awesome. Do you think you’ll be going? Well, I’m going to FabCon, so that’s that’s happening. Whether or not they’re going to let me wander over to the area that is SQL Con, I don’t know. I don’t again, we’ve never had a conference where it’s been two big conferences together. I’m not

4:55 Sure how they’re doing them. Is it the same registration? Is it different? Not really sure how that’s going to all play out. So, interesting to see how that’s going to work. , yeah, interesting. We’ll be see see how all things all these this new experience plays out. I’m happy to have all the SQL people here. Tommy, do you do you use your SQL inside fabric today? Currently, oh yeah, I do the SQL database. I’m still upset that we can only do a sing up to three databases all the time. Is that is that because why is there a limit on that? Cuz the

5:28 Thing doesn’t charge you when it’s not running. I do not know. That’s interesting. H yeah, I would think you’d be able to do more especially. So I I one of the things when we first got this SQL database inside Fabric, I was trying to test it out and figure out how why would you put this here and I think over the course of a last couple months as I’ve been building things, Tommy, I’ve been doing a lot more marketing in general. So in marketing experience, like I’m just trying to figure where to put the data, where to put my list, my contact list, all this information.

5:59 The more I work with the marketing side of things, the more I’m disappointed with all the tools that are out there that do marketing related things. Mailchimp, there’s a lot of email services that are out there. They all seem to be like not really doing what I want. My workflow that I want doesn’t really have the tools out there today don’t seem to fit my workflow very well. And so I’m trying to get my head around like how do I build this? What workflow should I be producing? What tools can integrate together? And at the end of the day, I keep going back to whatever tool we stand up, doesn’t

6:32 Matter what it is. I want all the data to come back to fabric. I want it to be in somewhere. And so to me, when I look at like SQL, a SQL server, this makes a lot of sense to put the SQL server inside fabric and then connect any applications or things you build back down to the SQL server cuz now you have full SQL tables, a transactional database inside fabric running as if you would have it in Azure or somewhere else. And it makes it really easy to mirror that data into a lakehouse. You can get all the other transactions. So it makes it removes I

7:04 Think a lot of friction between the transactional side of things and then the operational side of things. I think it does come with some implications but I’m excited seeing the the database world coming more into fabric. I think there’s a lot of opportunity there. What do you think Tommy? No I I completely agree and I think when the SQL databases first came out I know you were a little hesitant that we had lakeouses but I was yeah but honestly and data warehouses for that matter. Like if you’re doing SQL I would say use a data warehouse. like why would you need a SQL database? But sometimes you just need a app that runs

7:37 On top of a database. Well, that fits very well for SQL. No, and I think that’s the biggest thing is it’s the fact are there better ways from the analytical point of view to pro get your data through. Absolutely. Now, however, this database still has a its place in terms from querying from access for users. But again to your point from the application side of things that alone is makes it well more than worthwhile. Yeah, I I like and again I think maybe my strongest point for like why you would want to consider bringing SQL into fabric. I love the idea of how quickly

8:10 It ties back to other fabric related integration pieces. Like if I need mirroring, it’s right there. It just works. Like there’s a lot of things there’s a lot of features of it that make it easy for me to then do the reporting of the data as well as all the transactional side of data which I really like. Thousand% dude I love it and I’m so glad there’s entire conferences related to SQL and there’s SQL bits and obviously those conferences are they’re more than just SQL but the fact that SQL is still in the name tells me

8:42 Everything I need to know. We went to the SQL bits a while ago, Tommy, and I felt like it was it had some flavor of SQL to it, but I felt like SQL bits had moved a lot more towards a fabric bent and and mentality, a lot more around what fabric is doing or PowerBI is doing in SQL Bits. It’s interesting now seeing, , I would allude to fabric conferences, a lot of fabric related things, and now we’re having we’re now adding back in the flavor of SQL back into everything. So, anyways, just really interesting. ,

9:17 Good stuff. I’m excited to see the conference. I’m gonna be I’ll be interested to see how this is going to play out. Anyways, any other news or worthy items? Tommy, do you have any like beat from the streets you want to talk about? No. I was trying to see if there’s any news on the blogs, but nothing terribly new. So, yeah, this is the one I pulled this one from the fabric blog on this one. So, that’s why I pulled this one in. There was really nothing on the PowerBI blog coming out there as well. All right, with that being said, let’s get into our main topic today. We have another call in today. So, ,

9:49 Another call-in today. Welcome, Greg, as our call-in for today. We’re going to talk more about, , source control and unpack things here. So, let’s let me give a quick little introduction here around some things that are source control. I’m sure this conversation will wander many different places. source control inside Microsoft PowerBI fabric experiences. What do we get from source control? my background has been from day one of PowerBI the very beginning. And I

10:22 Remember at the very beginning it was source control was shoving all your PBX files into SharePoint and saving them somewhere. So you had a version of when when Michael screwed up the report page and Tommy made an update on something. I could at least go back and find what changes I had previously. So, , the very simple form is like where you back up things, where do you put things and and move things. Since then, we now have a lot more interesting tools at our disposal. We now have a git integration. We now have the PBIP format, which I

10:54 Think is a great enabler of breaking apart the the file format of the semantic model and the report side now. So everything now seems to be able to be controlled into these smaller files which I think adds a lot of capability to the source control story. now Tommy can work on page one, I can work on page two, Greg can work in the semantic model and everyone can get their changes brought together into a single object that we can publish to the service which is interesting. So I’ll just pause right there. Greg, welcome. What are your thoughts on the

11:27 Initial concept here around source control? Yeah, thank you. I’m a longtime listener and third time caller. I’m really happy to join you guys here. [laughter] , I think source control opens the door to a lot of other conversations. things that people think about when they think about source control, but that aren’t actually source control. So to me, source control is any system that you use to manage multiple different versions of the source code for some project that you’re working on, some software, some report, some model. where you keep the thing that defines

12:02 Those things that you’re working on and it’s different than other conversations but associated with it like you mentioned SharePoint and the early days. Yeah. Yeah. You and or one drive would do the same where you could keep a version history. Yeah. Yeah, and I think I think there is there’s a crossover there, but a version history is a little bit different than source control because a version history really only lets you have a linear set of changes. You have version one, then comes version two, then comes version three, and you need to make sure that

12:34 You put things in there in order. whereas I think source control, a system to manage multiple versions, doesn’t need to restrict you to just that linear history. And so I think the thing that makes the the big difference and when we’re talking about source control and not just backups and not just history is the ability to manage concurrent development. And so I think concurrency is something that’s really important to talk about. And concurrency doesn’t necessarily mean that you’ve got multiple people. You can be concurrent with yourself very easily. Concurrency simply means that you have interled

13:07 Processes of development. And so to be concurrent with yourself, you might be working on a feature and then in the middle of it, like you’re halfway through writing the code for it, someone finds a bug in production and you need to pause your work on that feature development, even though you’re halfway done, you need to go and you need to fix the bug in production to get the model refreshing again. And that might require some changes in order to fix whatever bug has arisen. And so immediately at that point, even though you’re one person, you’ve got a feature in flight that you’ve stopped. you’re not done with, but it you’ve done some work.

13:39 That’s one version. You’ve got the version in production, and then you’ve got the version that you need to edit based on what’s in production to fix whatever bug has arisen. Then you push the change to fix the bug. Now you’ve got a different version in production than where you started from when you started on your feature, but you go back to your feature and you finish the work on that. And then you want to get that into production as well. And so concurrent development I think is really what we need to think about when we’re thinking about source control and then we want to talk about the things that are necessary to support that concurrent

14:11 Development some of the implications of it and also tooling that goes along with and helps it. I like the term you’re using there, concurrent development. I I think and again I’m I’m looking at this lens of like how did I learn about this stuff? Like I started from the PowerBI world back in the early days and I didn’t think about anything concurrently, right? part of being able to do concurrent development depends on can I build small pieces of a single larger project, right? So I think there’s a dependency there that we didn’t really have in the very

14:43 Beginning. It was very difficult for us to take a single PowerBI file, PBX file, and divide it across a team. Also, Greg, I think to your point here, the concurrent development makes a lot of sense when we start talking about a team of people working together on things. I I like your your example there, I think, of fixing something in production while having a new report feature or semantic model feature in flight is a great example of when you need to go make some changes to some source code, push them out, fix things, and then take

15:16 Your feature branch or the things that you’re building that’s different or new, absorb those changes into your feature branch, and then continue on developing. So I think this this problem gets very much exacerbated when you have multiple developers trying to work in a team. If you’re just one person, okay, you can manage it like you can get around it a little bit. it I agree concurrency with yourself is a solid point but I don’t know like if we’re coming from the PowerBI world and bringing them to fabric now I don’t think there’s a

15:49 Lot of initial PowerBI developers thinking about how could I concurrently develop stuff like this is a new this is like a very software development experience that’s being brought to a less I would say less technical less it’s less everything has been like easy buttons right the whole the whole goal with fabric and things has been it’s a a UI it’s a guey it’s something simple there and now you’re bringing this really technical software development technique into PowerBI which I think is appropriate especially on

16:22 Larger teams or when things get bigger I I I agree with this but I I think it’s another we have to start educating more in the space and preaching the reasons it’s not scary you can do it And it they’re add there’s a lot of value added from this this idea here. Tommy, I’m you have something to say. So this is all only dependent on the fact that we actually have Timol now, right? Because even though before we did have the model.bim BIM file and we there are some things you could do

16:54 In Tableau editor. Source control was not really a production or a preferred way to really even manage PowerBI content and artifacts before you could you could have but it really didn’t make sense. And tell me if I’m wrong about that. I don’t think you’re wrong Tommy. I would just maybe extend your definition slightly from my perspective. Right. before Microsoft gave us the capability to use timal which is the semantic model

17:27 Easy to humanly read version of this and then there’s the PBIP format or the PBI format the PBI format is like the same thing but just for the report side right so take taking a single PBX file and dividing it into like okay let’s talk about the definition of this page let’s talk about the definition of this visual when you break those things down into individual files that’s where The strength of this source control and concurrent development makes a lot of sense I think. , and to be very clear, the first time I ever saw this was

18:00 Tabular editor. Tabular editor 2 was the very first time I saw anything of this nature. Now, it wasn’t tim at the time. It was all still just JSON, but tabular editor 2 when I saw it would open up a PBX file or you could connect to the semantic model. You could serialize. You could basically save to files or save to folder the entire model and then the whole model would be broken down into here’s the measures, here’s a table, here’s the other properties of the model, everything was broken down into

18:31 Smaller files and and then I could and the trick of this was yes, once you take a mantic model and break it down to small files. Okay, cool. But you have to put them back together and then put it back into the PowerBI report to make sure that it could all be read and rebuilt again. So my first experience with the source control stuff and seeing things serialized out and back in was tabulator editor 2. So I think there are a couple of things that have come up there that I’d like to

19:02 Respond to. The first is on the idea of source control as a new concept for a lot of people coming into PowerBI and coming into fabric. And I don’t think the concept is new. I think some of the terminology that we use from a software engineering and development perspective, the terminology itself is new. I think some of the tools are definitely new. Git is not something that most people use with Word or Excel, but the the idea is very common and I think everyone is very familiar with seeing copies of documents float around. , this is the report final final

19:36 Final final final underscore really this time. [laughter] And so people are well everyone I think that has worked in any organization and had to deal with a document of any sort or an artifact of any sort and also other people is familiar with underscorefinal double underscore really final and that thing which is [clears throat] at the end of the day that naming convention for files is a system to manage versions of a thing. So it is

20:09 Source control. It’s rudimentary. It’s not often called source control. So, the terminology is new, but the idea of I have different versions of this thing and I want to be able to look at both of them and see what changed or I want to be able to go back to an older version and I might want to be able to pick and choose from multiple different edits. , I I think that’s a very familiar experience. So, it’s just about educating on ideas on not ideas on techniques, tools, and jargon, but not necessarily on the idea itself of source control. Yeah, I like that. The the second thing both of you

20:42 Brought up was, , back in the the older days of just a PBX file, and that’s the only file we had in PowerBI. That does make source control very very hard be for a couple of reasons. One is that the PBX was opaque. It was a binary file, so you couldn’t open it up in a text editor and actually see what had changed in any meaningful way. You could unzip it and then poke around inside, but that wasn’t supported. And there was not really a lot of good tooling for doing something like that. Then the other side of it is the idea of a monolithic file which is

21:15 Different from an opaque file. So the PBX was opaque. You couldn’t look at it and see what was in it. You had to open it in PowerBI desktop. But a monolithic file is something like the model.b where you have one file that represents a whole lot of different things, one big file. And so one of the things that we get in a source control system is the ability to show multiple different versions and to perform a diff operation. And a diff is an action that you take to see the differences to highlight just those things that differ

21:48 Between two different versions that are in the source control system. If you were using, , underscorefinal and underscore doublefal, then the way that you would diff is with your old eyeballs and you would just look at the two of them and try to find the differences. If you’re using a tool like Impossible, [laughter] yeah, if you’re using a tool like git, you’ve got the command get diff, which does this action for you and shows you just those parts that are different. And you can also [clears throat] get summary statistics out of it. So you can say which files have differences or how many changes are there between

22:20 Two versions and two files or how many changes are there between many files in these two different versions. But if you have a single file, if you have a monolithic file like model.b or like the pbixx file, then your history of changes just says something changed in this file. And then the next change is something changed in the same file. and your next edit is something changed in that very same file again. So if you look at the history of changes, the file names don’t tell you anything and that becomes a

22:52 Little bit problematic and this is where timal is useful. This is where the save to folder feature that’s used by tabular editor and also some other community tools like PBI tools is very useful. What it does is it starts to break apart that monolith into multiple different pieces. And as soon as you have multiple different files, then your source control system is tracking files. It’s always tracking files, but if you have many files, then you see more granular changes. And so with Timle, you end up with a file per table. And so you can edit one table and Tommy

23:27 Can edit another table and I can edit a third. And then we’ll see Mike edited table one. Tommy edited the customers table and Greg edited the sales table. So, we’ve got three different things that have changed, but we don’t know what we changed in them. , , Mike, you might have been editing measures that belong to the measures table, and Tommy could have been editing husk details that are in the customers table. , so he could have been adding columns or changing columns and column names, and I could have been editing partitions in the sales table. All of those are things that are changes to the table, but they’re very, very different changes. And if the file that you have

24:00 Is per table, there’s nothing at the source control layer to tell you who was doing what. And that’s where this is chronologically out of order. But in terms of the ideas, this is going one step further. The save to folder feature that’s in tabular editor and used by PBI tools takes you down to a file per object. And so a column is an object. A measure is an object. a relationship can be its own object or could be part of the table depending on how you want to serialize these things. But then you were in the measures table and you were editing

24:33 Measures. If you have a file per measure, we’ll see that Mike edited not just the measures table, but he edited measure one and measure two but not measure three. And then we see that Tommy was editing the customers table. And we see that he was editing things that are in the columns folder. And he was editing a thing named customer name. and customer name went away, but customer first name appeared and customer last name appeared. And so you can see just at the level of the files that Tommy was making those changes to some columns. And then you look at the changes I’m making to partitions and you

25:05 See that there’s a folder for partitions and you see that the partition definitions are changing. Maybe I’m updating the incremental refresh policy or I’m changing the time periods that we use going from a partition per quarter to a partition per month. And you would be able to see at the level of the files that Mike was changing files that lived in the measures folder, Tommy was changing files that lived in the columns folder, and Greg was changing files that live in the partitions folder. And the more granular your files are, the more information the source control system can tell you because source control systems are agnostic to what is in the

25:37 Files. They are just saying, , there’s a version of this file and here’s a different version of the file. They give you tools to work with that. But for the most part, the information that you get out of source control systems is about changes to files. And so that granularity is also very very useful in being able to work with these things and understand in terms that the source control system can deal with to understand what those changes are. All right, I’m going to I was taking copious notes while we’re talking through all those pieces here. So, , one of the things I think two pieces, I

26:10 Think Tommy, you touched on this one as well, and I’m going to want to just reiterate this again. I think the main unlock for us here has been the PBX file that we have been using since the beginning has now been changed into a format that is now easier to leverage and use. and the the fact that things were pre like pools were able to open that file up, unzip it, serialize things, take them apart basically and and stitch them back together and you were able to do that in an

26:41 Unsanctioned way. So there was you could do it but micros Microsoft would basically say look if you if something fails and it’s just totally broken after you do this not our responsibility we’re not supporting it. I think for me the big moment or shift around working with PowerBI and fabric is now that that experience has shifted. Microsoft now says look we are going to update our formats of underneath what’s inside the PBX and we will now start supporting small files of definition of objects.

27:17 And to me that was like the unlock moment where everything in my world is like yeah this is changing like this is this is next level stuff. This is where we should have been at the very beginning day one but there it’s it was definitely a opportunity of they’re just trying to get out the door. It was just getting built to get done and get people adopting the tool and moving quickly and fast and iterate quickly. There wasn’t this whole thinking of well let’s build this new online visualization tool called PowerBI and let’s think about how everyone will edit page one versus P. There wasn’t this it wasn’t really well

27:50 Thought out I think in the beginning. Well, it was but it wasn’t designed for like developers to co-edit files and things. So what we’ve seen though is a growing up effect or a maturing of the solution that I that I’m really happy with now which is really the unlock here. So that was like my one point. Then I want to make one other side point that you’re talking about Greg. While I think in in principle it’s easy to understand many people working on different things inside an object, a report, a semantic model, one of the things I feel like that gets people

28:22 Tripped up very quickly in this is when Greg you’re editing partitions and Tommy also goes in and edits partitions. And we have these things called the merge conflict. Like when two people edit the same file and again it it makes a lot of logical sense if you just think about it right if you’re everything inside your PBX file is broken down into small tiny files right again I go back to the analogy of like page one right so if we’re on page one and Tommy edits page one but Greg you edit page two no issue

28:55 Like we know that there’s separate files two things that have been modified differently and not an issue but if you’re both editing page one right if you’re both redefining things on the same object. Again, I’m I’m paintbrushing or spreading a very weird analogy here because it’s we can get a little bit more detailed than that, too. But if you’re both editing the same thing, okay, how do which change wins? And I think this is the very outside of that. That’s the first part where most new users get tripped up is how do we handle this idea of what is

29:28 A merge conflict? How do we how do we resolve this? what are good ways of using the tools that we’re given git the the tooling that’s exist diffs and things to understand which one should we change and most often new users just say ah I can’t figure out I’ll just delete all my changes start over and then make my changes again so I don’t necessarily think that’s the best option but as I think about this that’s where I see the first point of

30:01 Friction in this face as I observe it. Your thoughts, Tommy? And I I think the biggest thing here, too, is we only have Tim and as I’m looking at this. Well, [clears throat] hold on. Yeah. Yeah. What do you mean we only have Tindle? Well, right. Okay. You’re right, Becca. From a semantic model point of view, we No, I understand. Okay, I’m with you. Because obviously with and honestly, most of the conversation, Mike, that we’ve had around Git has really been around Tim. has not been around the other fabric artifacts that even though

30:35 They they produce files and not binary data flows notebooks they all produce files. You’re going there. Okay. it’s true though we don’t talk about that at all because there’s really not those are not ones that even that the notebook format the way they have it is not just a IPM IP like notebook file format. It has a whole other context to it. , lake houses as well has files that it produces source control data flows too,

31:08 But we’re not touching those. And really, Tindle is the only one that’s actually meant for to make it an equivalent like a Python package or node where it’s like, okay, I can see all the different things that were done. It’s almost like creating a website compared to the other formats. Right now, we’re not really touching. h interest you bringing that up and I don’t think to be honest and I don’t find that to be a problem. I I don’t think that’s an an issue that we have. So but it is something to consider as well when we’re going to see

31:41 We do the full stack get right now. We’re just saying that we’re completely experienced from the tindle point of view. What what are your thoughts, Greg, on on So, again, I was focusing a lot of my conversation around Greg on the PowerBI report and the semantic model side. Tommy, you’re bringing up the whole everything in fabric side as well. My initial opinion here is it’s interesting that you’re bringing up the rest of fee tummy because yes, everything else, pipelines, other things are all defined by JSON behind the scenes, which again is a series of small

32:13 Files that can be edited or modified for definitions of things. , [snorts] what are your thoughts on this part, Greg? Like this I think this is Sorry, let me one one thought and then I’ll give I’ll kick it to you, Greg. I want to I feel like Tommy the the difference here is a lot of the other experiences that we’re getting are cloud created. It’s in the browser. Oh yeah. Right. So for me the big difference is like I don’t get a tool to build a data pipeline on my local machine. So for to some degree I feel it’s a bit simpler

32:45 For Microsoft to come up with schemas and repeatable patterns. And also a lot of these other tools come from traditional Azure envir Azure things that already have this whole rich history of deploying building a web browser to to get stuff ARM templates to deploy stuff. So all of that has to be defined in a way that can be easily deployed and updated as you go. And so all the other fabric items make sense to me that they’re already supporting versions or

33:19 Version source control of those items. All right, that’s all I want to say. Sorry, Greg, over to you. So I’ll I’ll start with a somewhat minor point in what you said was the ability to run things locally, which I think is absolutely critical to be able to develop things and use source control. Well, if you have to go somewhere else and make the changes and then the canonical source is not what you have but living somewhere else and then you get copies of it. Most of the workflows that are built around source control and any downstream things like CI/CD don’t really fit in that

33:53 Paradigm. So being able to develop locally I think is absolutely critical. But on the the broader question of being able to you were talking about being able to merge changes from different people’s work and I think that’s where again the serialization formats become very important. And so when we’re talking about this I think it’s again important to make sure we’re talking about the same things. So merging is the action that you want to take when you have two different versions and you want to bring those together. And those versions may have conflicting changes where two people

34:27 Edited the same file or they may not have conflicting changes where all of the changes are two different files. And this is a somewhat naive look at it, but it’s what is available to the source control system because Git doesn’t know what a tabular model is. Git doesn’t know what Python code is. Git doesn’t know what C# code is or what JSON is. Git knows about files and it knows about what lines are in a file and that’s it. And so Git is able to do actually a lot with that very rudimentary knowledge. it can merge changes to different parts of a file and it does a pretty good job

35:00 Of figuring out if you and I edited significantly different sections of the file and there aren’t too many changes. It can usually make a merge even within a single file pretty effectively. But it’s up to a bunch of heruristics and again it’s without understanding of what that file is. And so the the more files that we can break something apart into, the lower the surface area for a merge conflict is because again we can only have a merge conflict when multiple people touch the same file or multiple different branches have edited the same file. And so the more files you have to represent smaller things, the less

35:34 Surface area there is for a merge conflict. And so in that way the the best thing that you can do is to have the smallest possible representation the most files to represent the things because that means every change that you make is going to be in different places. And so that’s where the strength of timal is over the model.bim because timal has more files. So more surface area to make changes in different places. And saving to folder again gives you even more surface area. and you’d have to be changing the same measure or the very same column to end up with a merge conflict. And so there are a

36:07 Couple of different things that we want to optimize for because what happens when you get a merge conflict is you need to remediate it. you need to go in and change and say, , in this file we want these lines from the first person and these lines from the second person. And when you need to do that, you need to be able to edit the files by hand because what git does when you’re making those when you get a merge conflict, git inserts information into the file that basically makes it invalid. It’ll insert a bunch of angle brackets. It’ll tell you which branches two different sections came from. And that’s invalid timal. That’s

36:40 Invalid JSON. but it’s just get showing these lines were different. Here’s where the conflict is. Human, go figure it out. And so there are a couple of things that you need to do there. You need to be able to read that that conflict and decide which pieces that you want. And you need to be able to make sure that after resolving the conflict, you have a valid file. And so TIMDLE is really optimizing for being able to read that merge conflict and being able to edit that thing by hand. It is friendlier to the human eye than JSON is. But save to folder is optimizing in a

37:15 Different direction. saved to folder by being so granular virtually eliminates merge conflicts because it’s a very rare scenario where you would actually assign to two different people the same measure to edit like you wouldn’t give the give two tasks for the same measure at the same time or two tasks for the same column at the same time. So that’s not that’s got good not good practice there. Yeah. So saving to folder almost eliminates merge conflicts so you never even have to look at it. TIMDLE makes it easier to deal with the merge conflict when it happens. But by not going as far

37:49 Because right now TIMDLE only supports going down to a file per table. It doesn’t support going down to a file per object. if did that then you’d get the best of both worlds. You would have this very granular serialization that basically gets rid of merge conflicts. And on those super rare occasions where you get them, it would be friendlier to look at. But for me, and this is personal preference, I and it it’s not right or wrong to prefer something different, but for me, being able to nearly eliminate merge conflicts is more important than making them readable when they happen. H. So, this is where I I put my

38:25 Idea or thinking cap on here. And this is where I Does this make sense to have AIs and agents participating in some of these challenges that we have around merging of things? Is this is this where like, , if I’m looking at a diff between two files, yes, I can go see the exact diff of what’s going on there, right? Is this I haven’t seen my opinion. I haven’t seen anything yet. That doesn’t mean it doesn’t exist. It’s just I haven’t experienced it yet. But is this something where, , agents or agentic things would be really well served. It’s all code. I can see

39:00 What it was, what it’s now doing. , I don’t really want to be that technical expert figuring out how to merge or what’s the best choice here to merge things. What if what if we could throw some AI at some of this? Is this something, Greg, that we could throw something AI at it and it would solve some of these problems for newer users or you think that’s just like a misnomer or a fallacy? It’s it’s not a good idea to do that. Well, the first thing I’ll say is that AI isn’t pixie dust and you can’t just sprinkle it onto something and expect of course it is. I [laughter] just throw it everywhere. , , I tripped on some earlier this morning. [laughter]

39:34 You’re not handsome enough. Just throw some AI on it. Yeah, do good. You you’ll be much better. , , you’re too tired today. Just add AI. you’ll be not tired anymore. , you run out of coffee, throw AI at it. It’ll figure it [laughter] out. Like, who needs the coffee when you have powdered AI, right? [laughter] You’re right. It is like pixie dust. It’s not a solution for everything. But as far as What do you think? Yeah. Yeah. That said, if you have an agent that you work with that you’ve taught about and you’ve given context to about the serialization formats at play, what a valid model looks like,

40:08 Then yeah, there’s plenty of git merge and git command information in the training history of these models. for for better or worse, git has a somewhat confusing command line interface. So there are many questions on resources like Stack Overflow and elsewhere on other forums throughout the internet. So many people have asked questions and gotten, , very pedantic step-by-step answers and that’s ideal training data. So the the AIS are actually pretty decent at git commands and stuff like that. And they know, they’ve been trained on what

40:41 A git merge conflict marker looks like. So they can interpret that pretty well, but they can interpret the the merge conflict information much better than they can interpret the timal information because timal basically isn’t in any of the training data. Yes. Correct. And so getting getting good tindle out of an AI requires some prep work, but the AI LLM should be quite good at the git side of those things. And so if you’ve got an agent and you’ve got skills or tools or whichever name for that concept is where you’ve given context for specific

41:14 Actions to the AI if you’ve already got that to work with PowerBI models or semantic models in general then yeah an AI should probably be able to help with the the merging quite well. but it there is that prep work. , and if you just sprinkle the AI on top, it’ll tell you exactly what to do about the git changes and , it may or may not give you a valid model at the end of Yeah, that’s a problem with especially with the AI even if you use something like cursor or VS code that actually has code review. Heck, even right now with GitHub you can actually have Copilot

41:46 Like review your project before you do any pull requests. However, there’s a lot lot of context you need to give it. You can do custom instructions but it can’t just be like to to AI Tim is very very new and also it’s one thing to see whether it’s working or not but the thing is again Timul is one the semantic model side which is measures formulas syntax there’s

42:19 Custom there’s best practices that we could put in that AI is not going to do it’s only going to make sure nothing’s broken and then There’s the report side of the PBIR making sure things are aligned that it’s also probably not going to do as well which is what you need it to do. Usually that code review is there if it’s like hey a missing app script in some development code. So that’s one of the things we really want to watch out for as well. Yeah. Interesting. And the interplay there with the PBIR and other things is actually somewhere that I think an AI

42:52 With proper context and skills and tools actually could be quite helpful with because one of the limitations that I alluded to earlier is that Git is dealing at the level of files. Mh. And so having a clean merge is one thing. If Tommy’s working on the customer table, like I said, and he’s changing from a single customer name field to a customer first name and a customer last name field and I’m working on a measure in a different table, tindle or save to folder, both of those since we’re in different tables, will have a clean merge. The merge will succeed. Git will

43:25 Allow you to finish. a clean merge is necessary but not sufficient to give you a valid model at the end of it. So let’s say that the measure that I was working on, okay, that’s where I’m going to go. So like you got to tie back the the two columns from the one column. Yeah. Go ahead. Keep going. I like this. The measure. So let’s say that the measure I’m working on and remember Tommy changed from customer name to two columns. Customer first name and customer last name. And the measure I was working on was a distinct count of customer names. Mhm. Well, my distinct count of customer name might be referencing the old single name

43:58 Column. Yes. And the the correct way to do that distinct count now requires a summarize or a group by and a count rows of that rather than a distinct count of a single column. So the model has changed in a way that cleanly merges but still does not yield a valid model. And so you still have to have testing. You still have to have validation as part of your process whether you’re using source control or not. You should test and validate in some way. And , one of my favorite observations is

44:30 Everyone has a test environment whether they admit that or not. Just some people are lucky enough to also have a separate environment to have production in. So some people if you’re testing and validating in production that’s that’s fine, but production is your test environment and you need to make sure that you need to make sure that your changes are valid and Git is going to do nothing for you there. Git does not know what a model Correct. So here’s where I want to so we’ve talked a lot about a lot of like technical pieces around like merging and

45:03 Like all these different terms. So where do new let’s I want to take the lens here just slightly and say where do we suggest new users start? How do you get going with this? Like so okay let’s say conceptually someone listening to the podcast is like yeah I’m on I’m on board like this makes sense. I I hear what you’re saying. I understand the concept of small files track things. I’m bought in PBIR sounds great. Let’s do it. So your team or you individually, how do you start learning

45:37 To become good at this? How do you start incorporating this into your workflow? And so maybe maybe I could just ask just a general question both Tommy and Greg. Do you remember when you started working with Git? And Greg, you’ll have to put your big thinking cap on this one. This was probably like a long long time ago for you. , but mine’s probably not as long ago. But if you put your thinking cap on, what was it like for you to start understanding and learning git, branching, rebasing, merges, like all these terms we’re saying here. What was it like when you

46:09 Started figuring it out? I’m going to kick it here to Tommy first and then maybe we’ll hop over to Greg next. Tommy, what do you what was it like when you first learned it? So it was weird and I wasn’t really honestly I really wasn’t doing my own projects with git. I was mostly looking at GitHub repos and testing them out. So like cloning them. So learning some basics of just what’s in a repo. Okay, this got this because for example there’s a lot of repos for like hey awesome rules or docs or here’s some custom or custom commands but and I wanted to

46:43 Reference it sooner or later. Then actually Mike, when you recommended to me to put my contracts in markdown, well, it made a lot of sense to put that in a git repo. So then I can view it anywhere. So that was the first time that I actually started getting used to like, okay, I’m going to commit something now. Okay, what was the previous thing? Where’s that file? And then it it got obviously more when it came to PowerBI and working on other projects where it was the you doing everything in main accidentally did something. So I, , rightcicked

47:15 On something and said just revert it, but it doesn’t actually revert a commit and [laughter] and then all and then all the things and then you actually can’t commit something and then you get very frustrated. So yeah, I went through all that until really realizing like, okay, if I’m going to, , any change I have to make, it’s going to go into the branch and just having that process. But it took time to make some mistakes and then do some reading. But also just looking at a lot of other git repos and like I said seeing what they’re doing. Okay. love the points there Tommy. I can echo a lot of the same sentiment

47:49 That I was doing the way you’re experiencing it was how I was a lot. I’m going to GitHub. I’m pulling down a copy of some code and I’m I’m only building on main. [laughter] That was what I was doing. Not good. that’s how I started. I also found it very difficult to understand the branching and which things were happening where. So one of my first interactions with like git in general. I started a lot with the GitHub desktop application. It simplifies things a little bit for me. I wasn’t very good at the command

48:23 Line and I would say I’m okay at it right now. My developers are way better than command line than I am. They’re like whipping up commands and like oh just type all these things out and just use it on the command line. Great. I wish I was spending more time on it. I’m doing a lot more architecting and bigger picture things. So when I started doing Git, that was like the first entry into it. Oh, I can store all these little projects down on my computer. I can use Git desktop to help me manage those things. I could with a UI, I could, , create and click buttons, make branches, all these

48:54 Different things directly in there. I’m now much more of a fan of VS Code. I think I don’t actually use Git GitHub Desktop at all anymore. I’ve almost exclusively inside VS Code doing everything there. And again, I’m still not the best at command line. I’m sure Greg is much more on the command line thing. So, , I like your sentiment there, Tommy. Let’s kick over to Greg. Greg, what was it like for you to start learning this stuff? And, , maybe maybe some recommendations for new users. How do they get started? So, I really like official documentation. And there actually is a

49:28 Link that I had shared with you. It’s probably a good time to drop into the chat the git SCM one which is about branching and merging. And I find that the Git documents are quite good, but they’re the documentation that aren’t the best to get started. They’re really good to firm up an understanding after you’ve built up an intuition somewhere else. I don’t remember which tutorials I used, but I remember the the metaphor that was very helpful for me. And what I would suggest people do is as they’re working on

50:01 Getting familiar with Git and they’re making a branch or they’re doing a diff between two different branches and that thing, I would really recommend paralleling that by opening up a different folder in your file explorer and making a whole copy of the folder that contains the stuff that is in the git repo. Make a second copy of that whole folder and name that the same as you would the branch. And think of branches in source control as just whole copies of the entire the root folder of where your

50:33 Repo lives. And if you’re going to make three branches, that means you make three different copies of that source repo. And then when you want to understand what it means to merge things or to diff across branches, , go through your git tutorial and do that do those operations in the git tutorial to look at, , diffing between branches or doing a merge between branches. But then also go and look at the difference between those two folders that you’ve made where you have the original folder and then you have the copy of everything in that in a second folder named the same as you would the

51:06 Branch. And just think about it as okay, I’ve got these two copies of the folders and I want to make them one. I want to take everything that I did in this copy and bring that into the original one. And that metaphor of thinking of copies of folders and subdirectories on the file system is really useful for me in thinking about git. It’s not a perfect analogy, but I find it’s much more helpful than trying to start off by understanding branches as their own thing, but just think of them as copies of the folder. And that metaphor was very helpful for me. Good. So, I I’ve put the link to the

51:39 Documentation here. I also I also put the little meme here, which I think is also very funny. Greg, you you threw down a a quick little XK CD. It’s like a little like, , meme website that does these little memes for technical people here. And I think that the meme here is quite hilarious. It’s a little image here of some people pointing at a computer, little stick figures, and it says one person says, “This is Git. It tracks collaborative work. It it on projects through a beautiful distributed graph tree model.” And the the other individual on the on

52:11 The slide goes, “Cool. How do we use it? No idea. Just memorize these shell commands and then type them to sync up. [laughter] That’s like that was my that was 100% like my first interaction. Like I don’t really know what they do. If I type this command, the merge conflict goes away and I’m happy again. Like that’s the stuff I was initially doing here. And one thing I just want to as I think about this and what your your comments there Greg, , we’re talking about source control and we’re talking about Git or GitHub or or how that integr integration is working here. I’ve done a lot of

52:43 Talking with DevOps and what that is in in conjunction with what source control is. Source control is a a strategy. It’s it’s a technique that you’re using to be able to have people collaboratively work on things. When we talk like DevOps, it’s a broader story, but people think DevOps is like a program , Azure DevOps. That’s not what it is. , DevOps is a process. It’s a business enabled process to help you get work done. So, I see source control as being like if we think about Lego bricks here, source source control and using git is

53:16 Like a part of this foundation. It’s part of the ecosystem that is what we call DevOps, development, operations. and it defines the process by which we need to do to get work done. And so this is like a one of those foundational bricks that you have to understand to help you move forward. And I think I’m very pleased to see Microsoft improving this area. There’s definitely improvements coming. It’s still not perfect. There’s still a lot of challenges with using source control with files, semantic models, and all the

53:50 Things that come from fabric. But if nothing else, this is like a good starting point to start figuring out like where does this surface area fit. Any other thoughts? Yeah, go ahead, Greg. I think without going into another hour or two on DevOps as a practice, it’s important to understand that DevOps like you said, it is a series of practices and also automations that go on top of other things. So it’s Yeah, I’d agree with that one. Al almost all DevOps is built on top of some source control system and usually on top of a source control forge is the generic

54:24 Term. So GitHub is a forge. Git lab is a different forge. Azure DevOps in from Microsoft is a different forge. And so forges are these things where you have the source code and also the automations on top of it. And I don’t know of much DevOps that isn’t built on top of source control. But the important thing is that the things like CI/CD, these are just event- driven automations. The event is that some new code comes in. Sure. And the automations are the CI/CD part. The fact that they’re implemented on top of source control is a happy

54:57 Coincidence, but they are different things to understand. And I think it’s it’s useful to draw these sorts of lines because it can feel really overwhelming. If you think source control is everything that you can do on GitHub, then source control seems even bigger and more imposing because everything that you can do on GitHub as a category is a lot and it’s a lot more than source control. It’s also project management. It’s also automated builds and automated deployments. And all of these things are good practices, but you can start adopting source control without having

55:29 To adopt everything else or at least not right now. And having a good source control practice is useful for all of those other things as well. A good source control practice goes very well with a good project management practice, but you don’t need to adopt both at once. A good source control discipline goes very well with automated builds. But again, you don’t have to do both of those at once. I want to throw out an opinion here that may or may not land well as we wrap up here. , let’s just I guess we’re going to start wrapping here, but when we think about get CI/CD changes on things when I look at the

56:06 Landscape that is fabric right now, right, or anything that’s premium capacity by default, premium capacity gives you the ability to use git on a workspace. Now, there’s some places where this stuff falls apart, but again, as we’re talking about like new users getting involved with Git and building things and at least tracking source control on top of their workspaces, what are your feelings on like the I I want to say it’s like entry level and then there’s like professional level of things, right? So, if I’m entry level, I’m probably thinking about turning a

56:40 Git a a source control on at a workspace level. And then next level up would be okay. Now that you’ve source controlled the workspace, you can then also go see it on Azure DevOps or GitHub and see what’s being created when you change items or elements on the workspace. That’s level two maybe. But level three is okay, you now know what you’re doing. And to your point, Greg, around the forges, right, where actions can happen. when you get to like that next level, you don’t necessarily need to link the

57:12 Workspace anymore through the git repo and you can just manage all of the code independently and then the forge can push the code into the workspace as you need. So I my opinion here is I think the synchronizing a workspace using the the the git integration is a good first step for newer users. It it starts some good initial principles. It doesn’t solve all the problems and it is acting like you’re only building on main all the time. It’s not good for that reason. So, I definitely will acknowledge some of it falls apart,

57:46 Right? This doesn’t 100% fit the story of of what we’ve been talking here today. But, I do think it’s like level one and then level two, you can level up a bit more by seeing what’s in Git and GitHub, pulling those files down locally, making changes, pushing it back up. And then for me the when you add source control to a workspace you start shifting where the the true definition of things live. They stop becoming the workspace. And I can’t tell you the number of organizations I’ve worked with where people will just upload PBX files and say okay well they’re there and

58:18 They’ll just delete them off their desktop and then a month or two later come back and just have to download them again. Which is again it works. I’ve got me in the past when things were not as robust. I’ve gotten burned doing that. I’ve gotten burned where I put stuff up, things got edited, and I got locked in the service, and I can’t get it out. And it becomes very difficult to get copies of that stuff back out of the service. With the advent of better DICD pipelines and things, I think Microsoft’s gotten a lot better at letting you get getting things out of

58:49 The service. So, that’s gotten immensely better. Not perfect, but better. So, I’m just going to pause right there. I said a lot of things. the progression step one to to more prolevel things. , let me kick it over to Tommy. Tommy, do you agree with that approach or do you have veim, , disagreement with like how I’m pitching this? Honestly, I would say that this is something you got to start in dev rather than just turning a few things on because this can break a work. , I’ve already broken a workspace before. So if you’re not if you don’t have the

59:23 Plan with the branching strategies with different workspaces and you’re just going to do everything in main, you can easily run into issues, not just with trying to do a commit, but I’ve had issues with the PBR file saying it didn’t have enough refreshes and no idea what that meant, but so I would say yeah. So I would say no, this is absolutely something that you need to start in dev and just have a playground to do. Greg, what are your thoughts? I’d echo Tommy a little bit. , but I also do agree with you. I think it is

59:56 Better to have source control turned on for a workspace than not if you’re starting from absolutely zero, nothing else. Better to turn it on than not. But I agree with Tommy. , and what the way that I would state it is this. Sync is neither a build action nor is it a deploy action. So, git sync is not those things, but people try to use it for those things. , I don’t think we have time to really dive into building and deploying, but I’ll give a

60:28 Quick example. One thing that’s very common to do, , not so much in the PowerBI and semantic model world, but I think it’s a good practice people should use. But one thing that’s very common is to put into a built artifact the exact commit hash. And a hash is what git uses to identify the ex a single commit. it uniquely identifies that set of changes throughout the entire repository. And a common thing to do is to put that git hash into the built artifact. For a semantic model, that would mean defining a measure or a table with a hard-coded column that has the git hash in it. Now,

61:02 The only possible way to do that is to make a change to what is in the source control or in the source control repository after something has been checked in. It is impossible to put the hash into something and then commit it because by changing the hash, you’ve changed the object. You commit it, there’s a new hash. So you can’t actually take the hash and put it into the object within the context of a git commit. You can only do that outside of that context through some automated build action. This is one example and it is representative of the types of things that you might want

61:35 To do. You want to act on what is checked into source control and then build something and then take that built object and put it into place in a in an appropriate environment in dev in test in prod to be able to do something like that. Sync is an insufficient mechanism. And so sync is not build. Sync is not deploy. And if you want to do CI/CD, you want to be able to build automatically. You want to be able to deploy automatically. And so that’s where I’m going to echo what Tommy said. If you’re trying to use git sync as part of a DevOps practice, you’re probably going

62:06 To run into some pains. Yeah. And so I agree with you, Mike. It’s better to turn it on than not if you’re doing nothing else. And as soon as you’re trying to adopt other practices, you should probably turn off Git Sync and just treat your repo in your forge as your source of truth. And then it is responsibility and work because you have to then come up with the deployment process that takes bits that live in source control and take them and put them into the place where they need to go. Sync does move bits from one place to another. It takes

62:38 The exact bits on disk from one place and puts them in the other. But that is again neither build nor deploy. It is simply sync. Okay, good points there. I think we have a whole another topic we could basically open up here is like deployment patterns and how’s that look and what what where do you start? So really good thoughts here. I hope you everyone has enjoyed this conversation around source control things that are out there just some really fundamentals. I think a lot of this this really wasn’t a very detailed conversation around specifically fabric or powerbi was more just conceptually what does this mean for us? How do we how do we

63:10 Mentally put a mental model around what source control means for us now that we’re inside this this fabric world? Anyways, Greg, thank you so much for your time on the podcast today. Again, as always, I love the education you’re providing to us. It’s good to have someone way smarter than both Tommy and I put together on the podcast. So, thoroughly enjoy the conversation and the and the examples you’re bringing. Spot on. Super super clean. I really like the examples as well. That being said, thank you all so much for joining us on the podcast. We appreciate your time. We know you can be doing a million other things like actually getting real

63:42 Work done at your job. So, , thank you for spending some of the time with us and and, , not spending it being productive. , that being said, we really do appreciate all your likes and comments down below. Please make sure you let us know in the feedback and and help the algorithm out by if you like this conversation, if you want us to do more of these, please let us know in the comments. Put your thoughts down. We’d love to hear how you’re using Git. Are you using it in different places? what are your opinions around it? Where have you struggled at the beginning and how have you overcome them? That would be super helpful for the community in

64:13 General just to hear more about that as well. That being said, Tommy, where else can you find the podcast? You can find us on Apple, Spotify, or wherever you get your podcast. Make sure to subscribe and leave a rating. It helps us out a ton. Do you have a question, idea, or topic that you want us to talk about a future episode? Head over to powerbi.tips/mpodcast. Leave your name and a great question. And finally, join us live every Tuesday and Thursday, 7:30 a.m. Central, and join the conversation in all of PowerBI tips social media channels. Thank you all, and we’ll see you next time.

Thank You

Want to catch us live? Join every Tuesday and Thursday at 7:30 AM Central on YouTube and LinkedIn.

Got a question? Head to powerbi.tips/empodcast and submit your topic ideas.

Listen on Spotify, Apple Podcasts, or wherever you get your podcasts.