Git Best Practices Diff Noise & Naming - Ep. 513

Mike and Tommy use this episode to zoom out from tools and focus on the discipline behind good Git hygiene. The conversation turns everyday annoyances—noisy diffs, sloppy naming, and hard-to-review changes—into a practical guide for building cleaner repos, calmer reviews, and workflows your future self will actually appreciate.

News & Announcements

There were no dedicated news links in the video description for this episode beyond the standard subscribe, follow, and contact links. This one stays focused on workflow discipline and practical team habits instead of external announcements.

Main Discussion

Topic: Git best practices for reducing diff noise and improving naming discipline

Mike and Tommy frame Git best practices as a communication problem as much as a technical one. Clean diffs, clear naming, and intentional organization make it easier for teammates to understand what changed, why it changed, and whether the change is safe to approve.

• Treat diffs as a shared communication surface. A pull request is not just a bundle of code changes; it is the artifact reviewers use to understand intent. When formatting churn, renamed fields, or unrelated edits get mixed together, the real change becomes harder to spot.

• Reduce diff noise before you ask for review. Teams move faster when cosmetic changes, reformatting, and structural cleanup are separated from logic changes. That keeps reviewers focused on behavior instead of wading through a wall of irrelevant red and green.

• Use naming to explain purpose, not just type. Good names should help someone infer what a file, branch, object, or function is for without extra translation. Mike and Tommy emphasize that naming becomes even more important as projects grow and more people touch the same repo.

• Consistency beats cleverness. The best convention is usually the one the whole team can remember and apply repeatedly. A simple, enforced pattern for branch names, files, and artifacts is more valuable than an elaborate system nobody follows.

• Keep changes scoped to one intent. Mixing refactors, bug fixes, and new features into one branch creates confusing history and painful code reviews. Smaller, purposeful commits and PRs make both rollback and collaboration dramatically easier.

• Optimize for future maintenance, not just today’s merge. A clean Git history pays off later when debugging regressions, tracing decisions, or understanding why a rename happened. The point is not perfection; it is preserving enough clarity that the repo remains usable over time.

• Reviewability is part of engineering quality. If a change is technically correct but difficult to review, it still creates risk for the team. Lowering friction in reviews is a real engineering outcome, not just a courtesy.

Looking Forward

If your team has been tolerating noisy pull requests and inconsistent naming, this episode is a good prompt to document a lightweight Git standard and start applying it to the next review instead of waiting for a perfect process overhaul.

Episode Transcript

0:05 Exp. [music] Tommy and Mike lighting up the sky. Dance to the day to laugh in the [music] mix. Fabric and A. I get your feels. Explicit measures. Drop the beat [music] now. Pumpkins feel the crown. Explicit measures. Welcome back to another episode of the Explicit Measures podcast. Tommy, good morning. How are you doing, dude? what? I’m also doing so much better because it’s funny how music

0:37 much better because it’s funny how music can change your personality. The our intro just awesome. Awesome. Yeah. Well, this has been a super fun for those of you who haven’t been joining us in a while, as of episode 500, we have changed our intro. We now have a new intro now moving forward for the next 500. So, you’re going to have to hear this song for the next 500 episodes until we hit a thousand. So, for the next five years, you’re going to hear that same same intro every single time. That being said, this is a recorded episode. Tommy and I are doing some traveling here and so because of that, this will

1:07 here and so because of that, this will be recorded. If you like to get episodes ahead of time, if you don’t want to wait for these episodes to come out and you want to be getting them as we record them, all we take all of our recordings and episodes, we put them immediately as soon as we can into the PowerBI tips website. So, if you want early previews of content, you can go ahead and subscribe, become a member, you need to be visualize this higher and higher level to be able to get access to the the episodes directly as we record them. So, that being a question for Yeah. Yeah. Go ahead. Let’s see. I do have a

1:39 Yeah. Go ahead. Let’s see. I do have a question for you before we dive into what the topic is. Speaking of music, I’m curious for you. Your normal workday when you’re just doing your normal work, do you have anything on? Do you do music? What is your background noise if any? any? Yeah, I would say if I don’t forget, there’s always some music playing in the background. And I usually I usually like lyrics or songs that do not have lyrics in them, but it’s upbeat. It’s energetic stuff. It’s like very like,

2:10 stuff. It’s like very like,, my kids would describe it as bouncy. It’s bouncy music. It’s very very happy,, you just want to bop to it, right? but that’s pretty much every day. I’ll have that running as much as I can. Even when I’m in certain meetings, sometimes I’ll just like put it on quietly because I have a audio mixer here that lets me balance the music like in or out of my headphones, in or out of the microphone. So, I have like a a a professional studio mixer thing and so I can use that to put music quietly on the back of my ears. I find

2:41 quietly on the back of my ears. I find it just helps me stay focused and keep things clean and clear. And also, if I’m listening to music, I’m less likely to jump in. I think I slow down a little bit when talking with other people. Interesting. Interesting. I tried music. Yeah, I’ve tried music in the past, but I I then I get focused on like what album it is and when an album ends, it breaks me in and out. So, I’m very much a podcast person and and Oh, you can listen to a podcast while

3:13 Oh, you can listen to a podcast while working. working. It’s the ADD mind, man. just talking in the background. Like honestly that slows me down because it’s just that pattern rather than like there’s the chorus and then there’s the bridge. You’re like, “Oh, the music change.” So, so is my thought process. Just hearing just normal chatter, just noise is so much better than quiet and so much better than music for me. So, so it’s almost like you’re replicating like an office space with people talking in the background., it’s quiet, but it’s around, but you’re still doing stuff. If you’re just like you can just

3:44 stuff. If you’re just like you can just tone out that talking noise and focus on what you’re doing. It’s incredibly easy to do in my brain. It just and it makes honestly me able to focus. focus. Interesting. So does that mean you’re listening to a podcast right now during our podcast? No, this this I only hear you my friend. This is so meta right now. I was new to us yesterday. Yeah, [laughter] that’s amazing. All right, great great little introduction topic there. So let’s jump into our our mailback. This is a mailback today topic. it will be

4:14 is a mailback today topic. it will be git best practices, diff noise and naming. And I think this is going to cover a lot of topics here because there is git just like as a best practice in general. And then there is how do you use git integration directly with fabric and powerbi? That’s another whole kind and powerbi? That’s another whole ball of wax here. And let’s see where of ball of wax here. And let’s see where this question goes. and we’ll we’ll figure it out from there. What do you think Tommy? I I love it. I love it. So again, this is March Mailbag Mania. We’ve gotten so many people submitting questions that we’re like, we got we got

4:45 questions that we’re like, we got we got to cover these at some point. So, yep. let’s dive right into the mailbag. And again, people people put a name. We really do want to give a shout out to the people who are submitting these great questions. We love talking about them, too. We love the types of questions people are doing. So, here we go. Hey guys, great show. Thanks. I would be thrilled if you get a little more concrete on best practices around source control. I pushed for adoption of git even though we were only

5:15 adoption of git even though we were only a small team. I guess I have a few topics I would love your feedback on. How to avoid diff different noise or the the diff process for multiple people working on the same report constantly changing expansion states of dimensions i. e. metrics, visual slicer selections, etc. Maybe a safe option that does not store these things would be very beneficial. I had or have GitHub Copilot write me a

