The Changelog: Software Development, Open Source - Git your reset on (Interview)

Episode Date: February 15, 2022

This week we're joined by Annie Sexton, UX Engineer at Render, to talk about her blog post titled Git Organized: A Better Git Flow that made the internet explode when she suggested using `reset` instead of `rebase` for a better git flow. On this show we talk about the git flow she suggests and why, how this flow works for her when she's hacking on the Render codebase (and when she uses it), the good and the bad of Git, and we also talked about the cognitive load of Git commits as you work.

All right, welcome back. This is the changelog. Thank you for tuning in. My name is Adam Stachowiak and I'm the editor-in-chief here at changelog. On this show, we feature the hackers, the leaders, and the innovators in the world of software. If this is your first time here, welcome. If you haven't yet, subscribe at changelog.fm today we're joined by annie sexton ux engineer at render talking about her blog post titled a better git flow and it made the internet explode when annie suggested using reset instead of rebase for a better git flow on this show we talk with annie about the git flow she suggests and why how this flow works for her when she's hacking on the render code base, and when she uses it, the good and the bad of Git.

And we also talk about the cognitive load of Git commits as you work. And for our Plus Plus subscribers, you might notice there's an extent of six minutes and 40 seconds of runtime on this show. That's because we included a bonus segment with Annie. To get on that Plus Plus feed, learn more at changelog.com slash plus plus. Big thanks to our friends and our partners at Fastly. Our pod is fast to download globally. Thanks to their edge cloud network.

Check them out at fastly.com. This episode is brought to you by our friends at Sentry. Build better software faster, diagnose, fix, and optimize the performance of your code. Over 1 million developers and 68,000 organizations already use Sentry. That number includes us. Here's the absolute easiest way to try Sentry right now. You don't have to do anything. Just go to try.sentry-demo.com that is an open sandbox with

data that refreshes every time you refresh or every 10 minutes something like that but long story short that's the easiest way to try Sentry right now no installation no whatsoever that dashboard is the exact dashboard we see every time we log into Sentry and of course our listeners get a deal they get the team plan for free for three months. All you got to do is go to Sentry.io and use the code changelog when you sign up. Again, Sentry.io and use the code changelog. so we are joined by annie sexton a ux engineer at render and the author of a very interesting blog post recently get organized Organized, A Better

Git Flow. Annie, thanks for coming on the show. Yeah, thanks for having me. So a better git flow. I think we all have an idea about how to flow with our git processes and some could be better or worse or worse for me may not work for you. It's an interesting topic of a conversation, but really it comes down to communicating and collaborating. There's lots of things like who conversation, but really it comes down to communicating and

collaborating. There's lots of things like, who am I serving here? Who is this for? How do I do it? How do we do it together? How do we get on the same page? Curious how you came. We're going to talk about the nitty gritty details of this particular process and how it compares to other ways that you can get. But I'm curious how you came to this process, what your process was to land here and think, I got to write about this. Yeah, well, it really started with a coworker of mine, making some comments about some PRs that I was making. And he offered some advice about doing get differently. And up until that point, I really hadn't had a lot of coaching around Git aside from just the basics.

And it made me realize that there was a lot of things that I didn't understand about Git and that it was a lot less scary than I expected it to be. And it opened up this great conversation where he introduced me to his method of cleaning up his commits that although our our techniques differ a little bit he tends to rely more on using rebase interactive rather than just like a full-on reset but through teaching me all these elements of git it introduced me to this new way of approaching git flow that is way less stressful and also results in a much cleaner git history so we do want to talk about the process i want to go up a level for a second because i think there's an interesting meta game involved with regards to tools and processes and software in general which is opinionated versus unopinionated it's interesting that git is kind of unopinionated about how you use it considering the original authorship.

And sometimes I like, there are other ecosystems or tools that are like, hey, there is one way to do it, or there is one best way to do it. Go comes to mind. Python around their peps and like, this is how you write idiomatic Python. And then there's the Perl

and kind of the Ruby, Tim Towdy idea of of like there is more than one way to do it and we like that and i'm curious your thoughts on not just git because you can use git in many different ways in fact i think the linux kernel team like they still email patches around each other and stuff yeah to a certain degree but do you like the flexibility it provides or like if there's only one way to use git we wouldn't have to even have this conversation or your blog posts are like, this is just how you do it is this way. But instead, there's flexibility, which some people like, but also, now we have to decide how to use it. I'm just curious what you think about that trade off. Yeah, you know, I've thought a lot about this, because I'm going to use a comparison.

So I'm a full stack developer, really. But the two frameworks that I am most used to are React and then Rails. And those are kind of on two ends of the spectrum as far as opinionated stuff goes. Like how much structure do you get right out of the box? So with Rails, you do things the Rails way, right? Ruby, yes, there's lots of flexibility. But with Rails, there's a way you do things. You have the MVC flow and that's what you do. Whereas with React, I would say you have pretty simple concepts. And as a result, many React apps, there's so many different ways of structuring them. And it can be quite intimidating when you're

joining a new team and being introduced to a new React app that you're not familiar with, because everyone can do it differently. So you get more control with that. So once you're actually more familiar with the code base, and you're the one in the driver's seat making these decisions, then I think that flexibility can be really empowering. But sometimes it can be quite overwhelming because if there's not a precedent set, a reset, then that can be a challenging task. So luckily, I do think that Git is old enough that many, many people, many veterans of Git have tested it a lot of different ways, tried it different ways, and have some really valuable workflows that people can rely on. But it's still flexible enough that, you know, people can do it their own, do it other ways if they want to. So I think,

I tend to like to know how things work under the hood. I don't love when things just sort of magically work. And I think that's actually what made Git so intimidating for the longest times because there was just a lot under the hood that I didn't understand. And I would say that's not to say that I am now a Git expert by any stretch, but I know a lot more than I did then. So I think when you're able to, when you're just getting started, having some basic, obviously knowledge about Git, but also practices that other people have, you know, they have been tried and tested, can really help minimize the need to get Supercom,

you know, into the weeds. But then when you start to run into problems and you gain more experience with it, having that extra knowledge about how things work behind the scenes is really valuable. I will say that Git can be very, very intimidating. I was once on a team, this is back in the day, it was still remote too. It was Change Healthcare was the company I was working with. I was a contractor and I was change healthcare was the company i was working with i was a contractor and i was definitely not engineer i was definitely designer ux not to say that those folks don't get deep into get but like i committed code but i was mostly a front-ender i wasn't really trying to i was this is probably 2008 2007 so it was 2010 maybe i, maybe. I don't know. I don't know the exact year, but it was early

