Hasty Treat - Git Rebase Explained

Monday. Monday. Monday.

Open wide dev fans. Get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest TS, web development treats coming in hot. Here is Wes, Barracuda, Boss, and Scott, El Toro Loco, Tolinski.

Welcome to syntax in this Monday hasty treat. We're gonna be talking about git rebase.

We're gonna be explaining Git rebase, talk about when, what, where, why, how you might use it, and, overall, what the heck you know, what are the reasons for using Gitbase rebase and Why? So my name is Scott Tolinski. I'm a full stack developer from Denver, Colorado, and with me as always is Wes Bos. Hey.

Coming in hot is Wes Bos.

This episode today is sponsored by 2 amazing companies, one of which is Sanity atcenteridot I o, and the other is [email protected].

Now Century is the perfect place to handle all of your errors and exceptions. Let me tell you. I've been using this software for a very long time. And what it does is you just connect it to your application, and then it logs anytime there's, errors or exceptions, or even better, you can actually manually log any sort of errors you want as well. It's Very, very good. It keeps them all inside of a dashboard where you can relate them to specific version releases even as far as, connecting it To the source code, getting source maps in there, attaching user information, viewing performance metrics, it is So so good. Basically, you can get alerts if there's regressions.

I can't even tell you, Wes. Let let me tell you here. Every single week, we try out new features of sent Sentry and are just blown away at how much better all of the features are. So you can really take some time. You can get the basics going in just about a couple seconds, or you can, you know, level up and get that advanced version of century going and really get some amazing error and exception handling. So head on over to century dot I o. Use the coupon code to tasty treat, all lowercase, all one word when you sign up. So We're also sponsored by Sanity, which I almost said Sanity, like, 8 times in that ad read because Sanity and Sentry are very, very similar words. Wes, do you wanna talk about Sanity?

Yes. Sanity is the structured content CMS.

They are awesome. They've got Sanity Studio, which is a really sick CMS.

They are they have this new thing called Content Lake, which is their reimplementation of their database, which is real time, super fast.

They got a whole bunch of new functions on that for search and for filtering. They have this new API that is versioned, which is really cool because Then you can be sure that the data is always going to be returned properly until you decide to update it. They got plug ins for everything. So Cloudinary, Algolia, Slugs, anything that you want. We, personally, we use the slug, on my own course on sanity, which is really cool. So if you are working on a project and you need A back end for it. You need to put your content somewhere. Sanity is the place for it. Check it out. Sanity.i0forward/ syntax. It's gonna get you double The free usage tier. Thanks so much to Sanity for sponsoring.

Alright. Let's talk about Git rebase. This is one of those things that is A very, very handy Git skill to have, and it's it's one of those things that's maybe a little bit hard To understand as to why you might need it and and what it does, but I would say it's in my, I don't know, top seven Pieces of Git that I use, especially I don't I don't use this as much when I'm just working on my by myself, but especially when you're working on a project that's moving fast or has multiple lots of people working on the codebase at once, rebase is gonna come and save your bacon. I'm interested in saving bacon, and

I'm very interested in hearing a little bit more about rebase because if this might be help as a a nice little preface to some of our our listeners.

I, myself, I use Git every day several times a day, many, many, many times a day. And my experience with Git rebase was I tried it once, it failed spectacularly, and I have Never tried it again. I personally have not had the use case where I've been like, oh, man. I got a rebase right now. Like, for me, for the most part, what we do is pull requests.

We, you know, code reviews on this pull request, click go, merge that pull request, or or Continuous integration, all that stuff runs, all our tests pass, and then the code gets merged. And to be honest, that has worked Fine for us. So I'm very interested in in hearing a little bit more about why Git rebase could save some bacon on my end and, you know, And what what the hype's about? Because a lot of people talk about it like it's it's their child or something. Yeah. Let me let me just say, if you are a dev who uses rebase quite a bit, Tweet us at syntax. F m as to, like, what does your workflow look like,

when working on features in your app? And I'm wondering if that involves using rebase. So Let's think about an application. You've got an app. You've got it in a Git repo, and you have it on your main or your master branch.

Then you wanna implement a feature. Like, maybe, Scott wants to add a feature to the syntax website where He adds a picture of himself anytime the word Scott appears. So what Scott will do is he will branch off of our master branch Into his own branch called Feature Dash Scott's Face.