5:47 I had or have GitHub Copilot write me a script to rename the folder of visuals and pages so that the diffs are human understandable. Is this really the way to go? Thank you so much for your great work. Love this question. I thought you were gonna say love Robert or Shannon or somebody like I thought you were gonna make up a name at the end there because there was no name provided. provided. Sorry. Yeah. End and end end question. Now Thomas end question finished. Awesome. This is a great topic. So, I think we need to

6:18 a great topic. So, I think we need to state just maybe some very brief assumptions about where this person is coming from with their team, what they’re doing with Git because I I do want to touch on I think GitHub or using Git integration comes in multiple flavors as the maturity level of your team., for me personally, I like to think of it as like there’s like beginner mode, there’s like intermediate mode, and then there’s like full-on advanced mode with Git integration, like stuff that you can you can really heavily automate and and do a lot of neat things

6:48 automate and and do a lot of neat things there. Each one of them have their own advantages, I think,, and help you in different ways. As you become more comfortable, I think you’re able to move up the scale from beginner mode to intermediate mode, ultimately into advanced mode. And it depends where your company comes from. How do you guys like to build as a BI team? And I’ll just point out I think traditionally Tommy BI teams do not have the concept of git integration. BI teams do not have the concept of dev test

7:18 do not have the concept of dev test prod. More advanced teams do but most teams in the BI space don’t think that way. I remember when I started with PowerBI the best I thought of was like prod and backup, right? I had things I would publish and then save all the files into SharePoint. That was my backup of those files. And it was very single person driven. When someone needs to work on a report, it was one person only working on the one report. We never really wanted to split work between

7:48 really wanted to split work between people and have two people working on the same report because stuff would get overwritten. It would be a problem. We didn’t have any way of saving things. So, let me pause there. Tommy, what are your thoughts on that framework? beginner, intermediate, and advanced. So, yeah, a few comments there. I think this get changes the way that people not only work, but I think what they’re actually working on because to your point, Mike, just like the previous work

8:18 point, Mike, just like the previous work style. Well, generally speaking, what I’ve seen is like a dev in production where we’re going to build the report and then to a production workspace. However, However, very common. Yep. Yeah. Very common. However, once it was in prod, then you just always made those predictions to the production work report. That was always a development of report, not any modifications. But I think the important part you’re talking about here, Mike, is everyone was siloed. Like I when I first started was like the marketing and sales report developer analyst

8:49 report developer analyst because it was very difficult to work in any collaboration on a model and we stored things in SharePoint and everyone had access to it but no one was really also working on my reports because I didn’t know if they made a change until like the SharePoint file changed I couldn’t know what those changes were so it was a much more difficult process which basically made me siloed. what what made any of the analyst silo when I became a director of BI that was the same idea where okay

9:21 BI that was the same idea where okay you’re going to be head of marketing data you’re going to be the subject matter expert in operations because the technology was constrained that way with git and I think where you’re talking about this expansion to the intermediate side the advanced side is I can get all these changes and I can really collaborate which is very much honestly for us a novel concept, but when you’re dealing with Git is the purpose of that, too.

9:51 of that, too. Yeah, let’s go let’s go down that route, I think, a little bit, Tommy. So, let let’s I want to maybe add a little bit of context for those who are not familiar. Again, I’m going to assume that some people know what’s going on here, some people don’t know what’s going on here. So, I’m going to maybe step back here a little bit as well. When we talk about there’s there’s difference between Git and GitHub, right? So, GitHub is a software that Microsoft owns. they bought them out and GitHub is where you can store your code when you’re working on fabric workspaces

10:21 when you’re working on fabric workspaces and even I think premium per user also get this as well if you want to integrate with git git the git integration can go in two different places you can use azure devops which is one it just stores the same git experience it’s the same libraries it’s the same pattern as you do with GitHub so there’s two primary landing places if you’re going to use Git integration with the workspaces. So, I’m going to just call that out to begin with. It’s a good point.

10:51 It’s a good point. I prefer it. I waffle back and forth a little bit. Say it. Say it. I know what you’re going to say, but just say it out loud. I don’t know if I actually can pick one or the other anymore, Tommy. I I there’s advantages of either one. I like GitHub’s ability to use agents to do things like agents, agentic, building things with agent stuff is awesome in GitHub. In Azure DevOps, you get really good clear documentation on who is changing what bit of code with like

11:23 changing what bit of code with like commits and messages. And I I physically know when Tommy makes a change and he commits the change back to the repo or to the workspace, I know who made it. it it stores Tommy’s credentials directly there. My understanding is as of today there’s no clear way to say Tommy made this change on the GitHub repo. It’s basically using a shared access key and every change is coming from the same

11:48 and every change is coming from the same person or the same shared access key. So it’s it’s more difficult to determine who’s making the change on GitHub. That’s the only drawback that I see on GitHub at this point., Matias Tarbach has also done a really good job of doing a trustless, authorization of GitHub with your, your workspaces. So that way you don’t have to have a shared access key which is like a big no no in the in the world of like security. You don’t really want that. You want to be able to grant specific action or specific access to this

12:18 action or specific access to this workspace can talk to this git repo. So that’s that’s a very technical advanced detail, but just saying that GitHub seems to be my preference right now, even though I had to do a little bit more creativity around getting it connected into powerbi. com. So let me just pause right there. Thoughts on those two realms, Tommy? Did I miss anything that you would add to InHub versus VS Code? If you’re not, I’ll say it. GitHub is the preferred way. Like I I understand

12:49 the preferred way. Like I I understand the access thing, but that’s also too, and correct me if I’m wrong, I don’t see who the user is if I’m making changes in the service. If I’m making changes on my own machine and publishing and committing that to the repo, the repo, that user that user GitHub, GitHub, right? The the problem that you had. Now, let’s say if I modify a report in the service, I don’t know who that is. Correct. And that’s more of my general, right? So that case, but as we think about the maturity of teams as they’re growing up, I’m not

13:19 teams as they’re growing up, I’m not going to assume everyone’s going to use Git and immediately do all their edits and changes by pulling down the Git repo, using VS Code, and then editing with desktop on top of things. I’m going to assume the repo is the source of truth. And my assumption here is the reason you do this is you’re going to allow the ability to change things in the workspace. You’re going to allow changes in the code library with VS Code. you’re going to allow changes in multiple places and this the whole idea of this is it doesn’t really matter how you change the code the source of

13:50 how you change the code the source of truth truth is the git repo is the repo whatever that is the repository yeah and when we say repo repository so that’s a fundamental mental shift though for most people because typically everyone thinks the workspace the one that you’re working in is the source of truth truth and as soon as you add git it’s not your mental model needs to change and the workspace does not become the source of truth It is a portion of source of truth but is not the final end all beall. The git repo is the source of

14:20 beall. The git repo is the source of truth. truth. When you get to using a repository only and that becomes the source of truth. I equate it to basically going from riding a bike to driving a car. Not so much in the skill Mike but there are certain rules of the road. I think that the person who submitted this mailbag I I don’t think mentioned that’s really important right at this junction and one of the big things about is committing. So again the other change most people are coming from a sharepoint or one drive type setting of storing

14:50 or one drive type setting of storing their information or publishing. So everything was very I think everything or I had to publish or or or the workspace is the source. I’ve seen I’ve seen teams where like we have no concept of like SharePoint backing up, right? It’s literally I publish the report and then it goes to the service and then I download the report, work on it and then push it back up again, which is fine. I would just argue it’s very basic like that’s a very simple way of thinking about how you store changes of things. And I think it’s also a very large risk