Git days. So like even my knowledge around Git was still young then. I had to rebase off and I'm like, oh my gosh, I'm my divergence somehow from the master branch. Like, oh my gosh, where am I at? And I'd have to like call in air support. And this is before Zoom. I think we actually did like remote meetings with like go to meeting or something like that and like had a screen share like that's how old how back in the day this was and I would just get into like situations where I'm like I just want to commit my code I just want to get my code into the repo and move along with my day because all my cognitive load and all my brain was on this git flow versus my actual job which was marking up the form, making sure it worked,

making sure the markup was right and the styles were right and nothing would break on mobile and different stuff. Like I was totally outside of my job's perspective just trying to commit code. And it's such an intimidating thing when you're in that position, when you're like, you know what?

I just want to get my code committed. I think unless you're Linus or maybe you predate Git and you're using CVS and you're in that position when you're like, you know what, I just want to get my code committed. I think unless you're Linus or you're maybe you predate Git and you're using CVS and you're using SVN and then you decided to switch to Git, unless you're one of those, you know, elder states people of our community, pretty much all of us have to use Git before we're going to understand Git, right? Like nobody has like a four year degree in Git and then they start coding, right? Like you're coding and you're like, I need to share this share this i need to i just want to get it out there and so almost all of us start just by memorizing a handful of things that you can do and having no idea how it works

yeah and just like here's this incantation and then when this messes up and the design the api of the command line tool, somewhat obtuse. It's gotten better over the years. It used to be very unintuitive how you would, for instance, delete a remote branch by git pushing the branch name with a colon in front of it. I still don't know why. There's a reason for that, I'm sure. But yeah, as you use it,

first you start off just memorizing the commands. Then you start emulating people who have been around longer. And then you start to kind of understand how it works. And it does become less intimidating. But you still aren't sure if you're using it right. Right. I've been using it since it came out. I mean, I knew a very, actually SVN was more intimidating to me than Git was

because I kind of learned Git as I started programming. I just had the right timing in my career and I had to do some SVN stuff because I was making WordPress plugins and I'm like, this thing's intimidating. But I've had enough experience with Git, probably however many years it's been publicly available, and I still question whether I'm using it right. Totally. I'm always in the docs, man. How do I revert that again?

What's the syntax to do it? It always seems to jump around. I have to in the docs, man. Like how do you, how do I revert that again? What's the, what's the syntax to do it? It always seems to jump around. I have to consult the docs for get constantly. So the, the kind of the standard typical, now that GitHub is established and most of us are doing PRS, or if you're on GitLab, you're doing MRS,

right? Merge requests, kind of a standard flow for a feature or even bug production, but bug production. That's what most of us do. It's a feature or even bug production but bug production that's what most of us do it's a feature branch but i got bugs alongside i remember i made an image one time of it was like a meme i was trying to get going of a it was like a ship that was shipping a ship like a not a cargo ship but an airplane we're seeing those and they're like carrying a little one on top maybe it's a rocket on top or something oh yeah and it was like this is your the the big one that was flying was like the feature

that you're shipping and then a little one along for the ride was like the bug that you're shipping alongside just because that's like it's there so yeah we we have bug production but the typical flow is i'm on my main branch i'm ready to start my feature i I create a feature branch. I check it out. So now I'm there. And I go about, I do some things. I make a commit. I describe what I did. I do some more things. I make a commit. I describe what I did. Maybe I have two of those and then I get back on the main or maybe I have 27 because it's been a longstanding deal. And maybe I've rebased along the way. Who knows what I've done. But I've had these commits, commits, commits, commits, and then it's time for a pull request

and a merge back onto the main branch. And that's pretty standard. There are other ways of doing it, there are people that don't do it that way, but that's what you're typically going to see out there. So when you talk about this better Git flow that you describe in your post, Annie, it's better than that is what you're saying.

So let's start with saying that flow right there. Like what are some of its drawbacks? Why is it not always ideal? Well, one of the issues is that it's much riskier to roll back commits, especially if your commits aren't as tidy as they could be. You know, when you have that sneaky little bug that's piggybacking on top of another commit that you didn't realize was there. When you roll things

back, then all of a sudden, you might be also breaking other things that if your good commits aren't as self contained as they ought to be, right, that can be really problematic because you can roll things back and maybe you fix the bug, but then introduce a new issue because something else was depending on the thing, the code that you just committed. So that can be problematic. I actually think that more importantly

is what makes this flow better is for PRs, the actual review process. I have, I think for most of my career, I've hated doing reviews on PRs because I've shared some code that somebody else wrote, and I don't understand exactly how everything is connected. And especially if there's a ton of files, it's not, and they don't give you a very good description of what's actually happening. Mm-hmm.

Their commits aren't actually broken up into logical steps because they just committed to save the work. So some things are sort of like half-finished between commits. And that can be kind of overwhelming to review. It's possible, obviously, but it's not the nicest process. So what I like about this Git flow is that it introduces a way to keep your Git commits really clean so that they are easy to revert and easy to review. So in like a pull request then with this kind of flow, would you, and Jared, in our case, I'm looking at like PR 400, move assets to S3, the most recent one. So in this case, like if, and you may not have this as a reference, but it's just a pull request and you can kind of see the atomic commits

over time from Jared and Gerhard, essentially committing code to our repository that moves our assets from a local disk to S3 as part of the process. So in this case, would you then just, would all those atomic commits over time by going the reset route, would those be gone? Well, hold on. She hasn't described the new way yet. Okay.

Sorry. I'm jumping ahead. My bad. So those are the two things. Reverting is problematic because you might accidentally revert something that you didn't think you were going to, right? Because the commits are messy and over time, especially the longer you do a thing, you end up doing things that aren't core to that feature, right?

Like they're just tangential. And then the code review is the same problem that manifests in a different way, which is like there's just more things in there. And that's probably the way that that pull request you're looking at, Adam, goes. But now describe this other way. So at least we'll have both methods on the table. Then we can discuss the differences.

So how do you propose or how are you doing it these days that you learned from Dan? Sure. So what I do these days is when I am developing a feature, fixing a bug, Git is really not something I'm thinking about too often. The first stage is just fix the thing, make the feature. And along the way, I still want to save my work, obviously, and push up to a feature branch. But I tend to just always commit things

with a WIP, work in progress message. And that's it. I don't try and describe what I was doing because all of that I intend to just completely rewrite. So build the feature, do the thing. And then when you're ready, and I actually didn't list this in the, um, in the article, but so the next step would be to do a reset to origin main or origin master, I tend to do a git fetch. And then I rebase on top of master, just a plain rebase, not interactive, just so I know that my stuff, like I have the most up to date version of code that I'm building off of. And then from there, I will reset origin master. Now, with Reset, without any parameters, aside from the branch that you're resetting from,

