Now that you've learned the absolute basics, let's review some workflow. I'm going to create a new Laravel application, myapp, and give that a second. And then I will cd into that. And I will go ahead and initialize git. And let's review the git status. Sure enough, we see all of the files there from the Laravel framework. Okay. I'm in my project root, so I can add everything here. And I will commit with a message that describes what I've done. In this case, I installed Laravel. Now, on that note, if I scroll up, notice that for the message itself,

In this case, I installed Laravel. Now, on that note, if I scroll up, notice that for the message itself, I always use the present tense. So in this case, I didn't say installed Laravel, even though that would be fine, nothing's going to happen, it's just a message. But, that being said, you'll find it's a general, common practice to write your commit messages in the present tense. And that makes it actually a little bit more readable. When you are reviewing the log, especially when you have lots of commits, you can see right here, okay, this commit installs Laravel.

the basic idea is, if you can describe the change that you just made, then you probably should commit it. Now, here's the thing, this is a good recommendation, and then at the same time, it's incredibly vague. For example, if I go to routes.php, maybe we add a new route for an about page, and do something like this. What does that mean? Because I added a new route for the about page, that I should then go and commit it? No, in most situations, that's absolutely not the case. But that still begs the question, well, when do I create a new commit?

No, in most situations, that's absolutely not the case. But that still begs the question, well, when do I create a new commit? And maybe you can think of it like this, when you hit a milestone, it's time to commit. And this is especially useful if you build your application in terms of features. You do it in little steps, like I want an authentication layer for my application. So you code all of that, you make it work, once it's tested, everything works great, that's a good stopping point. Think of it like that, I hit this milestone, that feature is implemented, let's go ahead and commit it.

Think of it like that, I hit this milestone, that feature is implemented, let's go ahead and commit it. Let's imagine that we've done it. So we would add all the files to the staging area, we would commit it with add authentication layer, and we're done. Okay, next, maybe you decide, well, I need some kind of reporting layer for my application. So let's imagine you're building just a typical blog, and you want to report on that, you probably don't need to, but if you wanted that, maybe you could compile the total number of posts,

and you want to report on that, you probably don't need to, but if you wanted that, maybe you could compile the total number of Posts, you could check the frequency for how often you post, and then put that on a line graph or something, I don't know. But let's imagine that's the next step. Okay, well, that could represent a milestone or feature, and when it's implemented, you can commit it. So we can do whatever logic to add reporting to our app. And when that's done, add everything to the staging area, and remember, always, as a good practice, check your status first.

And when that's done, add everything to the staging area, and remember, always, as a good practice, check your status first. You want to make sure that everything relevant to adding a reporting layer is represented here, because sometimes, if you're not careful, and if you're just working all over the place, well, if you do git add ., that's going to add all of the files, every file, if you're in your project root. But, for example, if you just change some kind of config item that is completely unrelated, well, you want to make sure that's not included with the same commit.

or whatever the commit is just needs a little bit more information. Okay, in those cases, here's what you can do. I will git commit, and because I don't add -m, it'll open up an editor to write the message, and now here's what you can do. The first line will be the general description, like add reporting layer. Now, if you need more information, just separate it by a line, and you can add it here. In this case, I'll paste in some lorem text.

it doesn't matter that much. In fact, what a lot of people do is they don't even initialize git until they have sort of their first draft. I do this a lot for smaller things, like if I'm working on a composer package. I'll get it to work, and then I will git init, I will say git add everything, and then git commit with a message of "first draft." And then from then on, for any new feature I add, or any bug fix, or things like that,