15:21 And I think it’s also a very large risk to the company because there is no ability to roll back and see this report had six or seven different changes over the course of the last couple days. How do I if I break something? I don’t have a good way of reverting back to what it was. The fundamental shift and this is only really allowed because we have the new format of PowerBI desk reports. This would not matter, Mike. And also too, I think one thing to mention here, none of this would matter what we’re talking about if we did not have the PBIR

15:53 about if we did not have the PBIR format, which is changing everything because before first nine years, first yeah, first about eight years of our existence in PowerBI, PowerBI was binary. It was a file a pubix which was not easily seen in terms of like what changes were made. I know there are different versions of it, but the only way to know what changed was actually open up the PowerBI report desktop file and I had to go through manually. The difference now is Microsoft did like you

16:25 difference now is Microsoft did like you do any application if you’re writing in Python there’s code it’s codified and that has been a fun that this is what allows us to do git in general. Mike the fundamental difference in when we think of GitHub why would I use a repository? Why would I use Azure DevOps or GitHub? Well, it’s this ability what’s called a commit. And this is the the question that was asked about difference or the diff. I know what changes were made. I can see

16:56 I know what changes were made. I can see the difference between each commit is basically each version of the repository. So let’s say Mike, I worked on two or three different reports in a repository. Well, what I have to do now and this is the modern flow in a repository. I commit those changes. So each of those files is now updated. Not when I save it, not when I publish it, but when I do this commit, a user can then go in and say, “Hey, there’s a new commit. Okay, what is the difference

17:26 commit. Okay, what is the difference between this commit? What changes were made?” And I can see a measure was added or even,, the location of of a design and it’s codified. This is the rules of the road here that we’re dealing with. So there’s I have another thing about a commit that’s really important here, but let me pause there. That does change the way we work. Correct. In terms of just with the PBIR too. too. Yeah. So Yeah. So there’s a little bit of history that we need to maybe touch on here to

17:56 need to maybe touch on here to speak to your point here. You’re right. The PBIR format is this solid the solid change that Microsoft has been making to how this works. I believe the community for a long period of time was like, man, it’d be really nice if I could have multiple people work on the same report. [clears throat] The only way to do this is to take a file-based approach and break down the concept of report into many small files that can that can become compiled together to make one piece of reporting. It’s the same concept of software. When

18:26 It’s the same concept of software. When you build software, you don’t build one monolithic file for all the software. You build lots of files that all talk to each other and reference each other. And that helps you to be able to edit very specific things. For example, a the folder structure of the PBIR allows you to specify a page. Inside the page, there are page level settings. So there’s settings at the page level, which is in a file, and then each visual becomes its own file. So if you add a new visual, you’re adding a new file to

18:56 new visual, you’re adding a new file to this PBIR format. You can then specify where the visual lives, what are its settings, all the properties of that visual. So this is the ability for you to be able to cleanly adjust and know specifically what things changed. Tommy came in, he added a new page. I can see the new file appeared for Tommy. Here’s where the new page references occur. So this is fundamental in like how you build code and actually how you work better with building

19:28 better with building solutions that have like multiple people working on the same stuff. Right? Right? To go back to the this timb format. PB format is the side of the report side. The TMDL tab your model definition language TMDL that is the equivalent of the report side breaking things into small files but for the semantic model. So the semantic model gets the same thing a table columns measures these are all broken down into smaller files that make

19:58 broken down into smaller files that make it easier for us to manipulate and manage the semantic model as well. So the combination of these two pieces is what enables us to have this new format. Microsoft has been working really hard to make this standard NGA. It’s going to be almost we’re we’re really close to being GA. Apparently right now all feature parody from the old PBIX format and the PBIR format and TIMDLE are equivalent. All the features are covered in the new format. Moving forward, Microsoft will only develop in

20:28 forward, Microsoft will only develop in the new PBIR format. They’re getting runtime on it right now and making sure there’s no bugs. So that’s what the it’s not in GA yet is because they’re just waiting for bugs to get squished and fix things and make sure it has enough run time to say it’s good. So this is the future. PBIR format is the way of building reports moving forward. I’m not sure where I was going with that, Tommy, but did this answer your question or [laughter] or Monday, so there’s a bit of a runway here. So going off of that and

21:00 a runway here. So going off of that and again this is not I I I think it’s important to make the distinction. So you’re not going to just have a single file to find your report. It’s going to be in multiple files. Correct. Correct. All right. So with that concept in mind, one thing I I was disappointed a bit in the mailbag question about how do you track difficil because I think I had to read this question three times to really get what it was asking here. So tell me what you think he means by or he or she means by diff noise in this

21:32 or she means by diff noise in this statement. What do you think this is? I imagine I imagine this is a person who looks at the repo sees there’s four new commits and it shows 27 updated files and like I don’t know where to start thing like how do I actually navigate to verify or to have a good sense of what those changes were. I can see these green and red lines. I can see a bunch of files were updated, but it’s still hard for a human to read and go through 27 updated tables and report pages that are all files now and to say,

22:03 pages that are all files now and to say, “Oh, I can translate that to what was actually changed for the user.” Okay, so let me add some more context. I think what’s going on here? I think you’re right in some degree, but I think actually if you read a bit further, and this is why I had to read this statement three times. How do you avoid the diff noise? And let’s talk more about like the for example when you have a matrix on a page sometimes you click on a piece of data and that state is expanded right right if you have a slicer that has been selected with a value. If you have a

22:37 selected with a value. If you have a a filter content, so you have a slash on the page and you type in the words into the filter, those words are stored in the filter as a filtered list that then users would see with us as a commit change updated file. So the what I’m trying to point out is all of those changes, right? Even down to the visual level like is the filter pane open? Is the filter pane closed on page one? Is the filter pane open? On page two, is the filter ping open or closed? So, I think what the question is

23:08 closed? So, I think what the question is when you have two people working on the same report, Tommy, you’re going to go in and you’re going to test some stuff. I’m going to go build this. I’m going to build this. I’m build this. At some point, you may have forgotten to reset something. You didn’t reset all the filters. You didn’t reset the matrix back to its default state. You didn’t unexpand everything and minimize everything altogether. So there’s almost this I see where you’re going. Okay. You see, I think I’m reading this

23:36 You see, I think I’m reading this question as like look, there’s a lot of noise for people to go through and build things in the report that is added to the commits because someone undo something. Yes, correct. It’s not necessary. I don’t actually want to publish the report with a filtered slicer plane or I don’t want to publish the report with a matrix that’s got stuff selected in it. Right? That’s not the intent. The intent is to have a clean report, make changes to the report or things in the report, but then

24:07 report or things in the report, but then all these little like things people forget to do, you you turn you get rid of them, right? You don’t them. Yeah. I’m going to take it a step further. Regardless of whether or not you forget to change it back, those changes are shown in a commit the same as if I update or add or delete a measure or change the business logic. There’s no difference from looking at a sea of changes on it. Only they both they all look the same. They all look like a change in the file.