it doesn't change your working tree. So all of your files stay intact. Reset was always really intimidating to me. I think I was coached back in the day that things are irreversible if you use Reset and it's super dangerous. And it's not. It's really not,

there's a lot, there's actually very few things in Git that you can't undo. It's almost always in there. Yeah. It's in there. Yeah. Because it's, it's an append only database. So, right. So that's a huge relief. So I do all of my work in progress commits. Then I do a reset, which basically makes it look like you just made all of your changes all in one go without ever making a single commit. And then you can go through and pick out which files seem to go together the best, you know, and just group your changes into logical commits. And especially if you have an editor that makes this a lot easier, I think that I use VS Code and it's quite easy to just

to like, click through the files that I've changed, see the changes and verify that they should be grouped together. And then I make individual commits saying exactly what I did. So it's as if I was a perfect person. And I knew exactly what I was going to build, you know, every single line, and I committed them one after the other, as if I was like a robot or something. So it's quite nice, actually. You end up, the end result is a very, very tidy and well-organized Git history. But what I love about this is that they're completely separate tasks. When I am in development mode, I'm in development mode, and I am just problem solving. And I don't have to switch mentally to thinking about

Git as well, because all of that gets taken care of later. So that's personally why I really prefer this reset method. Yeah. So this is where Richard Hipp, who's the author of Fossil, would say, you're basically lying to everybody. You're going through and you're tidying up history that wasn't there and you're rewriting history. Because in Fossil, every commit that you commit is immediately shared over the network with everybody else. There's no hiding anything. Now you can go back and change things and append new things that fix those other things but they he and they believe in like let it all out there which i'm more on your side and i like to prepare

myself you know like i'm gonna get cleaned up before i go to the restaurant so that's very interesting that now comes into the conversation that adam was getting to with collaboration because you have this feature branch along the way and this is pushed remote I assume like you're not keeping that on your laptop right no you aren't or yes you aren't I asked it in a weird way oh I know I am pushing it to a remote branch you're sharing okay I asked in a double negative fashion sorry yeah no I'm sorry so it is shared and then when it comes time to open a PR, then are you like force pushing? Like, is that branch only there so that it exists in more than one place? Or is there collaboration

along the way during these whip commits? Or are they just for you? The whip commits are just for me. When I push up to the feature branch, sometimes I do have, I am pretty comfortable doing a force push because that's usually when I have gone through and made my cleaner commits afterwards. So there's no harm in doing it that way. Dash to edge force is so scary. I've gotten a lot less intimidated by it since doing it this way because I know exactly what I'm changing. Sure. And it comes down to knowing how Git works and knowing that and being comfortable.

Because if you have a scalpel and you don't know it's sharp, you can cut somebody, right? You're still holding the same object. It could be a dull scalpel. It could be a sharp one. But if you don't know how sharp it is, then you can still do some damage. Right. Then if you're using a force push in this case, so essentially this forces a rewrite to the remote repository. And that forces everybody else who tracks that repository to adhere to whatever you, like you kind of revert some things.

Does it only happen in the branch then? Yeah, it only happens in the branch. It's just the branch. That's why it's pretty harmless. So if you're only doing that to a branch, that's different. Yeah. I mean, because if you're doing a dash force, dash dash force on master or main. No's why it's pretty harmless. So if you're only doing that to a branch, that's different. Yeah. I mean, because if you're doing a dash force, dash dash force on master or main. No, I would not do that.

Right, right, right, right. No. Somebody's upset. Yeah. A lot of people are upset. So, you know, dash dash force is there for a reason. And so as long as we know why you're wielding that scalpel, you're doing it to precisely do what you want to do, it's totally fine. And in the case of a

remote branch that's there merely for you to not have a single point of failure it's there so that you can you know work on an l square or whatever but it's still just andy's code she's working on this feature and if you go and look at it you're gonna see a bunch of whip commits that are just like okay you're not going to collaborate on that but once you get to the point where you've done all of that, you've done your reset, which by the way, I learned about this use of reset from this post. So thank you. Like I said, I've been using Git for many years, but I've only ever used Git reset for to like unstage some stuff.

I can't remember what I use it for. But this is like all the commits that you did between when you forked, not forked, when you branched and what's there now assuming you've rebased so you have the latest all those commits quote-unquote disappear and everything goes unstaged but all your changes are right there right and so it's like your code is still changed but your history is now quote-unquote gone it's hidden and you can recommit it logically and it's a beautiful thing right like you basically exactly, it's hidden and you can recommit it logically. And it's a beautiful thing, right? Like you basically cleaned up your room and, you know, and got dressed and now you're

ready for the world to see your stuff. Right. And I would say that, because I've heard some people complain that, well, that sort of defeats the purpose of having those point in time commits to track like exactly actually what happened. And I would say, well, what's the point of having those early timestamps, because they don't actually serve your teammates, what actually helps your teammates understand and navigate the changes that were made is when they are actually properly organized. So the fact that you sort of like erased, I'm using quotation marks, or erased those old commits. For Richard's sake, yes. Erasing the history.

I was also doing air quotes and I forgot to say it out loud because you're watching me. But, you know, the fact that you quote unquote erased those old commits doesn't actually change how other people will interact with the code. But in fact, it makes it a lot easier. Because the fact that you did it at a certain point in time, I would argue doesn't really matter as much as the changes that you actually made. And then the order that they were committed, the order is really what matters. And so when you know that, and as long as you're committing them in an appropriate order, where you're not leaving the code in a broken state, then you're still keeping the code in, you're keeping the repository in a clean state that's easy to review and easy to manage for other teammates as well. This episode is brought to you by our friends at Influx Data.

Act in time. Build on Influx Data, Act in Time, Build on InfluxDB. This is the platform developers use to build time series applications. And to them, joined by Barbara Nelson, VP of Application Engineering. Barbara, we're working together to share some behind the scenes there at Influx Data. And one of the things you've shared time and time again is this idea of meeting developers where they are. What do you mean by that? This is really important to us that we're not expecting developers to make wholesale changes to their product or application to try and leverage the power of our platform. So it's a mindset, both in terms of the capabilities of what we deliver and how we deliver them.

So, you know, why do we have the client API in 12 different languages? Because we're meeting developers where they are in 12 different languages. We're not going to tell them, if you want to use our platform, you have to use Python. If you're using C-sharp, you use our platform in C-sharp. That mindset of meet the developers where they are means we sometimes end up building multiple versions of the same thing, but for different target audiences. So a lot of the capabilities that we expose in our web UI, we also expose in our VS Code plugin. Some developers are spending all their time in VS Code, so they want a solution that works where they are today. And so that is a really important focus that we're not trying to tell the developers, you know, you need to change to use our platform.

