you do it no matter what, you always create a new branch for any amount of code you create. It just sort of depends upon the team. In this case, because it took about a week, I don't want to end up in the situation where I have code on master, but I need to merge in a PR, an important PR, but that conflicts with the new code I'm writing, and it gets all very tricky. In this case, we store it all on a branch that I called design. So now, let's install any updated dependencies, and then compile everything down. And that way, when we refresh the browser, it will, of course, reflect the new CSS and JavaScript. So here, of course, is what we had initially, and here is the new design.

So instead, I will generally create these Work In Progress commits. And then when I'm ready to submit the PR or merge it in, I will squash all of that down to a single readable commit that illustrates what I've done. Now we can do this in two ways. Of course, as the maintainer, I have full rights to merge in my own code. So what I could do if I want is just squash everything down now, or you can do that on the GitHub level. Now what about when you are working on a branch? So let's cover this real quick, some basic Git workflow. Oh, and whoops, we have a package-lock.json file I probably need to commit.

So let's cover this real quick, some basic Git workflow. Oh, and whoops, we have a package-lock.json file I probably need to commit. But anyways, if we check out our master branch, when you decide to work on a new feature, you will check out a new branch with a proper name. If it's a feature, you might say feature/whatever you're working on. You might say bug/whatever or bug-whatever, whatever convention your team relies upon. Then when you want to push your changes up to GitHub, well, you want to push up not the master branch, but maybe in our case, the design branch. So I would say git push origin design. Now in this case, everything's up to date, but that would be the command I'd use.

So you'll see a lot of this stuff like behind the scenes, a lot of SVG files. We're using Tailwind CSS behind the scenes, so a lot of the partials have been updated to reflect that. You know, everything that goes with a significant UI refactor. But now, as the maintainer, I don't want to commit all of these work-in-progress things. I'd rather squash all of that down to a readable commit. So let's not create a merge commit, but instead I want to squash all of those 24 commits down to a single commit. Now if I click on it, you'll see it will take the subject of the PR and make that the new commit.

Now if I click on it, you'll see it will take the subject of the PR and make that the new commit. And then in the description, you'll see all of the previous commits, which I certainly don't need. So let's confirm the squash and merge it in. OK, so now take a look. If we come back to my commits, you're not going to see a bunch of work-in-progress commits. You're just going to see a single commit that represents all of the changes that I made here. So now, we will pull in the changes. So now if I do git log, you'll see our new big commit.