24:37 like a change in the file. Agreed. Agreed. Which is also noise because there’s some noise that’s more important than others. If someone forgets to do the filter pane or changes the definition of a measure, which one should I validate? I lose the measure. Right? But I think this is the this is the problem though. Like this is what I’m I think I think the issue is how do you get rid of that noise? So we have a state of this matrix visual. The matrix visual is on this page. This is the default state I want it to be in. How do you con how do you conform the state of

25:08 you con how do you conform the state of that matrix to be the same every single time and you don’t get the added noise? Now I think how I would how I would portray this right to your point Tommy the get checkin or the commits is going to show every little thing. So, if there is a non-standard pattern you see on the matrix, on the page, someone added something in there, you’re going to see the diff that’s going to have a whole bunch of extra code and content. What I would argue is that is part of

25:39 What I would argue is that is part of the reviewer’s job, right? When you see things like added filter context to a slicer, expanded tables or matrix or the expanded matrix, that is a warning sign that the user didn’t reset the state of that commit correctly. You can do one of two things. You can try and fix it by making another commit to undo it as part of your your review process, going in, delete the code, revert it. I don’t

26:09 delete the code, revert it. I don’t think that’s the right process. Or you can say, I’m going to reject this pull request and you need to make comments on this. Here is where you added this additional context. The process here is supposed to be go back to the developer, reject the change, and say you didn’t do something right. You changed something you shouldn’t have changed. You should go back and fix it. they should go back, unset that property,, fix it, and then commit it again, and then see that there’s no diff on the on the matrix expansion stuff.

26:40 on the matrix expansion stuff. I I think there’s two things you’re talking about here that Let’s Let’s get right on the same page here. Mhm. Mhm. You cannot reject a change, a commit. You can revert a commit, which creates a new commit. Then it gets really complicated here. You’re talking about a pull request., yes. Hold on. So, I need I think I skipped ahead. Yeah, you’re right. I think I need to add some more context here. here. Yeah. But before you do that, I’m gonna I’m gonna I want to add something here really important in terms of what’s the solution here. My responsibility if I am working in a

27:10 My responsibility if I am working in a team that is relying on a GitHub repository and source control again regardless of GitHub or not. Sure. Sure. I have a responsibility to alleviate the noise. Not necessarily with to me what you’re talking about with whether or not a matrix expanded or not. Fine. But if that’s combined, which it usually is combined with model changes, which is more my concern, my responsibility, just like stopping at a red light, is my commit message. So this is another

27:41 commit message. So this is another concept. This is a basic concept here that I really want to focus on. When you create a commit, when you say I’m going to push these changes to the repository, all the changes in that repository, you can add a message and a description and basically, hey, commit change. We did this and then you can outline those changes or you can just do what’s default,, a basic,, squiggly, whatever. A lot of times I used to do was just write like ABCD just so it had a message on it. Yep. Yep. However, that does not help anyone who’s

28:13 However, that does not help anyone who’s doing a review. Correct. We’ll get into the difference here. If I’m working in the same branch, not to get too over the top yet, I have a responsibility, and this is the point. I have a responsibility if I’m working in a team in source control to add the right commit message because there are going to be no matter what Mike Mike even changes that I’ve seen Mike where it’s like the model version changes like it’s now 1508 to 1507 or like these little knick-knack things that are noise

28:45 little knick-knack things that are noise some things even if I reset everything it just updates random parts of the files but what I want people to focus on I dang Well, better add to my commit message. It’s saying we updated the, you message. It’s saying we updated the,, diffusion model. We added three know, diffusion model. We added three measures. Okay. Well, now as a reviewer, I can go I know where to navigate to review those files out of the 50, you review those files out of the 50,, the sea of changes and the sea of know, the sea of changes and the sea of files that changed. I know where to hyperfocus on what files to review

29:17 hyperfocus on what files to review rather than going through each file individually. I have a responsibility and I think anyone does and I think this is part of the process that you better well implement is the commit process. yes I agree. I think the committing messages I agree with you there. I think what I’m also hearing you say Tommy and I’m going to read between the lines here a little bit based on what your statement is.

29:50 If we’re using a workspace enabled git integration, whatever that may be, you’re and and you’re basic you’re working on a branch of code. Mhm. Mhm. So, we talked a little bit earlier, and this is why I’m going to try and phrase this in like these like beginner, intermediate, advanced levels here, right? So, when I talk about a beginner mode of what we’re doing with Git integration, beginner mode to me would be I’m going to go to a workspace and I’m going to turn on Git integration. I’m going to have a repo and it’s just the main branch that this is the the story of truth is that main branch very

30:22 story of truth is that main branch very simple I’m not building multiple branches I’m every time I make a change on the repo I’m committing everything to main this is very basic when I make a change I write a commit message to your point Tommy describe what happened here’s what happened submit this diff noise that we’re talking about that in the question here is very hard to unwind or fix without making another commit to fix the thing that was just committed. So it’s it’s

30:52 that was just committed. So it’s it’s basically like pick up the files again, fix it and put it back in. So th this this concept of beginner mode is you have one branch and everyone works on the one branch. Everyone is committing their code back to the one branch. Again, good place to start for just getting your feet wet with what branching and GitHub and Git looks like, right? The next level up, which I would call a bit more intermediate, is you need to start thinking about a strategy on, okay, now I have potentially two

31:22 on, okay, now I have potentially two workspaces. I know where you’re going with this. Okay, I have one workspace that is dev and I have another workspace that’s production. So, how do I handle two changes at once? Right? I may be working with developers on the dev branch to build something new, add a new page, add more visuals, fix something, adjust a measure, whatever the things are, right? I have this library of of changes and I may want to get it to the next level, right? This is where I think you need to

31:52 right? This is where I think you need to start understanding in the intermediate level the branching strategy. You need branches. So, I’m going to have a dev workspace. I’m going to have a prod workspace and I may want to use the dev workspace on the dev branch. This is why you want to do this because when I was going back earlier to the diff noise and we were talking about commit messages and changes and things, you can go into the dev branch, make a bunch of changes, and then see there’s this noise. You opened the matrix up. You added this filter to the slicer.

32:23 You added this filter to the slicer. these do not exist in here and you don’t want to pull those changes into production because you’re gonna automatically filter out or make some data dis disappear based on what you described like what you changed. So I think to handle this diff question is you need to really start thinking about a strategy around I need more than one branch of of changes that are occurring. And so now you’ve really got to introduce your team to branching strategies. What do a commit mean? what

32:53 strategies. What do a commit mean? what a commits to dev look like and how do I pull a dev branch pull those changes into the main branch. That’s a that’s a whole new ball of wax that the team needs to understand away from I’m just going to drop git on a workspace and we’re going to call it done. I my mental model is when git is turned on to a workspace, it is a simple backup method and revert method to that workspace.

33:23 method to that workspace. I I every change is captured and I can back up and revert if needed. So I would say I I’ll add a little on there on and as we’re answering this question. So that basic intermediate advance I would say your basic minimal viable skill is committing and writing correct commit messages. Writing appropriate commit messages. Right. Being getting that working like describe the changes you just made. Make sure you tell people what you did. Yep. Yep. Exactly. And you can use GitHub copilot too but saying we worked on this

33:54 copilot too but saying we worked on this semantic model. We updated this report in the commitment message. That is your minimal viable to be a basic level in PowerBI and we’re still working usually basic one to one one workspace one repository. I love where you’re going with this because this is exactly where I wanted to go. If you really want to eliminate noise and to the question, you have to then develop and introduce branching and multiple workspaces to

