Check this out, this is pretty cool. We're on our master branch, but we've decided we want to start working on a new feature. So we've learned we can check out a new branch feature, and we'll stick with that same idea of a reporting layer. And then at this point we begin working on it. For example, we make a controller called ReportsController, and then maybe we open up our routes file, and we set up some kind of resource for the reports, like so. So just basic steps to get this working. But now, like we talked about a couple episodes ago, what about if you need to take a break from this, switch back to your master branch, and make some kind of hotfix, or something like that? What exactly can we do here? Because a few lessons ago, well, we just said commit your changes, and then switch back to your main branch, where these changes have not yet been applied, and make your fix, right? And it's true, that's very much an option. But what about

of people do these basic work in progress commits, where it's sort of like a temporary save. And then when you want to get back to work, you just git reset back to that current commit. And that works just fine when you're only working locally, you haven't pushed this up to production. So that's an option, and it would look something like this. Add the files, git commit with a message of work in progress, do a git status, that's clean. And if we check out our master branch and do a git status, that one is clean as well. So you make your fix, do whatever you need to do here, and then when you return to your feature branch, you can do a git log and simply reset to the previous commit. git reset, and we'll do a soft reset here to that commit. So now if I run a git status, you'll see that once again we have these files, but our commit history is as we would want. Now a quick note on that, be very careful with git reset. By itself, it's relatively safe. But if

status, you'll see that once again we have these files, but our commit history is as we would want. Now a quick note on that, be very careful with git reset. By itself, it's relatively safe. But if you've pushed your project up to something like GitHub, and your commit history has been shared with other people, and they've pulled that in, you want to be careful about doing things like git reset --hard. The difference between git reset --soft is that it will not touch your index or your working tree whatsoever. So that's useful if you want to reset to a current commit, but retain all of the changes that have been made since then. If I were to change that to --hard, that would mean reset to exactly how it looked at this specific commit. Any files that you've changed since then will be reverted back to the way they looked at that point. This is pretty dangerous. You can lose history by doing this. So make sure you only run this command if you have not pushed your changes up to, again,

reverted back to the way they looked at that point. This is pretty dangerous. You can lose history by doing this. So make sure you only run this command if you have not pushed your changes up to, again, a site like GitHub. But anyways, that's another video. The main point is, once again, we were able to stash our changes away, so to speak, switch over to our master branch, make our change, return, and then reset back to a previous commit and continue on. But notice how that was kind of tedious, right? We don't want to have to do that, and really, it's just kind of a tricky way to get around it. Wouldn't it be better if there was something more dedicated? And there is. So in this case, once again, we have two files staged. This time, if I want to stash my changes, why don't we just call git stash. Done. Saved our working directory. So now, take a look. If I run git status, our working directory is clean, at which point we could go back to our master branch. There, of course, the directory

git stash. Done. Saved our working directory. So now, take a look. If I run git status, our working directory is clean, at which point we could go back to our master branch. There, of course, the directory will be clean, and you can make your changes. Then, when you're done, go back to your feature branch and take a look at this. If I run git stash list, this will show me all save points, so to speak, and each of them have this unique ID. Now, what if I simply want to just apply this stash? We've stashed it away. Think of that sort of like putting your files to the side of your desk, just piling them up and putting them to the side for now. But, say, 30 minutes later, you're ready to work on them again. So you want to take those files and bring them back to your work area. Okay, we can say git stash pop, or you can do apply. They're just slightly different. For example, if I were to do git stash apply, that will return my files, as you can see right here. So if I run git status,

stash pop, or you can do apply. They're just slightly different. For example, if I were to do git stash apply, that will return my files, as you can see right here. So if I run git status, it's all back. But if I do git stash list, you'll see that still represented here. So if you ever want to apply the changes but also pop this off the list, sort of like deleting a branch, then in those cases, you could say git stash pop. Or, if I run git stash list again, and you want to apply a specific stash, remember, you could have multiple ones here. Well, in that case, you could copy this little identifier here. Well, I git stash apply, and then you paste in the identifier that you would want. And by the way, the same is going to be true for git stash drop. We won't apply it, we just want to delete it, essentially. So if you call it with no identifier, then it will default to the most recently stashed object. Okay, now if we run git stash list, it's no longer there.

we just want to delete it, essentially. So if you call it with no identifier, then it will default to the most recently stashed object. Okay, now if we run git stash list, it's no longer there. But if I run git status, we can see our changes. So once again, let's go through that workflow, because I know it can be a little confusing at first. We add our files. Okay, we've staged a few things, but now we want to work on something else. So we stash them away. Now that cleans out our current working directory, but it hasn't deleted everything, which is useful. You then switch to the necessary branch, and you make your changes. And when you're done, you can return and say git stash apply, or like I said, pop. That will apply it, but then pop it off that list. There we go. So now we have our files back, and we can continue on our way. But now here's another option. Once again, let's git stash these changes,

So now we have our files back, and we can continue on our way. But now here's another option. Once again, let's git stash these changes, check out our master branch, and let's just delete that branch entirely. Okay, so we still have that stash. If we list it, it's still there. And we could apply that to a different branch if we wanted to. So imagine that you were actually working on your master branch, not a separate branch. Let's do that. git stash pop. Okay, so these files are now on our master branch. And we're in that same situation where we just want to set these changes aside and work on some kind of important fix for production. So let's do this. Let's stash these changes away. Once again, git status. And by the way, don't forget, if you ever see me do gs, that's just our alias for git status. And we talked about that in the previous lesson.

Once again, git status. And by the way, don't forget, if you ever see me do GS, that's just our alias for git status. And we talked about that in the previous lesson. Okay, now we've stashed away those changes. And if we want to, we could apply those, but also apply them to a new branch in the process, maybe like we should have done in the first place. We do this. git stash branch. And this time, we'll call the branch feature, and once again, reporting. So take what was in that stash and apply it, but apply it to a new branch rather than our master branch. So if we run that, now you'll see that we've switched to this new branch. And if I do a git status, we can see those changes. So now we can continue on whenever we're ready to commit, add reporting feature. And it's all maintained in this single branch. And if we then return to our master branch and do a git log, of course, we won't see that.