Let's talk about branching.

A branch is an independent line of development.

So far, we've spent a lot of time working on the master branch.... I suppose that's been fine for what we've been doing, but really, that's a bad development practice.

Plus, this prevents unstable and half baked code from being live on the site.

Once a feature has been finished and approved it can be merged back into the master branch.

Meaning, your master branch should only contain finished, production-ready code.

Let's dive a little deeper into what this looks like within an actual project.

git is a big part of development because it's one way that developers work together. If you're not sure what git is, why you would use it, how to get it installed, check out some of the other videos in this series.

Let's jump into some actual code. Let's keep working on our jokes repo that we've been working on in some of the previous videos. If you want to follow along, all my code is on GitHub, feel free to download, use it, modify it, whatever.

Right now, we have a single jokes.txt file that has a bunch of different jokes in it. Let's break the file up into multiple files based on joke categories.

Right now we're in the master branch.

In the terminal, you can see we're on the master branch. You can also look in the bottom left corner of VS Code and see we're on the master branch.

Remember, master should be the production-ready version of our code. You can think of it as your official project directory. In fact, when you visit GitHub, it displays the master branch by default.

A best practice is not to mess with master. It's supposed to be a stable version of your code, used in production.

Let's create a new branch to work from, in the Terminal, type:

That -b is a flag that creates a new branch.

The branch name can't have any spaces.

You'll notice, I named my branch feature/THE-NAME-OF-THE-FEATURE . The feature/ is just part of a naming convention.

Naming conventions make it easy to find what you're looking for. Different teams will use different conventions.

Some people may choose to name their branches based on the author

Others, will label them by bugfix, features, or a hotfix

You could also add an additional level of hierarchy, by including a feature-area

But, the important thing to remember here is: one feature per branch, or one bug per branch.

For projects I've worked on, I'm usually working from some kind of ticket or issue system. I've found it helpful to include the ID number from that ticket within the branch name. This helps, me at least, find the branch that I'm looking for.

Regardless of what convention you decide to use, the important thing is to be consistent.

OK, so now we have our new branch and we're on the new branch instead of master. You can see, with the tools I'm using in the Terminal, it actually tells me what branch I'm on.

Now we can make the changes we want for our project.

Within the jokes.txt file, you'll see we have several jokes:

Let's break this file apart so that we have a different file for every type of joke.

I'm going to create a new file, called programming-jokes.txt and add the first 3 jokes to that file. Just a quick copy and paste.

Now, let's create a file called riddles.txt and copy and paste the next joke there.

Last file: knock-knock-jokes.txt and copy and paste the last joke there.

Since our original jokes.txt file doesn't contain anything, we can get rid of that file.

OK, let's commit our work, just like we've done in the past:

That . means to stage all the changes we made. There's no need to add each file individually.

Awesome! Now that our feature is complete, we can merge this back into master.

So, let's move back over to the master branch:

The --no-ff flag means that its going to create a new commit when it merges. So, when you hit enter, you should see the vim text editor open up within your Terminal. Here it wants you to add a commit message for your merge.

I'm just going to use the default message it created for me: Merge branch 'feature/joke-in-categories'

I can hit :wq to save and quit.

Now, I'm going to type

so we can see our history of commits:

The most recent commit is at the top. If we start at the bottom, you can see that was our initial commit. Then, we made another commit that broke the jokes out into separate files on the feature/joke-in-categories branch. Then, we merged that code into master.

I've told you before, I like to use a program, called Tower. I like the visual representation it shows you:

It makes the history a little easier to understand.

Let's go through the process one more time, there's one more thing I'd like to point out:

I want to add some more Knock Knock Jokes, let's create a new branch:

Oh no! I forgot to use the feature/ as part of my branch name. No worries. Within the Terminal, type:

Since we're on the branch that we're trying to rename, this is all we need to do.

But, I'm not going to run this command just yet. I want to show you how this would work if you're trying to rename a branch you're not on. Let's move over to master:

Now, to rename our knock-knock joke branch we can run:

Perfect. Now, we just need to check out the knock-knock joke branch in order to make our change:

Within knock-knock-jokes.txt I'm going to add:

Let's commit this joke:

Let's pretend that this joke needs to be approved before we can add it to master. In the meantime, we need to add a new riddle.

What do we do?

We need to create another branch, but we need to "fork" off master. This keeps everything clean and separate. Plus, this way it doesn't matter which joke gets approved first. We can merge these branches in any order.

Within the Terminal:

Now, if we open our knock-knock-jokes.txt file you'll see that the ice cream joke isn't there. — Good, that's what we want!

Let's open riddles.txt and add this:

Now, we can commit this:

Let's merge both of these branches into master.

Perfect!

Now, let's double-check our knock-knock-jokes.txt file. Perfect, our ice cream joke is there. And if we got to the riddles.txt file, we can see the roof joke, too.

For the record, sometimes you'll work with code that builds off itself. In that case, you don't necessarily want to wait until your code gets merged into master to start on the new feature and you don't want to rebuild the feature on your new branch.

What should you do?

Glad you asked! You can fork off your new branch, you just need to make a note so that the branches get merged to master in the correct order.

Before we call it quits, let's do a little housekeeping.

To list all the branches in our repository, in the Terminal type:

You can also type

both commands do the exact same thing.

I think you can already see that this list might get long.

The * indicates what branch you currently have checked out.

git has your back. If you try to delete a branch that hasn't been merged into master, git will tell you!

If you want to delete a branch that has not been merged, losing that work forever, you can force it:

If you want to see a list of branches that have not been merged into master, you can use the following command:

Similarly, you might have guessed, this command:

will show a list of all the branches that have been merged.

Let's remove all the branches that we've merged in:

Done.

All the code is posted on GitHub. Feel free to download it, play with it, modify it, share it, use it, whatever. Have at it!