Let's look at this workflow that is very
popular these days. You can call it the
open-source workflow, even though it's not
just for open source, as we'll see later.
My usual disclaimer, I don't expect that
you'll memorize this information. I won't
go into the technical details in this
training. I'd just like to give you a
concrete example of a way of working
that's only possible with distributed
version control. You'll probably have many
opportunities to learn this stuff by doing
it as you gain more experience with Git.
For now, just relax, and let's look at
this way of working. Look who's back,
Sonja, our developer friend. She's a
passionate developer, so she wants to
contribute to open-source projects over
the weekend, and she found a project on
GitHub that could use a few bug fixes, so
she plans to contribute to that. Let's say
that the project belongs to a GitHub user
called pluralsight, and it's called
marathonfish. The GitHub convention is
that a repo is identified by the name of
the user or organization that owns the
project/ the name of the project, so it's
pluralsight/marathonfish. So Sonja creates
a GitHub account. Let's say her GitHub
name is nusco. That's actually my GitHub
account. I'm using it here because I want
to be sure that I'm not stealing some
other user's name and dragging innocent
people into my example. So Sonja, or
nusco, to use her GitHub name, wants to
contribute to this project. The first
thing she needs is her own copy of this
repository so she can work on it. And
maybe you remember from the previous
module that she could clone this repo to
her local machine, and she'd get a
complete copy of the repo, history and
all. But instead, she does something
slightly different. Let me show what, and
then I'll explain why. Instead of getting
a local clone of the repo, Sonja asks
GitHub to give her a remote clone inside
the GitHub. This operation is called the
fork in GitHub's terms. Every project you
visit in GitHub has a button to Fork it.
It's this one. So when Sonja forks
pluralsight/marathonfish, she creates her
own copy of the project, so
nusco/marathonfish, and then she also
clones this repo to her local computer to
work on it, and she keeps
nusco/marathonfish on GitHub as her
remote. In a minute, I'll show you why
this complication, why Sonja didn't just
clone the original repo. So now Sonja
works on her contributions to the project.
She fixes a bug and creates a new commit
or a few commits in her local repo, and
all the commit says this little patch
here. Then she'd like to push the commit
to the original project. She wants her
changes incorporated here, but that's when
things get a bit more complicated because
Sonja doesn't have permission to push to
this project. It belongs to another user,
pluralsight. I mean, open-source projects
are public and all, but that doesn't
certainly doesn't mean that anybody can
just push code to any project. Instead,
open-source project have a maintainer, a
user an organization that decides which
contributions get into the project. In
this case, the maintainer is pluralsight.
So the problem here becomes as follows,
Sonja has a new commit for the
pluralsight/marathonfish repository, but
she doesn't have write access to that
repo, so she'd like to submit her
contribution to the pluralsight user so
that this user can hopefully roll it into
the original project. But Sonja's
contribution is on her private computer,
so how can pluralsight see those changes
or even know they exist? And now, we can
see why Sonja created a fork of the
original project because this fork can be
read by anybody, but it can only be
written by her. It's her copy of the
project on GitHub. So she can push the
changes to the fork, nusco/marathonfish,
and then she can use the defining feature
of GitHub. That's called the pull request,
that is, she sends a message to the
pluralsight user that says, look, I have a
contribution here on this fork of your
project, so why don't you come and get it?
And pluralsight can check the changes, and
maybe review them, maybe discuss them with
Sonja, or run the project's automated
tests on Sonja's changes, and hopefully
say, okay, I like these changes, and pull
these changes from Sonja's fork into the
original project. All those things can
happen inside the GitHub interface. The
entire project from the sending of the
pull request to accepting it can be done
in GitHub. And that's the open-source
workflow. It's actually a bit more
complicated than this in the general case,
for example, Sonja might have to keep the
original project as a secondary mode, as
well as her own fork so that if the
original project changes, she can get the
latest commits and solve many conflicts
before she sends a pull request. So there
are a few more wrinkles involved, but what
you've seen is the core idea of this way
of working. You fork a project, you clone
it to your local computer, you commit your
changes to it, push those changes to the
fork, and then send the pull request to
ask the maintainer of the original project
to pull your changes, and hopefully they
do. And if you think about it, this
workflow can only exist in a distributed
version control system. You cannot have
pull requests in a client server system.
You might remember, in the previous
module, I told you distributed version
control has its own ways to control
access, and this is one, and it works
great. Some open-source projects have
thousands of contributors from all over
the world, from core stable contributors
to occasional contributors who might send
a single patch and then disappear. And
even with all those people waltzing around
the project, they still maintain tight
control over what code gets into the
project, arguably, more control than the
typical internal company project. And in
fact, many companies these days are
adopting this way of working based on pull
requests for their internal projects. So I
called it the open-source workflow, but
it's becoming more and more common for
closed-source projects as well. And that
was my last example in this training. I
hope it gave you a glimpse of the power of Git and distributed version control.