34:24 branching and multiple workspaces to that repository to that source. And that really Mike is the way that noise is eliminated. But you have to introduce this concept here. Now a very one to one again. Okay, I’ll pause there. there. Yeah, pause. Let’s pause right there. I just want to throw something. love this idea and I want to introduce branching as some concepts here. So before we go to the next thought because I think I wanna I want to hang on this branch. Oh, I’m gonna hang on branching too. Yeah, [laughter] let’s hang on the branches.

34:55 let’s hang on the branches. All right, let’s keep going a little bit further down this topic. Okay, branching is really important here. So again, mental model here. You have a dev workspace, you have a production workspace. Okay, we have two different workspaces. Let’s say I want to make some changes. Like let’s actually push Tommy. Tommy, I want you to go add another report page or I want you to make some more measure changes. How do you do this? And there’s another couple concepts here that I think again falls into the immediate maybe even to the advanced mode which is okay Tommy take a cut of

35:27 mode which is okay Tommy take a cut of the current dev branch. Make a Tommy developer branch. You build a brand new workspace. You have all the artifacts deployed into that workspace separately. Tommy, you work on those changes independently all by yourself. You’re the only one who has access to the workspace. You’re the only one who has access to the changes. You make all the changes you need. Now, this is creating an a third branch, right? You have one branch maybe for main, one branch for the dev workspace. Now, Tommy’s creating a third branch, which

35:58 Tommy’s creating a third branch, which is Tommy’s new changes, what you’re trying to build. Now that new branch is what you pull requests back into dev. I’m Tommy’s done his individual contributor work. We now need to do integration testing which is in the development environment. Tommy’s now complete. I’m done. And you pull requests back to dev. And now we have the review. So to that’s that’s another like this is again more advanced branching strategies where developers are actually taking think

36:28 developers are actually taking think of it like an encyclopedia. I’m going to give you some work Tommy. You’re going to take this the book that is your encyclopedia page off. You’re going to take it, go use it, and then put it back into the encyclopedia when you’re done. Any changes that are made go back into that main that that branch for whatever you’re trying to commit back to. I would challenge what you’re saying is intermediate though too because and again this is you really want to eliminate the noise and also I would even challenge one step further. If you really want to provide full collaboration, you really have to go

36:59 collaboration, you really have to go this route. And the reason why, for example, let’s say you’re building an app, let’s say you’re building a podcast app or,, building an app for your kids and I’m like, Mike, I think I can make this really cool. I don’t want to obviously overwrite anything you did, right? So, I basically extract at a certain point what your app looked like. And to your point, I have my own branch now of revised changes. I have two abilities here. At any point, if you’re updating your main your master app and

37:30 updating your main your master app and you’re like, “Oh, I made some changes. I can pull that into mine.” But at some point, I’m going to say, “Mike, I made some changes. I added colors. I even added some new features to this application.” I want you to take a look at that. Well, I what we do is it’s called a pull request. And you mentioned this idea of pull. What the heck is a pull? is simply the ability and it’s a really novel ability by git to merge changes together based on again the point in time and it’s really important here where we go

38:00 it’s really important here where we go through a pull request on verifying and validating that obviously any nothing’s broken that does get into the more advanced stage however and unfortunately for people listening you want collaboration you really have to master this you really have to be on top of this because this is not for the faint of part. However, going through the collaboration and what I spoke to was just for like really just a repository. I would like to if if if you

38:30 repository. I would like to if if if you so are willing to focus on I think the onetoone idea here where let’s say dev and prod with workspaces if you were do that example I can have two separate workspaces that inter that act on their own but what I would do and I would recommend to be in the intermediate level is they’re off the same repository just a different branch and I think that’s what you’re really saying so in PowerBI I have a you really saying so in PowerBI I have a the marketing pro prod workspace

39:00 know the marketing pro prod workspace and I also have another workspace called marketing dev workspace. Well, if I’m going to do source control, write, both of those workspaces are using the same repository. The only difference is what branch they’re using. Th this is a what you describe is a pattern in I would argue a handful of patterns that work right so

39:30 work right so yeah [laughter] so if you go to Microsoft documentation and you look at what they’re doing on how they’re deploying code this is this is something you can use there’s so many patterns and how you do branching and branching strategies also I’ll note here traditionally when you went to go look at like GitHub and started looking at or Sorry. Go to the workspace. When you go to a workspace and you have a git enabled workspace, you used to have only a button called commit, commit, right? So, you used to only have a single button that said commit to

40:01 single button that said commit to the branch that you’re on, whatever you’re linked to. Yeah. For example, I have a workspace up here. It’s connected to the main branch, which is the source of truth. And if I commit, I’m committing committing messages directly to a main branch. However, Microsoft has recently added the ability to make a new branch during that workspace. So, you can have a workspace committing its changes to a branch that you can then go pull those into

40:31 into the main branch. So, Microsoft is introducing in the UI of the git repos the ability to create branches on the fly from a workspace. in in real time. And the reason why this is important is because what we’re talking about this intermediate level, this is where I think you need to understand what branching is, what a commit is, and how do you do a pull request? request? Yeah. Yeah. going back to your full comment, Tommy, around do I have two branches, one called prod

41:03 do I have two branches, one called prod and one called dev. Yes, that will work. That is one way of doing it. There’s actually multitudes of other ways you can build this. You could have without getting to the weeds. Yeah. Yeah. We could have a single branch that is just on dev called main and you commit all your changes there and then use deployment pipelines to move the code from dev to test to prod. So you can use a mix of git and deployment pipelines. You could ignore all deployment pipelines and only use git and have different branches one for each environment. Or

41:33 environment. Or you can have any combination thereof. You can have two branches and three workspaces. You can have all these different combinations of how you want to deploy and build code., and this is why I think the Git integration is so powerful because it allows you to build process around how your company develops. develops. Yeah. Yeah. And so there are some best practices, but you have flexibility here. And this is where I’m like when I talk to customers around using Git, I need to talk to your team and you need to tell me what are you doing?

42:03 need to tell me what are you doing? How are how do you like to build? How many developers are there? Because then I can decide whether or not your team fits in the beginner mode or intermediate mode or we need to start educating you to get into advanced mode depending on how your workflow works. This is exactly what I was going to say because and I’m going to start using plant-based puns for the remainder of the repository since we’re talking about branches without getting too much into the weeds of this. though is to your point if I start researching

42:33 point if I start researching git methods and branching methods unfortunately you’re going to find mostly development b pure developmentbased approaches you’re not going to find many if at all any business intelligence focused platforms because one the concept they don’t do it they don’t do it this is all new this is purely a software development right yeah application development web development% yeah and so That’s the unfortunate thing is we’re this is not a round peg in a square hole type of

43:04 round peg in a square hole type of situation. However, the resources available are this does work for our workflow. However, the appropriate strategies right now are being built, let’s say right now. Not that they’re not built at all, but I think that we’re in the process of finding the best approaches. To your point, I I’m doing the same as you where I’m talking to teams and we’re just having calls on here’s who our team is. This is what we do. we would like to do all the things. is like well no no you don’t have to do X Y and Z and I think a big part is here

43:34 X Y and Z and I think a big part is here start with basic I think because I want to get into the AI part and start with basic start with the basic commit can we handle writing right commit messages on a single workspace and handle collaborating that way because to me if we can’t do that branching is not going to work is it’s going to get way more complicated then we focus on simple dev branch prod branch on the same workspace, then I think you could get into more