And Scott is working on he he does a bunch of work, And then he's like, alright. I'm about to about to go home for the day. So he I don't know. Actually, this is a good question. Is if you are working on a feature And you're done for the day and you're not done the feature, do you commit everything that you've worked on so far, or do you just kinda leave it? Hell, yes.

I commit very frequently. I push very frequently, and I have, our poll requests open from the moment I create a branch, and then I So, like, what I'll do, if I'm starting a new branch, I'll start the branch, I'll open the poll request, I'll set it into draft mode, And then I will just leave it in draft mode while I'm cranking away on it, and I I basically use draft mode pull requests As just like the place, I just toss everything while I'm working on it. And the moment that I'm ready to have emerged, I'll take it out of draft mode. And we even have our continuous integration stuff to only run when it's not in draft mode. So using GitHub actions, you can tell, GitHub to only run, you know, TSC or only run your unit tests or whatever if the poll request is not in draft mode, which is what we do. It's been very nice. I like it. So

Scott's working on it, and he's got a commit, work in progress, added styling, another commit, A fixed accessibility issue, another commit, and, enabled SSR, another commit. So he's got 5 commits Now this pull request where Scott's adding pictures of his face, it takes him a week,

to implement this feature. It's gotta be just right.

Oh, well, I'm working on another feature kinda doing the same thing, adding my own face to this type of thing. And somebody else's is, Adam. The guy who edits a podcast is Submitting pull requests for new shows, and all of those things are being merged into master with the exception of of Scott's.

And what happens is that our master branch and what Scott has worked on are now sort of out of sync.

So what you can do here is do what's called a rebase.

So what you can do is like, You might think, okay, Wes, just take whatever's in master and merge it in. But that can be a bit of an issue because some of the code that Scott was working on May have been some code that I have already worked on. So what a rebase will allow you to do is you take Scott's Five commits, and you rewind to a point where he didn't write any of that code. It's kinda like a Git stash, but you just kinda rewind the whole thing, And then you say rebase it on master. And what it will do is it will say, okay. These 5 commits that Scott has done, those are not part of our master Branch, so let me just have sort of put those aside for a second. All the work Scott did in those 5 commits, let me put them aside and rewind it to a point, And then we'll we'll tack on everything that has happened since he created this branch on the master branch. So we'll rewind, put all the commits that happened in master, and now you're at a point where, okay, I have a, Sort of like a fresh copy of whatever's in master, and then the rebase will now try to play back and put these things on top of The latest update. And that's different from a merge because a merge will just try to put sort of it will take Scott's 5 commits and then tack on what is in master On the end of it, whereas this will sort of rewind it, put everything back to the latest version of master, and then play back All of those values that Scott has after it. So why why is that useful? Well, we just said, Scott is Sometimes when you're working on an application, the developers will say every feature that you work on needs 1 commit.

Or, maybe Scott's like, alright. Work in progress. Work in progress or oops or he screwed up a bunch of things. And sometimes you can have 10, 15 different commits for 1 single feature. So what you can do with rebase is, specifically, this is called the interactive rebase, is that you can go through Each of these, and 1 by 1, you can pick which commits you want to apply.

You can reword different commits. So if you've accidentally Spelled something wrong, you reword it. Squash is one that I use quite a bit, where if you wanna squash 10 commits into 1, You basically it'll just it'll open up in your editor, and you can type s in front of the commits you wanna squash and p in front of the commits you wanna Keep, and then you can also reorder them if if that's something you wanted to do, and then that will just squash them into all of the commits that you've picked and the the ones below it. There's a whole bunch of other commands in there. I've not used any of the other ones. For me, it's just pick, reword, edit, squash.

There's a whole bunch of other ones that come along with it as well. Man, it's

well, 1, we you know, you were talking the whole time, so I didn't get to connect you on your awesome rewind sound.

Like, you know, you could do something like that. So I that's fascinating to me. You know, I have had these issues that you're describing, and what ultimately I end up doing is basically the thing you You said that you could do, but it can get a little bit messy where you're just in the merging, you know, main into whatever.

