we create a branch, and on that alternate timeline is where we start working on the feature. Now, we get halfway through and we find out we have that error, right? We have to go back to our main timeline or our master branch, fix the error, and push it up. Well, because these are two exclusive timelines or branches, there's no problem there. The work you do here has no effect on the master branch. So all you have to do is go back to the master branch, make your fix, and push it up, and none of that branch currently reflects the changes and modifications that you've made to your feature branch. That's the basic concept. Let me show you an action. If I switch to the terminal and list the files, I have a fresh install of Laravel.

Let me show you an action. If I switch to the terminal and list the files, I have a fresh install of Laravel. I will initialize git, add everything to the staging area, and then git commit with a message of install Laravel. Now, if I open this up in Sublime, let's just say within routes.php, and let's just add an about page like this. We're just simulating some kind of real work. But you know what? Why don't we make some kind of mistake? We'll get that wrong, right? But we think we had it right.

We'll get that wrong, right? But we think we had it right. Okay, so we do a git status. We add everything to the staging area and commit with git commit -m "add about page". Okay, everything's looking great. So now we can start working on our feature. So let's say once again back in routes, we're adding tons of stuff here. git reports or something like that. You know, lots of work involved in adding some kind of feature. But now as we're working on it, somebody notifies us that,

You know, lots of work involved in adding some kind of feature. But now as we're working on it, somebody notifies us that, hey, that about page doesn't work. With the recent commit, you got the URI wrong, and now every click to the about page doesn't work, and you need to fix that right away. Well, the problem is if I do a git status, we're working on this feature, and that probably has tons of files that we've modified. So what do we really do in these situations? Now, there are some little tricks we might make where you can do partial commits,

So what do we really do in these situations? Now, there are some little tricks we might make where you can do partial commits, where you can be pretty fine-grained about which lines from a change file you wish to add to a commit. But in general, it can just sort of be a nightmare. So instead, we'll take advantage of git branching. Why don't we go ahead and undo this change? We can do this by saying git status, and you'll have a little note here, git checkout -- the file to discard changes. app/Http/routes.php.

git checkout bash dash the file to discard changes. App/Http/routes.php. Okay, now that resets it to how it was before. This time, I will create a branch. Now, I could do git branch and then another command, git checkout, but more traditionally, you'll see people do this, git checkout -b a new branch, and then we give it any kind of identifier. If we're working on this concept of reporting, maybe you could follow a convention of feature- the name of the feature. Or maybe you're fixing an issue.

We've now created an alternate timeline, so to speak. Let's make a change here to demonstrate this. I'll say routes, and I'm going to add that reporting feature. I'll say return reporting feature to simulate it. Okay, so I will git add everything, commit with add reporting feature. But we still have work to do here. Now, let's imagine we still have that crisis where the about page is no longer loading. Not a problem in this case. If we git log, notice that we have these three commits.

Not a problem in this case. If we git log, notice that we have these three commits. But if I now check out my master branch again, the main timeline, and I do a git log, notice that it does not reflect the commit. So now, for example, if I were to cat app/Http/routes, it will not reflect the reporting feature that we've been working on. So now here is where we can make our fix. Or a quick note on that, if it's just a very easy fix, you could do it on master. If it's something that might require a little work, once again you could create a different branch for that.

If it's something that might require a little work, once again you could create a different branch for that. Like git checkout branch fix, and then once again an issue number or some kind of description. You fix the bug on that third alternate timeline, and then when that's ready, you can merge it back into master. Or, like I said, if it's an easy one, you can do it on master if you want. Okay, so let's sublime routes.php, fix our bug in whatever form that takes. git status, git add everything or that file, and git commit with fix about page URI.

git status, git add everything or that file, and git commit with fix about page URI. Okay, so now think about it. We have these two separate timelines. The master branch, we have this new commit where we fixed a URI. But if you remember, if we go back to the other branch, git checkout feature, and you can use tab completion here. Now if we go back to that other branch and log, it has a very different timeline here. It doesn't contain the bug fix, and it also has this new reporting feature.

we'll say that was everything that needed to be done. So now we're ready to push this up to production. Okay, git checkout the master branch, and I'm going to merge in that alternate timeline. git merge feature, and I'll hit tab. We're going to merge that branch into the master. We run it, it'll create a merge commit, and I can save and close that out. Okay, so now if I git log, notice that our master branch successfully merged in the reporting layer, and it also, of course, reflects the about page. So now if we cat app/Http/routes, sure enough, we have the correct about page,

in the reporting layer, and it also, of course, reflects the about page. So now if we cat app/Http/routes, sure enough, we have the correct about page, but we also have the feature that we've been working on. So that's the basic concept. When you're working on a bug, or an issue, or a brand new feature, don't do it on your master branch. Instead, create either a develop branch, if it's something simple. This is really good for things like packages. You just have two branches, a master branch and a single develop branch. Or you can create one branch per feature, and

You just have two branches, a master branch and a single develop branch. Or you can create one branch per feature, and then once the feature has been implemented and you've merged it in, make sure you delete the branch. You do this by saying git branch -d for delete, and then you type in the branch name. And now we've deleted it. Okay, so in closing, the workflow is this. Check out a new branch, and you give it a name. Let's imagine we're fixing some kind of issue on GitHub.

Check out a new branch, and you give it a name. Let's imagine we're fixing some kind of issue on GitHub. issue dash and the GitHub issue number. Now on our alternate timeline, you fix the bug in whatever form. I'll just say somefix.txt, so that I have something to add and commit. Fix bug. Okay, now I can check out my master branch, return to the main timeline, and merge in the changes from our issue. Finally, we no longer need that separate branch, so we can delete it. All right, so play around with this workflow for a while, and

That's referred to as a merge conflict, and we'll figure out how to deal with it in the next video.