It's what are the ways that we can make our platform accessible to you the way you work today, the way you develop your application today. And so that mindset has been really important. It means that we often develop capabilities at different levels. So we'll have the same capability. You can access it through our web UI. You can also access it through a set of command line scripts. You can also access it directly via API calls. And all of that gives the developers the flexibility to use the platform the way it works best for them. Okay. You heard it here first. Meet developers where they are. That's the mindset of Influx Data.

How they build, how they ship, how they think about DX in terms of you using this platform to build your next time series application. Bring your preferred languages. InfluxDB integrates with 13 client libraries. C Sharp, Go, Ruby, of course, JavaScript, and so many more learn more and get started today at influx data.com slash change log again, influx data.com slash change log. So, Annie, I mentioned somewhat prematurely this pull request that we have out there. Pull request 400 on our main repository. So if you go to GitHub user thechangelog slash changelog.com, that's the repo. And then port request 400 audience.

You can track along with that. We'll also have a link in the show notes, but this is a port request recently. And Hey, by the way, we talked about this on ship it episode 40, our Kaizen episode. If you haven't listened to ship it yet, that's a great episode to begin at. We talk about the behind the scenes here at changelog and how we actually improve our infrastructure and platform. And this is part of that. So we talked about moving our assets to S3.

That's pull request 400. And what this pull request has is an opening commit and comment from Jared saying kind of what we're doing with this pull request, stating the case. And along the way you see, and because I know Gerhard and Jared did not use your Git flow, I know that these are atomic commits in the, I guess, normal fashion Jared had mentioned in part one. And so what you see here is you see collaboration between Gerhard adding commits that add cross-plane features to our Linode provider. And then all down the line, you see different comments and commits. You see Jared's atomic commits on dropping waffle to replace arc and a bunch of other stuff that essentially make us move our local assets from a disk at Linode to S3. And what I'm curious of, since I know they didn't use your flow and we talk about collaboration with the broadcast, because in a lot of cases you do have a lot of collaborations. Sometimes they're single

individuals committing and it's just a review. So it might be you committing a feature and your teammates coming on and you want to organize things. So it's easier for them to do the review because that's never fun to do a unorganized review. So how does collaboration happen? So if this is an example of non-ANI workflow, if we can call it that, let's just say, you know, if we know it's not that, how do we then collaborate in your style? How does it change? So I think that the reset method that I outlined could technically work for this. It might be a little trickier because, as I said before,

you tend to, when you're cleaning things up, you're doing that force push to clean up your feature branch. And I think that can get tricky when you're cleaning things up, you're doing that force push, right, to clean up your feature branch. And I think that can get tricky when you're collaborating with other people. Now, the way that I have collaborated with others is we just each keep our own branches and they exist on GitHub as completely separate branches.

And we might reference our branches and pull requests in another pull request. And so we have a conversation there. But I think that actually maybe a rebase interactive might make it a little easier. It's still the same sort of principle where you clean up your commits afterwards. But doing a rebase interactive might make it a little bit easier when you're because it sounds like you guys are working on the same branch. Is that right? Or two people were working on the same branch? Yes. So let me describe how this went down. So you'll notice for

people who are paying close attention and actually click through to the to the URL that if you look at the commit list, which is 31 commits on this, the first commit is on January 16th, 2022. And if you look at when I opened the pull request, I opened it on November 29th, 2021. So there's definitely some rewriting going on at some point anyways. I think you can see how it's like Jared authored and Gerhard committed. So somehow Gerhard did something that changed the timestamps around anyways. But the way that I generally work, and this is a feature that I put in 90% of the work, opened up the pull request, and the rest of the work was like, now we need to kind of reconfigure and change some environment variables and some part of our infrastructure deployment stuff

before we merge this so that it will go out smoothly. And so I did the feature, and then Gerhard came in later and kind of did the end things. And if you scroll to the bottom of the commit list, you'll see it's pretty much Gerhard by himself doing some stuff. And I'm not actually sure how you do those. Jared Santo authored and Gerhard committed. It's like a sign-off or something you can do inside Git

and somehow GitHub is doing a good job of describing that. But the way I work is actually somewhat similar to the way that you're describing until I get the pull request open and then I just kind of go chronological from there. That's where I was confused with this

process once you've shared and i assume there's going to be follow-up commits based on code review maybe you have a teammate who's like hey i'll hop in and do something and i guess once you you do your reset and your rewrite and you get it all logically awesome and submit it for code review from that point on do you just do commits naturally and push them to the branch or are you still going to do a rewrite or a reset at the very end when it's time to merge um it depends on what changes i'm making if it's a we really need to rethink how we're designing this component or if if it's a simple like oh there's a there's a typo if it's a simple like, oh, there's a typo. If there's a typo, let's do like a git commit amend, honestly,

where you're not even, I mean. So you're force pushing all the time. I mean, if I'm the only one making the changes and no one else is making commits to this branch, I don't think it matters that much. But if other people are making commits, that's a little bit different. Right. If you know there's collaboration, you can't do force because that really but if other people are making commits that's a little bit different right if you know there's collaboration you can't do force

because that really would it would ruin their branch they would be divergent to the branch at that point because it wouldn't match up you could still do it it would work it just causes more pain it does and so it's a matter of how much do you need to rewrite

how much are you collaborating how much is the work shared between two people? Because if somebody else, if there's quite a bit that is of work that is shared, then you'll probably want to do fewer forces. And if you do force pushes, you have to stay in communication with each other. So it's a matter of, you know,

do you work in different time zones or are you just like, it's the same time of day, you're on Slack at the same time. So you can just be like, hey, by the way, I did a force push, you're gonna have to do this. So I think it all sort of depends on how closely are you communicating with your collaborators? Is it super asynchronous communication? If so, then you might be able to want to be a little more considerate about the commits that you make. Because you're right, force pushing can be quite extreme when somebody else is also touching that same branch. So it really depends on how you're working together and what they're willing to do. Sometimes a force is just absolutely necessary, and you can just let them

know. But I think a rebase would be a good way of sort of more delicately handling these. It does require a little more, you know, tweaking and knowing exactly what to do when you're doing an interactive rebase to say, like, you know, fix up this, squash this, rearrange these things. But even then, I think that can still, I don't think that would result in a first push, but that can help, I would say. So a lot of people have brought up, you know, you can use rebasing as an alternative. And I think this is actually a really good use case

