♪ (intro music) ♪ Managing change can be challenging,
especially for software development. It's an elaborate process, where lots of people
are using many complex tools, in parallel, to build <i>one thing</i>. Workflow is about controlling the sequence of events
that transform a piece of work to ensure every person*
can use the best tool at the right time. At its core,
workflow <i>is</i> change management. There is no universal solution
for every team's needs, but a good workflow positions all of the tools, processes, and people,
for optimum happiness and productivity. Rather than presenting
a prescriptive set of features or family of products
with a predetermined flow, Github gives you the flexibility
to define the best workflow for <i>you</i>. It puts <i>your</i> code at the <i>center</i>
of your development process and provides sensible tools for managing changes to your software
and getting it where it needs <i>to go</i>. Let's take a look at some of the ways
Github lets <i>you</i> define <i>your</i> workflow. Branching is a core part of managing
parallel software development. Git, the version control
system Github is built for-- lets you create, destroy,
and combine branches with minimal effort. So, branches can exist
for as long, or as short, as you need. One of the most straightforward
branching workflows is the Github Flow. In this workflow, your project
has a singular master branch, where <i>all</i> released work lives. <i>And</i> you can create
temporary feature branches where new development takes place. When changes are ready for review, you open a pull request
to review and discuss them. We'll talk more about pull requests
in just a second. When changes are approved,
you can deploy your code from your feature branch
to production, if you need to. Then, you just merge the feature branch
into the master branch, and delete it. Let's talk a bit more about pull requests. On Github,
pull requests let you show others the changes you've made on one branch, so they can review and discuss them
before merging them into another branch. You can also integrate with other systems and have Github report
additional information about things like build results,
test coverage, and deployment status. Team members can use this information to discuss the code
and submit reviews that approve it, or request changes that need
to be addressed before merging. Whether you approve the changes,
or ultimately decide not to merge, the pull request remains intact
on Github for future reference, as a unified record
of the decision-making process, around that set of changes. Github's flexibility supports workflows
with more complex branching needs, too. One example of a more robust
branching strategy is the Git Flow. Git Flow relies on long-lived branches
for simultaneously developing new features while supporting current releases. In the Git Flow, you have two primary
branches: <i>master</i> and <i>develop</i>. The <i>master</i> branch
will always reflect the most current production-ready state of the software,
while the <i>develop</i> branch reflects the latest development
for the next release. You also have supporting branches
that each have specific purposes. <i>Feature</i> branches work
like <i>feature</i> branches in the Github Flow. <i>Release</i> branches help you
prepare the work on <i>develop</i>, that will be included
in the next release version. And <i>hotfix</i> branches let you make <i>critical changes</i>
to the <i>master</i> branch, without impeding work
on <i>develop</i> or the next release. Let's walk through
a typical workflow with the Git Flow. Developers create <i>feature</i> branches
off of the <i>develop</i> branch and merge them back into<i>
develop</i> when features are ready. When it is time to create
a new production release, you'll make a decision
about which new features will be included in it. At that point in the <i>develop</i> branch,
you start a <i>release</i> branch. This allows work to continue
on <i>develop</i> without disrupting the preparations for releasing
the new features to production. You <i>may</i> find that there are
a few bugs to fix before releasing. It's okay to add that work
to the release branch, but it's best to avoid
adding new big features to an existing <i>release</i> branch. Instead, save them for a future release. When the release is ready,
you merge the <i>release</i> branch into <i>master</i> and tag it
with a version number. Github recognizes tags in your project and lets you easily
create releases from them. Now, all of the work that you merged
into <i>develop</i>, prior to the <i>release</i> branch, is available in production
as part of the newest release. You can safely merge any bug fixes
from the <i>release</i> branch back into <i>develop</i>. And then, delete the <i>release</i> branch. Suppose a critical bug
arises in production. You can create a <i>hotfix</i> branch off
of <i>master</i> to address the bug immediately, while planned work continues on <i>develop</i>. When the bug is fixed, you can merge
the <i>hotfix</i> branch into <i>master</i>, tag the work, and create a new release. You'll <i>also</i> want
to merge the <i>hotfix</i> branch back into <i>develop</i>,
or to the next release branch, if one currently exists. Let's review that one more time. In software development branching kind of forms the skeleton
of your workflow. It could be minimal and straightforward,
highly-complex, or everything in-between. Regardless of your approach,
Github remains flexible for you. Modular workflow features
like pull requests and integrations with your preferred external systems
help you power a workflow, where everyone can use the best tools
exactly when they need it. For help crafting a plan that puts Github at the center
of your development workflow visit <i>github.com/business</i> to learn more. ♪ (outro music) ♪
