Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Branches are like alternate timelines for your code, timelines you can switch between at will.
Prerequisite Knowledge
Please be sure you've taken our Introduction to Git course before attempting this course.
On many systems, Git is configured to use the vi text editor by default. You may want to familiarize yourself with basic vi commands.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
[MUSIC]
0:00
I'm working on a simple program,
in the Ruby programming language,
0:09
that takes a series of numbers and
decodes it into text.
0:13
Don't worry if you don't know Ruby.
0:16
Anyone familiar with Git will understand
the problem I'm about to show you.
0:18
I'm keeping all my code in Git of course,
and my decode method has
0:22
already been committed to the repository
and shared with my users.
0:25
I've started work on an encode
method that will take a string and
0:29
convert it to an array of numbers.
0:33
But now I get a report that there's
a bug in the decode method.
0:35
It's suppose to decode each
number in the array and
0:39
add it onto the end of the string, but
instead, it's replacing the entire string.
0:41
So I stop my work on the encode method and
go to fix the decode method.
0:45
I go up and I find the problem,
this text = letter line.
0:50
The equals operator causes it
to replace the decoded string,
0:54
we need the plus equals operator so
that it appends to the string instead.
0:58
Let me save this and
suppose I test the change,
1:02
it looks like it's working correctly,
and so I decide to commit it.
1:05
I go to my terminal, and I stage the file
for committing, git add decode.rb.
1:08
Then I complete the commit with git
commit -m Fix bug with appending string.
1:17
Our bug fix is ready to share with users,
crisis averted, but
1:24
wait let's look at the code
that got committed.
1:28
I'll run git log with the -p flag
which will show our changes, uh-oh,
1:31
there in our commit is our
incomplete encode method.
1:36
Git has a branches feature to help
deal with situations like this.
1:40
You've probably seen fictional books or
movies that depict alternate realities
1:45
which are mostly like our own, but
a key element of history has been changed.
1:49
Branches are like those alternate
histories, you can switch to a branch
1:53
work on code for a new feature, and
commit all your changes to that branch.
1:58
If you switch back to
your original branch,
2:02
you'll get the original versions
of all your files back.
2:04
Switch back to the new branch and
you'll get the updated versions back.
2:07
You can create as many
branches as you want, and
2:12
switch between them anytime you want.
2:14
Cloned repositories can pull
copies of those branches too, and
2:16
switch between them at will.
2:20
This allow collaborators to review changes
that are on a branch without affecting
2:21
their own work.
2:25
All Git repositories start
with a Master branch,
2:27
your commits go on this branch by default.
2:30
Before beginning work on the encode
method, we could have created a branch
2:32
named Encode specifically for
work on that feature.
2:36
Commits related to the encode method
would go on this Encode branch,
2:39
not the Master branch.
2:43
When we discovered the issue
with decode method
2:45
we could have switched
back to the Master branch.
2:47
That would reset our source
code files back to a version
2:50
that didn't include the Encode method.
2:53
We could then fix the issue, commit
our changes to the Master branch, and
2:55
distribute our bug fix to our users,
2:59
without including
the incomplete encode method.
3:01
With that done, we can switch back to
our Encode branch, which would restore
3:04
the version of our source code that
includes the incomplete encode method.
3:07
That source code would also include the
bug in the decode method, but our commit
3:11
to fix that bug would be reincorporated
once we merge the two branches together.
3:15
We could resume making
commits on the Encode branch,
3:21
still without affecting the Master branch.
3:23
When the encoding feature is complete and
3:26
tested, we can use Git to merge
the Encode branch into the Master branch.
3:28
That will cause all the commits
from the new branch to be
3:33
added to the history of the master branch.
3:35
In our source code, the new method from
the Encode branch will be combined with
3:38
the bug fix from the Master branch.
3:42
In the real world,
software development can be messy.
3:44
You can find your attention divided
between urgent requests for
3:47
new features and fixing bugs.
3:50
Git branches can help you manage this
chaos by helping you keep all these
3:52
aspects of your work
separate from each other.
3:56
And when you're done, you can easily
bring all your work back together
3:59
by merging branches,
this course will teach you how.
4:02
We won't be using Treehouse workspaces for
this course at all.
4:06
I'll just be working on my
local computer in the terminal,
4:09
although it's possible to
follow along in workspaces.
4:12
I encourage you to install
Git on your computer and
4:15
follow along there instead,
see the teacher's notes for more info.
4:17
You shouldn't take this course
if you haven't used Git before.
4:22
You need to already know how to stage and
commit files, and for
4:25
later videos you'll need to know how to
use code hosting services like GitHub.
4:28
If you aren't already
familiar with these topics,
4:32
see the teacher's notes on this video's
page for links where you can learn more.
4:35
So now you have some
idea what branches are.
4:39
In the next video we'll show
you how to create a new branch.
4:41
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up