Tip:
Highlight text to annotate it
X
In this section, we're going to talk about branching. Branching is the way that you can
create different tracks of code that all have a common source.
So for example, say you have multiple versions of your website, you have a release that you
make and then you add some new changes, you add some new features, and then you make a
new release, each of those releases may be their own branch. That way, as you're adding
new features to the second version of your site, you can be working on and release bug
fixes for the first version.
You're probably seen this kind of release system for other types of software where there
are minor releases, where there are bug fixes made, and then there are major releases where
new features are rolled out.
The dynamic around that is actually fairly complex because as you add the bug fixes to
that first version, you'll want to usually roll in those bug fixes with the second version,
but for the features that you're adding to the second version, you don't want to pull
those into the first version. But occasionally, you'll find a bug on the second version and
want to pull that into the first version without pulling in the features.
By having a common repository for both of them, that is instead of creating a repository
for your version 1 and a separate repository for your version 2, you then have the flexibility
of using branching and merging in order to manage some of these complex transactions.
Now, what I just described with the release cycle is one legitimate version of using branching
and merging, but there are many others as well.
The actual mechanism of branching and merging is fairly simple and what adds complexity
is simply the rules that you enforce for your particular project. For example, if you have
releases, then you need to enforce a certain interaction between the new release and the
old releases.
Throughout this series, we're going to explore a set of uses for branches that all come together
for a complete workflow and we're going to work up to that rather complicated workflow
by understanding what each type of branching is for and what sort of rules need to be enforced
around it in order to maintain a sane, predictable, and stable environment for your development.
Now, just to clear, while we're talking about different types of branches, they're all the
same thing to get. They're all a branch, and the difference is how we enforce rules around
that particular branch.
For those of you who come from a different version control system namely Subversion,
branching and merging in Git is far less complicated and expensive than it is in Subversion. In
Subversion, you need duplicate copies of your entire repository or your checkout in order
to do a branch and merge.
But in Git, things work differently. You can have all of your branches and all of your
merges in the same repository without having to take up more space. So only the differences
between branches are taking up space on your hard drive. This means that you don't really
need to worry about restricting your workflow to use a limited number of branches just because
of performance. The main problem that you run into is simply keeping track of all of
your branches and knowing what they're all for.
The first type of branch that we're going to cover is a feature branch or a topic branch,
and the purpose of a branch like this is to create a separate track of development while
you work on a particular feature before rolling it into the main line of development. In this
case, our main line of development is going to be our master branch which is the default
branch that gets created with our repository and then we're going to create a feature branch
where we're going to work on our new feature.
Now, the reason why we might not want to do this on the main development branches because
we could be working on several features at the same time and not all of them will be
one so we want to release at the same time. Also, some of the features might be experimental
and we're not quite sure if in the end we'll actually want to roll them back in. So keeping
development on a separate branch makes it clean and easy to pick and choose what you
pull into that main branch.