for when you might actually want to use rebasing instead of like a full reset. Let's play a little game then. Let's imagine we're a collaborator with Annie on a port request. Okay. And for some reason she has to do a force push. What then? And Jared, I'll say what I think, and we'll see who's better. Yours may be better.

Let's assume we're the collaborator. Okay. I've got, we're on the same branch, Annie and I are collaborating, and she has to do a force push. And she messaged me in Slack, and she says, hey, Adam, sorry, did a force push. I think what I would do then is if I had some – Throw a temper tantrum. I might be upset, but if you know your git, if you know your git, then maybe there is no tantrum. It's just like –

They're just kidding. It's just more like a blip of cognitive shift to get my git right and then get back to my – I'm going to just keep saying git. Not G-E-T, but G-I-T. I'm going to get my saying Git, not G-E-T, but G-I-T. I'm going to get my Git stuff back in order. I think what I would do then is if I've got some, let's just say I've got my own WIPs locally, I might, if I know I've got, she's got a force out there and I've got to essentially consume what she's got because I'm out of sync. I would probably maybe keep my work in progress commits. I essentially want to rebase her branch, right? I want to get my, I want to have my changes in place,

probably commit all my changes, even WIPs or actual messages, get all my stuff staged actually in my commit log. And then I want to rebase that branch back locally, all my changes back onto hers. And that's essentially how you how you deal with the force right because yeah otherwise if i didn't do that sure git would yell when i try to push to that branch and say i don't even want to say i'm out of sync or i'm ahead or i'm behind or something like that from the head of the of the branch is that how

you would do it jared did i win likely how do you win if we're both gonna do the same thing well that's the truth is that the right way since you could probably do it, Jared? Did I win? Likely. How do you win if we're both going to do the same thing? Well, that's the truth. Is that the right way? Since you could probably do it different ways, how would you do it? Well, another way you could do it is basically unstage your whips and stash them and pull and then unstash. I do that a lot. I'll just stash, pull, or rebase if you have to, and then unstash. Because if those are whips anyways, you don't care about the history of those commits.

Right, right. You could do the reset back to the SHA using Annie's method. Back to a known SHA prior to Annie's current head, right, on the branch. Then you can make one gigantic commit of that. Maybe a massive WIP versus many WIPs, right? Sure. Do another rebase off of her branch. You've got that.

Or you could do the stash. Yeah, see, that's the thing we get is like, if you know the different tools and how they work, you can get more comfortable. That's why I wanted to play this little game. It's like, there's like probably three or four different ways. None of them are right. They all work. They all get you back to work.

It's a matter of which tool you're most comfortable with which can you do quickly so that uh annie's interruption cognitively doesn't shift you away from your work right exactly and this is actually i think this brings up a question of what's the best way to collaborate at all is it always that you're on the same branch or because in a situation like this it depends on if you're touching the same branch or because in a situation like this, it depends on if you're touching the same files, then it can be a little bit tricky. But if you're not,

I think that there's always a benefit in just having completely separate branches. I've never done that before. So this is like new thought process to me. I don't see why it wouldn't be good. I just have never done it that way. When you're, when you're touching the same files,

it can be tricky. And I would probably reevaluate who's doing what. Your life. Because it's really... Trying to reevaluate if this is better left to one person or if it really needs to be collaborated on by two people. But if you're touching relatively different files, then just creating different branches and merging them in separately, then that also saves you a lot of the headache of what happens if I force push.

I know a lot of people have opinions about not force pushing and they're welcome to those opinions. My opinion is once you have more than one person pushing to the same branch, you should be done with your force pushing. Right, right. Exactly. Just because it's causing them more work if you're doing that. I have no problem with it should be done with your force pushing. Right, exactly. Just because it's causing them more work if you're doing that. I have no problem with it if you're on your own branch. Yeah, same with me. I mean, I'll force push all day long to my own repos.

There's nobody there to get upset. Pushing nobody around. So most of the collaboration that I do on small teams, our teams is like one, two, sometimes three people. And I know there's people that work on larger teams and collaboration is harder amongst more people. So I'm not sure how those processes scale, but most of what we do is tag team. So it's kind of like I do some commits, I've pulled the pull requests open or something, and we talk about it. And then it's kind of like tag, you're it. And so now here comes Cody is an old collaborator of ours you know he he did a lot of

kind of the the ui of things that i would build the back end for to create a full stack developer between the two of us and it's like hey your turn let me know when you're done doing some stuff and then he works on that same branch for a while and then he says you know passing it back to you and then i pull and work and so that's how a lot of my collaboration has been is kind of just like one, you know, pass the baton more so than like we're both working simultaneously on the same feature. And so I think in that way, one branch makes a lot of sense.

But if you're simultaneously collaborating on a feature, maybe different files, but you're not passing the feature back and forth, I can see where two branches or N branches for that many collaborators is a better flow. So tell us about the teams that you work on and how many collaborators you usually have and what's your setup usually like?

Sure. So at Render, we have a lot of people working on many of the different repos. And we tend to have one person per branch. I don't know that there's many people who have multiple people working on the same branch. In fact, most of the time we tend to preface our branches with our names, Annie slash whatever feature we're working on. Gotcha.

And in that regard, it's quite easy to keep our work separate. And there's no real mix up. And the collaboration that we do happens more in the form of pair programming and the conversations that actually happen in the PRs. So that's what collaboration looks like. And if it's a bigger feature that can't be completed in a single branch, then I'm not actually sure if we do this, but I just thought this might be an option. You can have sort of like a long running feature branch that you then diverge from individually with.

So you've got the main feature brands. Right. And then. Like a pseudo main almost. Right. Exactly. Essentially staging, but like feature specific right so that would be another way of having people have their own branches they can manage that they then have people review and then you merge those

into your sort of like main feature branch does that make sense and then eventually that can get merged into main as well so that has been what collaboration has looked like in the past for me. I actually don't have much experience working directly on the same branch. It's usually been you have your own feature branch that only you touch. And if somebody else is messing with it, it's because they're helping like solve a bug that i can't crack yeah and then when we figure it out then maybe they make a commit or they just tell me what they did and then i write it so i'm curious which is more common so if you're listening and you're like i do it our team's work render style any style which is each person has their own named feature branch named after

themselves and collaborate that way or more like the way i've described where it's tag teaming the same branch and passing it back and forth or collaborating that way let us know in the comments or hit us up on twitter and just send us a note what style do you do because like i said there's more than one way to do it and this is a way that I actually haven't heard anybody elucidate in the way that you have apparently totally common at render. Maybe it's totally common, a lot of shops. And it's just that we don't talk about these things all that often. So that's, that's pretty cool. I think back to the flexibility of get though, I think that's what makes it so cool that it is so flexible, you know, back to your example, Andy, between react and rails, like, you know, there, there's just so much you it is so flexible. Back to your example, Annie, between React and Rails.

