Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Development Tools

Josie Nagy
Josie Nagy
14,992 Points
Posted by Josie Nagy
Josie Nagy
14,992 Points

How do pull requests really work?

I just recently started using git at work and for personal projects and still don't fully understand how it works.

My question is, once you've forked someone else's repo on github (let's say 'CSS_Modules'), does it not now function as separate repo from the original?

Then if I make a pull request on my repo ('Josie's_CSS_Modules') with new commits, how come the original repo that I forked from ('CSS Modules') still magically connects to my personal repo and accepts them to the master?

Wouldn't it make more sense if the new pull request I made was added to my repo ('Josie's_CSS_Modules') instead of the original one ('CSS Modules')?

My confusion comes from the fact that I worked on a different project in bitbucket where I didn't fork the project, just cloned it and then later created pull requests. So why fork something and create more steps when you can just do that directly?

I've already watched several tutorials and taken the treehouse classes, but I don't think this aspect was ever mentioned anywhere. Maybe it's obvious, but I personally don't get it.

Thanks for reading and if you know any articles or github repos that explain this concept, please share. ❤️

3 Answers

Liam Clarke
Liam Clarke
19,938 Points

Hi Josie

I think the way you described, you do not have your remotes set up to work from the main project that you forked, ill explain below:

TL;DR Forking allows you to have your own repository that you can contribute towards and Cloning only allows you to copy a repository and contribute only if you are explicitly declared as a "Contributor".

Forking Forking in its basic sense means copy this project and start a new project with it. A forked project is rarely contributed back to the original repository, it is mainly used to start your own project.

However, in a working environment with a team, there can be times where a fork is contributed back to its original.

For example: A team of 10 wanted to create a Front-end framework called ('CSS Modules') they could all fork the main repository and then work on individual parts, once these parts are done they could be merged back to the original repository allowing multiple people to work on their own smaller projects like ('Josie's_CSS_Modules') without getting conflicts with the main* ('CSS Modules') project, this is done through setting up an origin remote and upstream remote.

So a Fork is a separate repo, as your forked repository is now the origin, but still can contain a connection to the main repository through an upstream.

Cloning Cloning in its basic sense means copy this repository and use the copied repositories origin. However, a clone can only be contributed towards if you are explicitly declared as a "Contributor".

Once a project is forked, you would then clone your forked project to use locally.

For example: Using the same example above, A new developer joins the team and is tasked to work on a small project to check their competence, they could set up a project and just clone straight from that project as no one else will be working on it, it is theirs.

In Conclusion Use Forking when you want your own project, whether this is to build upon yourself or to have the second workflow for projects that you contribute towards.

Use Cloning to create a clone or copy of the target repository.

Useful extra information

Atlassian has very good guides and documentation for git, I recommend reading through some of these below in particular

Git Fork

Git Clone

adding a remote for origin/upstream/etc

Josie Nagy
Josie Nagy
14,992 Points
Josie Nagy
Josie Nagy
14,992 Points

Hi Liam,

Thanks a lot for taking the time to reply to my question, your answer cleared up a lot of doubts I had about this part of git. I hope other students also find it useful!

I did research based on the reply and links you sent me and I can now better understand:

  • the concept of having an origin remote vs upstream remote
  • the difference between being a collaborator (core development team) vs a contributor (were you can't directly contribute without a pull request)
  • forking vs cloning
  • tracking remote branches and doing it is useful

I've also been contributing on GitHub since I wrote this question, so practice has also helped. :)

I admit I still don't 100% understand how a lot of people syncing their forks with the upstream can be done without causing a lot of merge conflicts, but maybe I'll understand that better with more practice.

I thought this StackOverflow reply did a good job at explaining the context of a workflow that involves fork syncing: https://stackoverflow.com/questions/34219861/why-fork-syncing-is-useful

Thanks again!

Liam Clarke
Liam Clarke
19,938 Points
Liam Clarke
Liam Clarke
19,938 Points

Hi Josie

I'm glad the post helped, that StackOverflow answer does give some good explanations on fork syncing.

Lastly, I think looking at something called a rebase will help you understand how multiple people sync their forks.

Although this is quite a difficult concept to get your head around as rebasing has varying levels of complexity depending what your doing, once you understand it, it clears up all your problems with syncing repositories.

I won't describe it as the link above gives a good description but I'll try to put it in a familiar example.

Rebase

Using the above Front-end Framework example:

If you pull the repository ('CSS Modules') to your own forked repository ('Josie's_CSS_Modules') and then I pull from the main repository to create ('Liam's_CSS_Modules'), we are all in sync, the history of the projects are identical.

My task is to add a new feature to the repo and I've now completed it, I then merge this back into the main ('CSS Modules') and everything is fine with my new feature added.

Now you have finished your task, you try to merge but you get a merge conflict. That is because you don't have this new feature that I added in your history, your now behind the main ('CSS Modules') because of my merge.

In order for you to send your commit, you must do a rebase first:

git fetch upstream master
git rebase upstream/master

This will fetch my new feature and put your work on top of it so your history is the same as the main repositories, making us all in sync again.

Now you can go ahead and commit as normal.

I hope this makes sense, Good Luck!