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
Learn how all the individuals and components of an open-source project fit together.
Resources:
- GitHub Guides: About Forking
- Some companies prefer the “forking workflow” of open source for their internal projects. Instead of giving each developer on a team access to the main repository, they ask each developer to fork the main repository and then the developers issue pull requests across the fork. Review Scott Lowe’s blog post on The Git Fork-Branch-Pull Workflow.
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
Most open source projects follow
a very similar work flow.
0:00
Someone or a group of people
are in charge of the project.
0:03
There is another group of people who would
like to contribute code or bug reports to
0:07
the project, and another group of people
who just want to use the software.
0:11
In this video,
0:15
I'm going to explain how each part of
the open source puzzle fits together.
0:16
First, let me explain what each person's
role is on an open source project.
0:20
Each project on GitHub has an owner.
0:25
The owner is the person
who owns the repository.
0:28
Sometimes that owner is
a user like kdaigle and
0:30
sometimes the owner is an organization,
like acmeinc.
0:34
The owner has complete control over
the repository, whether it's public or
0:37
private, who can push
code to the repository,
0:42
and every other setting a repository has.
0:44
An owner can give push access to
collaborators and maintainers.
0:48
This is a lot like when we added
the developers team to our organization
0:52
in one of the last few stages.
0:56
A maintainer is someone the owner
trusts to review pull requests and
0:58
keep the project on track.
1:02
Some open source projects only
have one maintainer while
1:04
other projects may have dozens.
1:07
A maintainer can push and pull code.
1:09
A contributor is someone who doesn't
have direct push access to the code.
1:12
Let me explain what I mean.
1:16
On all of the projects we've been
working on up to this point,
1:18
we've had both push and
pull access to the repository.
1:21
On an open source project,
1:25
most people will only have
the ability to pull the code down.
1:26
This is called a contributor.
1:30
You need to ask permission to get
your changes into the project.
1:32
You usually do this with a pull request.
1:36
You create a pull request, and
then a maintainer, who has push and
1:38
pull access, accepts your changes and
they become a part of the project.
1:42
Last but not least are community members.
1:47
These are people who use
the code every day but
1:50
don't contribute back to the project.
1:52
Most people fall into this
category in open source.
1:55
Community members are vital though
as they'll find most of the bugs
1:58
in the project.
2:01
Since we want to contribute back
to an open source project, we
2:03
fall into the contributor category, or at
least hopeful contributor at this point.
2:06
We don't have push access to the main
project, and we want to make a change.
2:11
Since we can't push to the open
source repository directly,
2:16
we'll need to create a fork.
2:19
Let me show you.
2:21
The original repository,
we'll call it acme-inc/open-source,
2:22
who won't let us push to it, which means
we can't make our changes directly to it.
2:27
We'll need to fork the repository.
2:32
A fork is a GitHub feature where we
take a copy of the repository in its
2:34
current state and we move it into
our user account or organization.
2:39
A copy, or our fork, is owned by us.
2:44
Since we own it,
we can make changes directly to it.
2:48
When we're ready to send our changes back
to the original acme-inc/open-source
2:52
project, we can submit a pull request
between the two repositories.
2:55
But more on that later.
3:00
Right now let's create our first fork.
3:01
All right let's go back to
github.com/realkdaigle/hello-treehouse.
3:05
It's the same repository
we used in the last video.
3:11
To fork my repository,
in the tip right click the fork button.
3:14
You have an option of where
to fork the repository to.
3:19
You could choose your user account or an
organization account you have access to,
3:22
like the organization you
created earlier in the course.
3:26
This setting is to choose who you want
to own this copy of the repository.
3:29
For now, choose your organization account
by clicking on your organization name.
3:34
GitHub is now creating a new
repository owned by your organization
3:39
that you can push to.
3:43
This repository contains a copy of
the code from my repository, but
3:44
you completely control this one.
3:49
You'll see under the repository name
that there is a little fork symbol
3:51
that points towards
the original repository.
3:55
With your own fork,
3:58
you could pretty easily contribute back
to the hello treehouse repository.
3:59
I'm an owner and maintainer of
the hello treehouse repository and
4:03
you're about to become a contributor.
4:07
In the next video, we'll open a pull
request for the hello treehouse project.
4:09
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