So it's still fascinating to me. My issue is that When I tried to get rebase, it, like, had a I wish this was fresh in my mind because it had basically an issue at, like, step 1 of the the interactive process. And I was just like, well, I guess I'm screwed here. I guess I I don't know what I'm doing. I would be interested to try a rebase now with maybe After hearing you talk about it a little bit more so that I know what I'm getting into. Because for me, I was just thinking, alright. It just changes the head. It just changes where the the head of the Did the repo, and that's all I was thinking was doing. And so, like, I came into it thinking, alright. Just change the head. Alright. Let's just change the head to whatever I'm working on, and then it starts Give me some guff, and I'm just like, oh, I don't know about this. Yeah. So it's really interesting to hear you talk about it in a way that's not as, Like, a little bit more real world as to, like, what it's actually doing. Yeah. It it really helps you when you what your your branch that you're working on has Deviated so far from what is in the master branch because there's continuing work on your master branch. I'm I'm using master here as an example, but literally could be any branch. But In most case, you have, like, a development or master branch, and then you have feature branches

that you're you're working off of there. Mhmm. The other thing I I forgot to say is that, like, rebase can go step by step. So, basically, after you rewind it, then you can start to, 1 by 1, apply these commits on top of each other, and that's really helpful for resolving merge conflicts.

Because you could say, okay. The first thing I did was I removed this template and added in my new template. And then you're 10 commits in, and it might look the File might look totally different, and it's very hard to resolve a merge conflict from something that is totally different. So what what's helpful is you can say, okay. Let me resolve this merge conflict as if I was merging this one day after and not A week after, you can just solve the merge conflict. Say, okay. In in this commit, I modified this little bit and this little bit. And in this commit, I Move this from this file to this file, and the merge conflicts are sometimes a little bit easier to deal with when Things look very similar, especially if you're doing nice, small, little commits and not having to to squash it into 1 and just like, oh my gosh. This. I will never merge this thing because it looks totally different.

So dealing with it, 1 commit by 1 commit and then the ability to squash, reword. And then finally, when you do a pull request, everything is based off of the freshest master that you can have. Everything is nicely committed Into its own commits. Like, again, the maybe, the the value of of, squashing and reordering them as you could Put all your CSS changes in 1 commit and all of your JavaScript ones in another commit, all your server side stuff in another commit, and and then everything just nice and tidy by the time you submit a pull request, and then Everybody's happy. I can see the value in that, but it just sounds like so much work to me.

It sounds like so much work to me. Yeah. Yeah. I don't, I honestly don't use it all that much in in my own stuff. Where I did use it, it was when I was working on with client work on large projects where We just had I don't know. There's maybe sometimes 15 different devs touching the same code base as once. And when that starts to happen, you gotta get some really You gotta get a lot of rules in place before things get out of control.

Yeah. I'm interested. I'm interested in giving it a fair shake and and trying it in a Real capacity. So, yeah, I I think what you mentioned where you're working on a team like, we we have a team of, like, 3 or 4 developers. Right? Yeah. I I'm not seeing the benefit there for us, but I I would imagine that once you get into more people touching it, more more hands on the code, Tidier commits and all that stuff is much more important.

Awesome. One more thing I should say is sometimes you submit a pull request, And the pull request diff is showing, like, a 1000 files changed, and you will usually get From the author, hey. Can you rebase this? And that's the case where you don't have to do any of the squashing or anything like this, but it's just literally

Rewind it to what's on master right now, and then put your stuff on top. Interesting. Alright. That's it. Any, anything else to add, or should we wrap it up? I think we should wrap it up. I'm my the wheels are turning less. You got my wheels turning, which, you know, it's what a sign of a good episode. I I'm interested in hearing more about If you are out there and you use rebase all the time and we miss some sort of use case that you're talking of you know, you're thinking, oh, this is, You know, this is the reason why I use rebase.

Please let us know on Twitter. We will hit you up with that retweet. For those of you who are not on Twitter, we are frequently on Twitter retweeting, things like that that people send us, so it might be a nice value add to follow us on Twitter at Syntax FM. But yeah. So we just have if you're using any of that sort of stuff, because I'm interested in hearing more and more use cases for why rebase is the bee's knees. That's all I have for today, Wes. You got anything else? That's it. Peace. Peace.

Head on over to syntax.fm for a full archive of all of our shows, and don't forget