44:04 I think you could get into more strategies that your team needs. But I really think right now, Mike, that this is a stepping stone. I don’t know, even if I had a pretty well,, well-run team that I’m going right into one of the more advanced branching. I think I’m making them do the stepping stones from the onset. I would argue, Tommy, you have to do that just because most developer teams in the BI stack have never seen this before. They’re they’re they’re trying to like we hear that gets integrated like we hear that gets important. We know we should be using it. We hear

44:34 know we should be using it. We hear other teams like the data engineering team or the software development team, they’re using Git, we should probably be using it too. Like so there’s like you need to outline the advantages of it, right? the the main things are backup and reverting back to old code. I think those are your two main resiliencies of why you want to incorporate Git into your process., the next thing is when you start using multiple people to build on the same stuff, having co-developers

45:05 on the same stuff, having co-developers on the same report gets way better at helping you negotiate whose changes are happening. How do you take,, Tommy, you work on page one and you added a visual. Michael worked on page one and I changed a visual that was already there. Well, how do we take Tommy’s changes and Mike’s changes and merge them together in a way that still allows both of our changes to be applied to the page? That’s where codebased Git development makes a lot of sense. And so that’s that’s the place where

45:35 And so that’s that’s the place where when you start increasing your team size and and I’ll also argue here as well, Git isn’t here to slow things down. Once Once that’s another misconception. Yeah, Git is here to increase the speed of your development team. Increase the quality of the code and the reports that you’re producing as well. Without proper process, process, you’re going to get reports that are deployed with accidental filters applied with matrices that are exploded with

46:07 with matrices that are exploded with filter panes that are opening and closing different pages. So the whole reason this Git integration exists is so that you can get a more consistent and faster development cycle and a lot of the Git stuff is about automation. How do we automate a lot more of these pools? How do we automate reviews? How do we get a human in the loop to help us make sure we’re building the right things? That’s where a lot of the Git stuff comes into place. And I think it’s why this is advantage is here. Yeah. a lot of good things but again to your point Tommy stuff we have to

46:38 to your point Tommy stuff we have to learn as a development team working in BI that’s how we have to think I think and my rule of thumb here and to close the the part around the branching and what can help with noise anyone who’s beginning to start or has the desire for their team to start with Git and source control and PowerBI I would say it’s never been more important to write down the two or three things you’re trying to achieve with it before you start doing And I think we work like that in general, but it’s never been more important with Git, especially or we’ll

47:09 important with Git, especially or we’ll say source control is probably the better term here. If you’re wanting to

47:13 better term here. If you’re wanting to start with source control for your team, it is never more important to write down the two or three things you want to achieve with it before you start any technology or any process because that’s going to dictate what you’re going to do. And start simple. I’d agree with that one., and I also will argue with that one, Tommy, like the process is going to be paramount for your team to decide on. Git and GitHub or Azure DevOps is just there to support the existing process that you already need. You already know you need

47:43 already need. You already know you need reviews on things. You already know you need to know what changed from state one to state two. These are all things you need them. Now, it’s a matter of how do you integrate that into your process, right? right? So, let me close off the question here. I’m going to go back to the the the user’s question here around how do you avoid the diff noise for people working together. I’m going to argue I believe from what I see you need to work on your branching strategy. I think you need to move away from the basic mode which is just turning on a GitHub workspace.

48:13 just turning on a GitHub workspace. Instead, you need to think about what is the branching strategy and how do I add the additional review process of okay developer you’re being requested to build something take a copy of dev build your own workspace with that branch make the changes and pull request into main into the into the dev branch because this will give you the ability for you to make changes and have someone review them and if there’s something wrong you’re supposed to push the work back to the developer and say, “You got

48:44 the developer and say, “You got everything right. The changes are there, but you added extra changes that we didn’t need. You expanded the matrix. You you did the slicer the wrong way.” You want to push that back to the developer and make sure that they get it right and have a reset something., one thing I would argue here is a great way to do this is if you have a page in a state that you like., well, let me not Great. A decent way of doing this, I’ll I’ll caveat this is using a bookmark. A bookmark is a great way to get a state of a page and keep the state

49:17 get a state of a page and keep the state every single time. As you add new items to the page, the bookmark will probably need to change, but using the bookmark to have a default state. No slicer is selected, no filter pane open. Like the bookmark saves that state and when you press the button for the bookmark or you click on that, that can be one thing that is done to that report page. That way any filters that were applied, anything that was added in there was just go go goes away. So yeah, one way to lower the diff noise you’re talking

49:47 to lower the diff noise you’re talking about here is to incorporate bookmarks I think in a very simple way to maintain them and that way when you have a this is the state of the page I need when I’m done building I click this bookmark the state is now consistent. I I think this goes perfectly with the other part of the question here too because this made me think of something I actually haven’t thought about, Mike. And I think I’m going to I’m going to ask you, Mike, for the remainder of us doing the podcast for the future of time, anytime we use the word AI, I want

50:19 time, anytime we use the word AI, I want to hear that cheer from the crowd. Oh, yes. Oh, yes. So So this brings us to AI. Yes. Yes. There you go. So [laughter] sorry, I was a little early. Say it again, Tom. So, this brings us to the conversation. Where does AI Yes. Yes. fit into the conversation. There we go. That was good. That was good. Much better. We just needed a little bit of a, that was a bad commit on my end. I had to I had to fix that on there. there. Very nice. Very. [laughter] Yeah. I did there. I I That was actually pretty good. So, I’ll [laughter] give you that pun. So,

50:50 I’ll [laughter] give you that pun. So, however, now there’s there’s something that the mailbag messages. I had Get Cub Copilot write me a script to rename the folders of visuals. Cool. Cool. Yes. Yeah. So this is cool, but what does that mean? This is also I think a lot of what you said about noise. Yes. Yes. Can be handled by AI. So yes, yes, we’ve talked about a lot of concept that was just AI and I know people are going that’s not PowerBI. That’s just you and your cloudbot doing a bunch of stuff and that’s cool for you building applications that I have not seen.

51:21 applications that I have not seen. Yes. Yes. However, all those skills translate to right now because guess what? I can create a skill or have an agent in GitHub, especially GitHub right now, that can automate and go through, not even automate, automate even like not the appropriate word, but go through my repository and have specialized knowledge and actions to do based on what type of repository this is. So what is stopping me, Mike, from creating a

51:52 is stopping me, Mike, from creating a GitHub agent or a clawed skill whenever I commit a repo to say if you find any report that has an expanded filter pane, close it. Here’s what the code looks like in for a closed pane and an expanded pane. Close these things. You expanded pane. Close these things., any matrix that’s expanded, which know, any matrix that’s expanded, which again, it’s in the code, say close it. make sure everything’s sorted by the main,, metric or what these measures are. And anytime something’s

52:22 measures are. And anytime something’s committed or before I commit this, I can run AI to do this, Mike. And what’s to stop me from doing that outside of just commit messages, which is what generally what people see AI and repositories for? What do you think of that? Well, Well, I’m now heck on this now. Yeah. So, so I believe AI is going to add a lot of capabilities to these diffs and capabilities. So, let me answer the question directly here. I’m going to I know we’re getting closer on time here, so we’ll wrap here a little bit,