There's just so much you could do with it. And so I think that's why it's such a good fit and why it's actually lasted so long. Why it won and why it's lasted, despite Reset seeming scary because of what it actually names or the way you would delete a branch to a remote repository by pushing and all this, like despite the odd API sometimes with Git and some of the scary innards, it's so flexible. So it lets you and your team work the way you want other teams work the way they want. And it's really about leveraging its,

you know, its tooling inside of Git to work the way you need to for a team to collaborate and the way it actually works out on GitHub itself. Okay. And I would say that one of the benefits of having a lot of different ways to achieve the same objective in Git is that it also means that if you screw up,

there's a lot of different ways of fixing it. Yeah. And that's really nice. And so there's a huge relief when you start to learn more about it and learn that it's really not as scary. It definitely can seem scary, but the complexity is really beneficial

when you realize that a lot of these things are sellable. As long as you know how or you have somebody who can help you. This episode is brought to you by our friends at Fire Hydrant. Fire Hydrant is the reliability platform for every developer. Incidents impact everyone, not just SREs. Fire Hydrant gives teams the tools to maintain service catalogs, respond to incidents, communicate through status pages, and learn with retrospectives. What would normally be manual, error-prone tasks across the entire spectrum of responding to an incident, this can all be automated in every way with FireHydrant.

FireHydrant gives you incident tooling to manage incidents of any type with any severity with consistency. You can declare and mitigate incidents all inside Slack. Service catalogs allow service owners to improve operational maturity and document all your deploys in your service catalog incident analytics like extract meaningful insights about your reliability over any facet of your incident or the people who respond to them and at the heart of it all incident run books they let you create custom automation rules to convert manual tasks into automated reliable repeatable sequences that run when you want create slack channels jira tickets zoom bridges instantly after declaring an incident now your processes can be consistent and automatic try

fire hydrant free for 14 days get access to every feature no credit card required get started at firehydrant.io again firehydrant.io and also by our friends at mongod the makers of MongoDB Atlas, the multi-cloud application data platform. MongoDB Atlas provides an integrated suite of data services centered around a cloud database loved by millions of developers for its intuitive document data model and query API that maps to how you think and code. When you're ready to launch, Atlas automatically layers on production-grade resilience, performance, and security features so you can confidently scale your app from sandbox to customer-facing application. As a truly multi-cloud database, Atlas enables you to deploy your data across multiple regions on AWS,

Azure, and Google Cloud simultaneously. You heard that right. You can distribute your data across multiple cloud providers at the same time with a click of a button. And the next step is trying today for free. They have a free forever tier, so you can prove to yourself and to your team

that the platform has everything you need. Head to mongodb.com slash changelog. Again, mongodb.com slash changelog. so annie in the pre-call we talked about your twitter bio and uh i will reveal some things about you to our audience that may not know you yet and will know you after the show may go to your twitter bio and follow you one of the things you say is React.js is the first thing.

And then you say ADHD brain, space, lover of neuroscience. And you obviously put the brain emoji there. So that's beautiful. And then UX engineer at Render, previously at Heroku. She, her, your pronouns, some Japanese. I can't read, but you can. And then opinions of your own, blah, blah, blah. And that's actually what it says, blah, blah, blah.

So I want to bring the neuroscience in there because I think one outlier here that we haven't really talked about that may not even made it into your post, I just looked to see if like cognitive was mentioned, is the load that thinking about your commits as you make them does to a creator's brain, right? Whether you're a front-end designer

or a front-ender or a full stacker or back-ender or an API, it doesn't matter. Right. If you're using Git, which you probably are. We've demonstrated that by this conversation. You're thinking and commits. You're thinking in code, but you're thinking commits. If you're committing back to a repository, whether it's yourself or the collaborators, like how does the cognitive load tie into this? And maybe why you even call it better, a better workflow, a better Git flow. Sure.

And I do, I would have a disclaimer that I would just say it's better than the one that I outlined earlier, right? Not that, you know, not that it's better than everyone's Git flow, just the one that I, the simple one that I outlined in the post. Right. But yeah, there is a good amount of mental shifting that is required that I think many people sort of take for granted that happens when you're both developing a feature and also thinking about, wait, should this be its own commit right now? And that ability to pause and shift your focus and think about something else requires a lot of working memory, sort of your

short term memory, and a lot of executive functioning, which if you have something like ADHD, or you have another disorder that, you know, deals with executive dysfunction, then that might be a little bit difficult. And I'm, I do not speak for every neurodivergent person, but I have just found for me that that is a moment when it's advantageous to let myself just hyper focus on writing my code first, and then worrying about how I'm going to organize that and get later. Because that mental shifting is not something that I'm great at. It's something I quite struggle with due to my personal brain chemistry. And as a result, I think it's great that I'm able to use this other flow that really works a lot better for my brain. And I think other people might not want to do it this way

because their brain is a little bit different. And in fact, many people responded to this post bringing up rebasing as an alternative. And rebasing is a really great option. We talked about it before. And I think that rebasing can actually be faster than the reset method that I've mentioned, as long as some of your commits are able to be left relatively intact. So if you have to, the thing is, when I'm writing code, it's really difficult for me to also keep in mind whether or not I should be committing at the same time. I tend to just commit just to save my work along the way

and then organize things later. But if you're able to do that little mental shift easily and it's something that you are quite practiced at, and it comes naturally for you, then it's a great tool. Because the more commits you can just leave intact, the easier it's going to be to clean up later, obviously. And so that's where rebasing interactively could be a great option. But I find that for the effort that it's worth for me in the moment during development, it's quite disruptive. And so taking this approach is a lot more manageable for a brain like mine. Can I define executive function for us? That way we have our audience kind of caught up

on some of the neuroscience things around it. So executive function, thanks to understood.org for making this definition right there when you Google executive function. So thank you to this. This is not me bringing this out of my own memory. I'm leveraging the Internet. So here we go. Executive function is a set of mental skills that include working memory, flexible thinking, and self-control. Another post goes into deeper details, which is the seven executive functions. And they include proficiency and adaptable thinking, planning,

self-monitoring, self-control, working memory, time management, and organization. And as you, as any creative, as you're like thinking like you're these different executive functions are constantly being taxed. You may be thinking I'm hungry. So that's self-control. I'm like, do you want to eat? Self-monitoring, am I actually hungry? Time management, is it time to eat? You know, all these different things that sort of like are monitors as you're, as you're just doing life. So these things get taxed by anybody. So from your perspective, then what you're saying is, is when you work, it's just easier for you to sort of like blaze through things without taking that time to have to stop.

