[MUSIC]

I'm working on a simple program, in the Ruby programming language,

that takes a series of numbers and decodes it into text.

Don't worry if you don't know Ruby.

Anyone familiar with Git will understand the problem I'm about to show you.

I'm keeping all my code in Git of course, and my decode method has

already been committed to the repository and shared with my users.

I've started work on an encode method that will take a string and

convert it to an array of numbers.

But now I get a report that there's a bug in the decode method.

It's suppose to decode each number in the array and

add it onto the end of the string, but instead, it's replacing the entire string.

So I stop my work on the encode method and go to fix the decode method.

I go up and I find the problem, this text = letter line.

The equals operator causes it to replace the decoded string,

we need the plus equals operator so that it appends to the string instead.

Let me save this and suppose I test the change,

it looks like it's working correctly, and so I decide to commit it.

I go to my terminal, and I stage the file for committing, git add decode.rb.

Then I complete the commit with git commit -m Fix bug with appending string.

Our bug fix is ready to share with users, crisis averted, but

wait let's look at the code that got committed.

I'll run git log with the -p flag which will show our changes, uh-oh,

there in our commit is our incomplete encode method.

Git has a branches feature to help deal with situations like this.

You've probably seen fictional books or movies that depict alternate realities

which are mostly like our own, but a key element of history has been changed.

Branches are like those alternate histories, you can switch to a branch

work on code for a new feature, and commit all your changes to that branch.

If you switch back to your original branch,

you'll get the original versions of all your files back.

Switch back to the new branch and you'll get the updated versions back.

You can create as many branches as you want, and

switch between them anytime you want.

Cloned repositories can pull copies of those branches too, and

switch between them at will.

This allow collaborators to review changes that are on a branch without affecting

their own work.

All Git repositories start with a Master branch,

your commits go on this branch by default.

Before beginning work on the encode method, we could have created a branch

named Encode specifically for work on that feature.

Commits related to the encode method would go on this Encode branch,

not the Master branch.

When we discovered the issue with decode method

we could have switched back to the Master branch.

That would reset our source code files back to a version

that didn't include the Encode method.

We could then fix the issue, commit our changes to the Master branch, and

distribute our bug fix to our users,

without including the incomplete encode method.

With that done, we can switch back to our Encode branch, which would restore

the version of our source code that includes the incomplete encode method.

That source code would also include the bug in the decode method, but our commit

to fix that bug would be reincorporated once we merge the two branches together.

We could resume making commits on the Encode branch,

still without affecting the Master branch.

When the encoding feature is complete and

tested, we can use Git to merge the Encode branch into the Master branch.

That will cause all the commits from the new branch to be

added to the history of the master branch.

In our source code, the new method from the Encode branch will be combined with

the bug fix from the Master branch.

In the real world, software development can be messy.

You can find your attention divided between urgent requests for

new features and fixing bugs.

Git branches can help you manage this chaos by helping you keep all these

aspects of your work separate from each other.

And when you're done, you can easily bring all your work back together

by merging branches, this course will teach you how.

We won't be using Treehouse workspaces for this course at all.

I'll just be working on my local computer in the terminal,

although it's possible to follow along in workspaces.

I encourage you to install Git on your computer and

follow along there instead, see the teacher's notes for more info.

You shouldn't take this course if you haven't used Git before.

You need to already know how to stage and commit files, and for

later videos you'll need to know how to use code hosting services like GitHub.

If you aren't already familiar with these topics,

see the teacher's notes on this video's page for links where you can learn more.

So now you have some idea what branches are.

In the next video we'll show you how to create a new branch.