52:52 so we’ll wrap here a little bit, but I want to first address the comment here around I had GitHub Copilot write me a script. Totally acceptable. I think this is the right way to go. GitHub in and copilot and agents in general will help you automate a lot of repetitive work and you’ll just be able to write the script, run it and it’ll just do all the things. Great. That’s what you that’s exactly what you want. You with this you now need to make this part of your process. So because of this because of the script writing capability

53:23 because of the script writing capability of making human readable messages, what you’re what I think you’re describing here is I want be I want to be able to look at the code that was generated and I want to know exactly without looking at the report. I want to understand what people are changing how they’re adjusting things directly in code that match to the report. PowerBI and PowerBI desktop builds a lot of random gooids and a lot of random numbers. My only caution with this is whatever your go- co-pilot made the script to do, you can’t have conflicting messages. Meaning

53:55 can’t have conflicting messages. Meaning the visuals on the page or the page names can’t be you. They have to be unique. They can’t be the same name over and over again. So, as long as your script accounts for the ability for you to make human readable names of pages and visuals, a good point, where everything is unique, you’re not going to have any problem. The script is no issue. I think it’s very helpful. especially for doing reviews. When we talk more about AI [screaming] Yep. When we talk more about how that

54:25 Yep. When we talk more about how that integrates with your process, you can have AI have AI integrate directly with your,, reviews, your pull requests. Like you can do a pull request and the AI can be the first thing to review, right? You could actually give the AI instructions. look, I’m expecting you not to have these settings set and then when the review occurs, the agent can come through and say, did any of these things change? Right? So again,, one thing that’s a really important concept here is when we have AI generate

54:56 concept here is when we have AI generate code for us, that speeds up our ability to make the code. The next bottleneck you will see is AI to review the code or people to review the code. And so when you’re talking about continuous integration, continuous deployment, when you’re talking about GitHub, you’re talking about Git integration, you need to think about as you build more stuff quickly, you have to speed up the entire pipeline all the way down. The code creation is going faster now because we get agents. We now need to figure out how to use

55:26 We now need to figure out how to use agents to help us review faster because that’s going to be the next bottleneck if we only throw people at the problem to get things out the door. And so I see agents being able to be able to to help us accelerate the review process. I see agents for us to be able to help us do better checks on the report. I see GitHub Copilot writing more scripts for you that you will run to to verify and clean and do things. there’s no reason why this script can’t be run as part of a GitHub action. Now

55:59 part of a GitHub action. Now I’m I’m describing something that can be more complex. When you create a commit message, message, GitHub actions can be used to Tommy, you’re done with your branch. You’re ready to commit your change. That commit the committing of your message to a branch now gets picked up by the GitHub or the Azure DevOps and now regularly runs a series of scripts that happen after that and make an additional commit. So Tommy, your work is done. you run the scripts

56:30 is done. you run the scripts automatically and then those scripts are automatically changing the files and creating another pull request back to the main repo. This is very common. You can do this and the agent using GitHub copilot can help you build the triggers that will enable all these other actions to run. Well, even more so too with GitHub, they also have the GitHub folder/ aents which will run in the same fashion that are a set of in a sense skills. Same thing. So this this whole idea of like there’s a whole bunch of automation that can be handled around agents using

57:01 that can be handled around agents using agents to build better process. So let me go back here to this comment. You had GitHub copilot help you write a script to rename the folders. Great. Your next step should be use that script as part of your deployment process. And because you’re now using git, you can now when someone makes a change automatically run the script. And then you’re going to have another commit that you will then want to pull requests back into your dev branch. So I think,, if I had to,, read the between

57:32 to,, read the between the lines here is this question or the user of this question is not using branching effectively yet. I would agree. Is not using actions effectively yet. So everything you’re doing here is the right approach, but you’re still at a basic level. I’d like you to learn more about actions, branching strategies, and incorporating them into your process so more of what you’re doing can be 100% automated. And now you have just a human in the loop that can say, “Okay, Tommy, you made a

58:04 that can say, “Okay, Tommy, you made a change. These are the changes that we’re not allowing through to dev because you adjusted something that we don’t want to change. Filter pain, all these things.”, also I don’t know if we can do this or not, but you might be able to even do things like have the agent run these bookmarks per page in order to get it set correctly so that way there are no filters applied when something along those effects or those lines. So those are other things that we can potentially take away from this that would also help us out as well. So let me just pause right there. Thoughts? I

58:34 Thoughts? I I’m going to say my closing thought too. So the first part of what you’re saying here in terms of Yeah, I would agree. We’re still on a basic level here. If you want to get away from the noise, branching needs to become something you’re going to introduce. But again, focus on what you’re trying to achieve with that before you just start doing it. Then it’s become a branch noise. The second part here is unfortunately Mike, you and I are not working in JavaScript or Python, a very common language that AI knows. So if I am going

59:01 language that AI knows. So if I am going to write something from AI that’s not just helpful but that’s more than part of my workflow and a dependent part we have to custom write our a agentic solutions here now but this is possible to your point Mike I can have an agent that runs I can write it but I have to write it based on my organization’s preferences that everything’s collapsed these little tidbits of what I want every report to have but it has to be custom written for the agent right

59:31 be custom written for the agent right now. Don’t rely on the just general co-pilot review or the general co-pilot,, agent to meet your needs here. Unless, again, unless you’re writing your PowerBI reports in JavaScript, which you’re not, then we have to write custom rules, custom skills, custom instructions that we want our agent to perform. But this is possible and I want to really focus on that for this user. What the script is trying to do, not

60:01 What the script is trying to do, not just writing a script, but what an agent can do if you’re using PBI and focusing on this. on this. Writing out your workflow, writing out what your best practices are, providing examples in that skill. md or agents. md file can allow you to get rid of a lot of the noise, too. However, it is custom that we need to provide. Yeah. And you’re talking more about custom agents is what you’re alluding to which I think is to me I’m not Mike if

60:31 which I think is to me I’m not Mike if I’m using a PowerBI repo I’m not using a general agent. I think the only solution is a custom agent. Yeah. And the one that I think I think I believe you can do custom agents in both GitHub and in cloud code. A lot of the standards that I’m seeing generated be like skills or custom agents. A lot of those seem to be coming from the claude code space. And what you’re talking about, Tommy, is VS Code, heavy coding. And again, I would also argue some of this stuff is pushing I would call the advanced side, like custom agents, doing reviews. You’re

61:03 custom agents, doing reviews. You’re going to need a little bit more there. I think maybe we could touch on a little bit of intermediate interactions, but in general, I think this is going to be more of an advanced mode to using custom agents. But that being said, you can use cloud stacking and GitHub stacking. And both those features are available inside VS Code if you’re using VS Code to review and and do reviews with your code and stuff like that. So that that’s something that exists there. once you have a repo with those items in it, you can then use them directly inside GitHub with tasks and agents and

61:34 inside GitHub with tasks and agents and reviewing. Everything exists as part of the repo. The repo again still is the source of truth, but when you’re pulling these things down locally on your machine or you’re setting this stuff up, you’d probably need to set up more than that inside VS Code on your machine to help it run. Just a bit of a push back. I just sent you something in the chat, but I’m going to argue this is intermediate. A GitHub agent can run in the repository. It’s not necessarily local or specific to cloud. For example, the example they give is you can have a GitHub agent file that says generate a workflow that creates a daily status report for the