It keeps you in flow for you. And you could just, maybe you have a, uh, an alias where it's like WIP and you move along, you know, I don't know, but whatever it is, your pauses are less. Maybe they're just as frequent, but they're not that long. So your time between creative, get, commit, and then back to creative again is minimized. Exactly. And executive functioning, the main thing that I find difficult in switching between thinking about development versus my commits is that transitioning skill. That is something that if you have ADHD, it's something that we tend to struggle with. Not with everything. And so the ways in which your executive function impairments show up

for everyone with ADHD is quite different. And ADHD is not the only disorder where people struggle with this. It's just the one that I'm the most familiar with. But that ability to transition is a skill that's managed in like the prefrontal cortex. It's all part of your executive function skills. It relies on dopamine and norepinephrine to be able to shift that way. And if you are deficient in those abilities, then it can be quite difficult. So it's really, really great to find different ways of working with your brain rather than expecting it to do work in ways that just it wasn't really built naturally for that. So do your whip commits literally just say work in progress? Or do you also I've done

I do this locally as well, but I'll kind of leave myself a breadcrumbs sort of a certain degree. I actually do it less efficiently than you I have like one whip commit that I just amend to so I'm kind of just like, I usually leave in there like what I was doing or what I'm thinking, notes to future me. And I'm curious if you take time to do that, like, here's what I was doing or what I'm thinking notes to future me and I'm curious if you take time to do that like here's what I'm trying to accomplish or here's what I did during this hour or if like literally just like whip whip whip whip and you leave them blank and for later I just use whip whip whip okay and so if I'm if I want to keep track of what I'm working on for myself I just use like a notes app or something just because it's,

it's serving a different purpose. It's not there to keep my history in check. It's just, you know, I really just need to keep track of like, what was the bug that I was on? What was the thing I was struggling with? But I will say,

I know a number of people that do write little notes in their web commits. And then later when they choose to do a rebase, right. It's a lot easier to rearrange things as needed. Did I guess it right that you have an alias or do you not have an alias for making your WIPs easier? Do you actually type G-I-T space commit dash M? I should. I should have an alias.

I really don't, though. That's a good idea. That's a good idea. I'll do that. Let's get you an alias. Maybe GWIP. I don't know that's a good idea that's a good idea i'll i'll do that let's get you an alias maybe maybe g whip i don't know just whip just whip maybe it's just wip yeah it's so fun to say and yeah to type as well so what's the time span at which you are doing this and at what frequency because at a certain degree if you're literally just whipping in order to have a backup or something, you're basically like just hitting the save button again in Git, which means you really don't trust your SSD, which is fair, I think. But is this over the course of hours, days, weeks, months?

Usually hours. Usually hours. Definitely at the end of the day, at the very least, too, so I can push up to my future brands, because I don't want to lose any changes. But it's really whenever I remember and, but because it's all going to get rewritten, doesn't really matter how frequently I do it. So as long as it's at least at the end of the day, but it's really just for saving your work at that point, if you're doing it in the method that I've described, right, you can actually write a watcher to do that for you. Yeah, I could run every 30 minutes. And if you that point if you're doing it in the method that i've described right you can actually write a watcher to do that for you yeah and it could run every 30 minutes and if you

like if you have on stage changes every 30 minutes just do a whip commit because there's no abnormalness to any of your whip commits yeah it's like so who needs an alias i just get a boom right we're automating any's world but I would say that does kind of marry you to the reset option. Like you really, you know what I mean? You wouldn't want to. Right. Those whip commits are going to be kind of useless if you're doing a rebase interactive. Let's keep the human in control here, Jared.

Come on. I'm trying to help her out. I'm trying to get her as efficient as possible. Because then your cognitive load never switches. Exactly. That's true. Because even like switching to the command line and typing up git commit dash m. know but then i would just like forget how to use git it'd be terrible it's all it's all trade-offs all trade-offs so how has the community responded because this was

been out there a couple of weeks we've covered it in changelog news people been reading it there's twitter responses i think there's a hacker news thread probably what has been the consensus the response because people really do care about their get and people do think they have the best flow yeah and you have a better flow you don't specify better than the one i'm giving the example to exactly exactly well that's just what are people saying that's just to give it a catchy title that's all that's for totally it's been a really mixed response i think i would say most people have responded fairly positively saying, I like this, I do it slightly differently. That's been sort of like the general response.

And a lot of people have responded that they tend to rely more on rebasing interactive and get squashes. Get squashes can be really helpful. I am not the biggest fan because I like to have a little more granularity in what my commits are defining. So describe a Git squash and how that's different than a rebase or a reset. Like usually a Git squash is what you might do when you have your PR, it's been approved. And to squash it, rather than having all of those individual commits, they all get squished into one commit that contains all of those changes. And so it simplifies things. Right. But then you lose that granular view of what has actually happened.

So I prefer not to use GitSquash as much. But for some things, it can be kind of nice but i i totally understand is git squash a first class citizen in vs code in terms of like it's like i think since you mentioned you use vs code it's pretty easy to like hit the plus sign on a file to stage a change on like if you know you worked on two files and you're reviewing your reset for example it's like okay those two files go together these two files are these three files go together like you just hit the plus sign and like easily do that i just wonder if even if a squash is like a first class system in the workflow of vs code i don't think it is to my

knowledge i don't know well i'm also i'm mostly familiar with relying more on vs code for knowing what to stage and what not to stage because it it's a lot easier to be specific about which files, especially if you're doing this process where you're only committing, or excuse me, only staging some of them and not all of them. So I'm not sure. I wasn't sure what your flow was particularly, because that's how I tend to use VS Code. I'm usually command line junkie with Git,

unless I'm already in that visual mode and I've got my commit sitting here and you know unstaged my will just hit the plus button on these two files and just commit them right there because i happen to be there now i also use sublime text i occasionally use vim too so but most of the time i'm doing commits into a repository it's it's been and has been vs code primarily. Early Google search says you need to get Graph extension for this in VS Code

but that's also 18 months old so who knows they could have brought it into the main editor. Squash is good if you know. That's the thing. Again, there's no one way to roam. There's just so many roads there. If Squash gets you there it's basically the same as doing a reset and choosing files.

I mean, it's almost the same. The end result is almost the same, right? Like you've done away with that actual commit. If you have three individual commits and you squash them to one, it's still the same files touched. One single commit, one new message. The end result is basically the same. How you get there is just a different route, really. Once you're cool, once you decide you're going to rewrite the history to make it a