62:05 creates a daily status report for the maintainer. use the instructions at you maintainer. use the instructions at the this file name and the agent know the this file name and the agent anytime there’s a commit will go through and go through that workflow basically on what the schedule is. So and that happened automatically in the repository not on my machine. Yeah I I guess I’m I’m calling it as intermediate dude. So I I’m going to say what but you’re using actions to do all this. No. No. So yes it’s an action. It’s part of the deployment script. It’s part of the YAML

62:36 deployment script. It’s part of the YAML file that’s happening. So right there, daily repo status. mmd on daily schedule, you’re actually using an action to do all this. So when the schedule happens or when the permissions changes, there is information that’s happening there that is an action based thing. It runs as a standard workflow. Yes. So Yes. So there’s some idea that you need to know about that. So I would only push that to more an advanced mode just because that is an actionbased thing that has to be configured. You’re right, Tommy. There’s a good standard example. They’re not

63:07 a good standard example. They’re not hard to do. It’s written in YAML. It’s very easy to understand. I agree with that. But I’m also going to say this is starting to draw on this actionbased experience. And I’m going to just say in my experience, you can do some simple actions at the intermediate level. This would be a good example of one of those. Yes, fair. But you can get really complex with actions and do a lot of things in the action space. And that’s where you get to advance mode, right? So much so much so to the point of you can go to your so

63:38 can go to your so expert mode of this would be go to GitHub create a new branch and as soon as you create the branch the branch goes to your workspace copies the items switches the items makes a workspace deploys all the code creates the connected workspace to the branch automatically. So what I would like to see is like more automation built into the program that says look when I go to GitHub and make a branch. There’s an easy library that just builds

64:10 There’s an easy library that just builds everything I want. Right? So the act of me creating a branch spins up everything I need, loads the data, moves the files, relinks the the lakehouse to the semantic models. everything I I want the entire automation to be completed and then I just say new branch Mike make new page and then I just do my work and then I say done and it commits everything back and then I have this easy review process to pull it back into the main branch right so that’s that’s expert mode of where this can go

64:40 expert mode of where this can go I’ll rephrase my statement yes GitHub agents are advanced but you still you should still be using it [laughter] I agree I agree that’s I’ll say my statement is you you need and I I’ll say this there there are some fundamentals in front of the agents that you need to get your head around branching commits and pull requests that stuff you’ve got to like get a pretty solid understanding and not just for you as a leader but you your entire team needs to understand these concepts once

65:10 needs to understand these concepts once you get those done then the agents become extremely powerful then you start integrating with actions and that and that’s the lever that you’re driving as the business team to really start speeding up and really leveraging this. So all this to go back to say to the two points the questions how do you avoid diffs incorporate I think more branching how do you use GitHub copilot to help you automate with scripting yes do it but lean on actions and how you leverage scripting in concert with actions to

65:40 scripting in concert with actions to help you build out the rest of the items you need. you need. So that’s where I’m going to land on this one. No I I think I said my pieces here so I love it Mike. We were like,, this may be a shorter episode. We got things to do. We’re already over. I love it. I love it. So, it was way longer than I thought it was going to be. [laughter] It always is. Awesome. Well, thank you very much. This is a great question talking about Git Git integration and how do you do diff and removing the noise from the diffs., I thought this was a great topic, really good fodder here for communicating about how this works for us., and then with that being said,

66:11 us., and then with that being said, thank you so much for listening. If you want to hear these episodes as soon as they come out, please think about becoming a member on the podcast. We’d love for you to become a member on the show down in our YouTube channel. That’s where everything comes out as soon as we deploy them and record episodes. You’ll get early content when we’re traveling and things like that as well. Tommy, where else can you find the podcast? You can find us in Apple, Spotify, or wherever 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 in a future episode? Head over to

66:42 about in a future episode? Head over to powerbi. tiff/mpodcast. Leave your name and a great question. And finally, join us live every Tuesday and Thursday, a. m. Central, and join the conversation on all of PowerBI tips social media channels. Oh, Tommy, I forgot to tell you. This is one that I think will be very useful for you as well., we’re going to automate this part. No, no, no, we we will not., I want to also be very clear here. We have been doing some bigger bigger updates to the PowerBI tips websites. This is a bonus for for those of you who who made it

67:12 for for those of you who who made it this far. We’ve been making didn’t shut it off. [laughter] People have already have already left and gone on. We’ve made some major changes to the PowerBI tips website. PowerBI tips website is now getting every single episode from the podcast on the PowerBI tips website. And not only is the episode being landed there after we do it, we have the full audio transcript also searchable on the PowerBI tips website. So Tommy, as of today, this is again a recorded episode. So as of March 2nd, we now have episode 400 all

67:46 March 2nd, we now have episode 400 all the way to the current episode 506 already automated and loaded as transcripts on the website. So if you go to powerbay. tips and you click our search icon, you can search for any phrase or keyword that Tommy and Mike have said on any podcast., so you definitely want to go check out PowerBI tips. We’ve made some big improvements there. So I just went over and I looked up the word in quotes game changer. So did I. [laughter]

68:16 So did I. [laughter] I want to show you my screen. So you can now see every single episode we said the specific word game changer. So you can go through and then on episode 430 491, episode 505, episode 478, and anytime you have a phrase or word that we’ve said, you can go look them up and see when we’ve said them. And also when you click on the articles after you find it, you can actually search the article itself and the article will also let where game changer appeared

68:46 let where game changer appeared and there’s actually a minute time mark stamp where you can go click the minute time mark. it’ll take you to the YouTube video and show you the exact phrase when we actually said it in the video on the podcast. So, pretty major change for us. We’ve been making a game changer on our website to now incorporate all this stuff directly inside the website as well. So, if you want to go search all of the text, we’re trying to get every single episode from the Explicit Measures podcast loaded and on the website. We’re going to have all 500

69:17 website. We’re going to have all 500 plus episodes added up eventually. We’re working through that right now., but be aware that if you want to go search all the knowledge that Tommy and I have been talking about and Seth from the older episodes, you’re more than welcome to go search things on the website. It’ll be fully searchable., and you’ll have all this really rich information about what we’re communicating about these topics and things as well. So, when you need to fact check someone at your company or you need to go find that episode, what did Tommy say that one time about Git and Git integration? You can now go search it directly on the website and you’ll be able to pull up every time

69:47 you’ll be able to pull up every time Tommy said the word git and I don’t know if it’s going to spell the word git correctly. so git t. Yeah, it’s there. It’s getting github and github check. So yeah, you can go ahead and talk and go search the website for git integration and we’ll now give you full search across all of our episodes. Oh my goodness. So anyways, that’s great. Yeah, it’s amazing. It’s It’s actually quite impressive to have so many tags and things across all of our episodes that are now out there now, which is awesome. Okay, great.

70:17 awesome. Okay, great. That being said, thank you all so much. Thank you for listening today. We hope you’ve enjoyed this episode. Please share with somebody else if you like this content and if you’re finding value from it. With that being said, thank you all and we’ll see you next time. Explicit measures. Pump it up. [music] Be it high. Tommy and Mike lighting up the sky. Dance to the day. The laughs in the mix. Fabric and A. I get your [music] feels. Explicit measures. Drop the beat. Now, kings feel the crowd.

70:47 the beat. Now, kings feel the crowd. Explicit [music] measures.

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.