clean history, then it's like, well, how do I achieve that? Yeah. And there's no one way to do it. There's like so many different ways. And there's at least three that we've discussed. There's probably more. I like the way you've described it, though, because for you in particular, like if, if, you know, if your executive function is challenged, whenever you have to divert away from

your creative brain and your pause or whatever, they call that the state of flow. And you mentioned dopamine and neuro, neuroepinephrine, those are two neurochemicals that keep your brain in that, that world. Dopamine is primarily a reward kind of chemical, whereas norepinephrine is really kind of keeping you back in adaptability, you know, keeping like your awareness of time and self-control. Those are things that happen. So like if that's a challenge for you, then this is one of the perfect flows for you because it just helps you to stay in flow. Right, exactly. It's people with ADHD tend to, it's not that we have a deficiency in attention.

It's that we have a hard time regulating our attention. And this is exactly a situation where I personally find that it's not impossible by any stretch. And if I, I'm sure if I just practice a little bit more, it might be easier for me to keep my commits as I'm building them in a little more tidy of a manner. But at the end of the day, if I do the reset method, my commits are going to be as clean as possible. Like the end result is just fantastic. And so why spend the energy up front to do that when I can just like clean it up and do it perfectly in the very end?

Yeah, that's my take. And you get one more dopamine hit. I mean, it feels great when you when you do that. It's like check that off. Bonus dopamine. Thank you. End my day. Absolutely. See ya. Yeah. I mean, that's that's I say to each to each their own. Right. I mean, that's exactly like whatever works for you. I think that's. But I think one point of this conversation is one, Jared learned about Reset and he taught me about Reset as a result of your article, but then two, deeply examining what workflow works for you and why. And then someone's going to hear this show and think, you know what, Annie, that's a great workflow for you. I like that for the reasons you stated.

Mostly I'm a Reset kind of person. I I love interactive reset. I know Mark Erickson, one of the core contributors to Redux, commented on your tweet for your article and just shared essentially the exact opposite. Not that your way was bad, but they prefer reset based upon their tweet. Rebase? Rebase. Sorry, yeah, rebase. My bad. I should reset what I said and say rebase. That's a whip. That's the thing, though. It's examining, deep examining, I think, the way we leverage common tools. Right.

Right. And what works for you may not work for me. But now I know. And one, I guess several points, but like a main point is now I have a very deep point of empathy with you. If I was your coworker and you did this and I didn't understand your backstory, it may drive me crazy if I was like, why in the world is she resetting? That doesn't make any sense. But now I know, right? Like now I have. Her PRs are so clean and instructive. I hate it. I hate how logical her commits are. Right. It's such amazing commits, you know,

but for whatever reason I can, you know, I can like not so much down talk your methodology, but like not understand it. Yeah. If I didn't understand your backstory, like there's something that changes in humanity when I or someone knows somebody else's backstory. Think of a villain in a story. Like whenever they're sharing that story for a little while, they're a villain until they share their backstory and they describe why they're the villain. Like even the most recent version of Joker, for example, I'm not sure if you're a fan of this, but like Joaquin Phoenix played that role amazingly.

And traditionally Joker is a villain, right? He is a villain. But now you have this significant point of empathy with that character because, wow, that's what they went through in life and why they ended up that way. It doesn't make it okay, but at least now you can understand them better.

I think that's what we're trying to do here is like, you're the villain. I'm kidding. You're not the villain i'm sitting i'm kidding you're not the villain i know i'm drawing some lines here i'm wondering where you're trying to go with this i am the joker i am the joker i'm trying to massage my analogy this whole show is one big reveal surprise it's a point of empathy it really is because you know because there's no one way to roam and obviously Git can be a divisive kind of conversation because people have feelings and emotions around their ways and their things. Like, I think it just provides that point of attention because especially with the things that i've outlined if you have your own feature branch and it's just you and it's how you manage your local commits it ain't nobody's business how you do that how you deal with it right it really isn't and it's whatever

works for you and i see a lot of value in how other people have described how they manage it through squash through rebasing and i think that's fantastic and I don't think it needs to me there's no there doesn't need to be a fight about it or you know it's at the end of the day it's just whatever works for you and I think it's

awesome that Git can accommodate so many different ways of approaching this let me ask you this do you think render has less customers because of the way you commit your code or more customers? They don't even know is the answer, right? They don't even know. They still love the platform.

It's none of their business. It's none of their business. If the end result is still a working product that customers love, that's the point, right? Right. Well, Annie, we appreciate you coming on the show today. This has been a fun conversation. We appreciate you writing this blog post.

Hopefully you have future posts in mind and we encourage you to keep writing because as you share this way, I learned something. Adam got some more empathy. We revealed that you're the Joker. See, good things happen when you publish on the internet. So we really appreciate it. And hey, just broadening the conversation around a tool that we all know and most of us love

is just helping everybody involved. So appreciate that and just encourage you to keep writing. Thank you so much. Any advice for those out there following along? Any final words of wisdom? I would say don't let the imposter syndrome get to you too much.

I think that that's really what drives a lot of people's strong opinions is if you were maybe taught a certain way and when you were learning early on that you're supposed to do it this way and that was something that you struggled with, then that history may have contributed to some amount of imposter syndrome. But the reality is there's a lot of different ways of accomplishing the same thing. This goes for beyond Git, just development in general. And the more

we are curious about how other people approach the same problems, the more we can learn. And I think it's a lot better for the community if we approach these conversations through a lens of curiosity rather than trying to find the right answer.

I agree. Further curious. Thank you, Annie. find the right answer. I agree. For the curious. Thank you, Annie. It's been awesome. Thank you. All right. That's it for this episode of The Change Law. Thank you for tuning in. Big thanks to Annie Sexton for sharing her knowledge and her wisdom on this show and also in a blog post form.

We encourage more of that. If you post an awesome blog post, we might want to get you on this show. And the best way to share your post with us is go to changelog.com slash submit. That is an open submission process to everyone. And on that note, big thanks to you for listening to the show. We appreciate your attention. Do us one big favor. If you enjoy the show, share the show with a friend. That is honestly the best way for you to help us to grow our shows. We mentioned Change All Plus Plus, but really what we want you to do is just share our shows with your friends. That's the best thing you can do to help us. And big thanks to our friends at Fastly for having our CDN back.

Check them out at Fastly.com. And of course, Breakmaster Cylinder. Those beats are awesome. They're banging, as they say. Slam course, Breakmaster Cylinder. Those beats are awesome. They're banging as they say, slamming as they might also say. Thank you, Breakmaster Cylinder. That is it for this week. We will see you next week. Thank you. Game on.