larlet-fr-david-cache/cache/87088098369e5eadca6728c963966792/index.md

title: How to GitHub: Fork, Branch, Track, Squash and Pull Request
url: https://gun.io/blog/how-to-github-fork-branch-and-pull-request/
hash_url: 87088098369e5eadca6728c963966792

<p>This guide will teach you how to properly contribute to open source projects on GitHub. It assumes that you already know about how to use <b>Git</b> for version control and that you already have a GitHub account.

</p><p><i>Psstt.. if you already have a GitHub account and  you want to <b>earn more money</b>, <a href="https://gun.io/social/login/github/">sign up for Gun.io with your GitHub profile</a> and we'll pair you with people looking for developers based on your portfolio!</i>

</p><h4>Getting Started</h4>

<center><img src="http://i.imgur.com/LiEI3.png" alt="How to GitHub Guide Open Source" title="How to GitHub Open Source Guide"/><br/><i>GitHub displays these instructions when you start a new project.</i></center>

<p>GitHub is pretty great about giving advice to users starting new repositories, but it isn't very helpful when it comes to contributing changes back to other projects.  Hopefully, this guide will help.

</p><p>Before you get started, find the page of the project you're looking to improve. Poke around in the code a little bit, familiarize yourself with their development styles, check the commit log to see who is contributing and check out the profile of the core maintainer.

</p><h4>Check the Network</h4>
<center><img src="http://i.imgur.com/naZ6I.png" alt="How to GitHub Guide Network" title="How to GitHub Open Source Guide Network"/><br/><i>The network graph. Notice that somebody is already working on a 'mobile' branch, so you probably wouldn't want to duplicate their effort.</i></center>

<p>The first thing to do is check the <b>Network</b> tab on the project to see all the other forks that other people have made. Spend a few minutes digging around in them, as it's quite possible that somebody is already working on the problem that you'd like to see solved. It'll also give you an idea of the activity of the project, and how likely it is that your changes will be merged in.

</p><h4>Opening an Issue</h4>
<center><img src="http://i.imgur.com/oksQI.png" alt="How to GitHub Guide Issues" title="How to GitHub Open Source Guide Issues"/><br/><i>You've got issues, man.</i></center>

<p>Next, head over to the <b>Issues</b> tab. Have a look around, see how many issues there are and if anybody has opened up the issue that you're interested in working on.

</p><p>This is an important step that many people forget about, and they just submit major pull requests to maintainers without considering that the maintainers might not have the same <i>intentions</i> with the software as they do. This is especially true if a new feature requires <b>user interface/design changes</b>, as often, that's the aspect of programs that people are the most <i>protective</i> of.

</p><p>If your issue doesn't exist already, open up a new issue. Standard human interaction rules apply here; be friendly, be polite, say thanks for making the project, describe the bug or feature you'd like to work on and then offer to help.

</p><p>Hopefully, they'll reply shortly with some input on how to solve the problem.

</p><h4>Making Your Fork</h4>

<center><img src="http://i.imgur.com/VWFCB.png" alt="How to GitHub Guide Hardcore Forking Action" title="How to GitHub Guide Hardcore Forking Action"/><br/><i>Hardcore Forking Action</i></center>

<p>Here's the fun part! Hit 'Fork'. Now you've got your own version! Go to the page, get the ssh: url from the box at the top and then

</p><pre>git clone **your ssh/git url**</pre>

<p>to your local machine. Hooray! You have the code on your local machine now.

</p><h4>Make Your Fork Track the Original Upstream Repo</h4>
<center><img src="http://i.imgur.com/bbNRs.png" alt="How to GitHub Guide Hardcore Fork" title="How to GitHub Guide Fork"/><br/><i>It's a fork. Hur hur hur.</i></center>

<p>This step isn't absolutely necessary, but I find it <b>very useful</b> if you plan on working on this project for anything more than a very quick fix. Use the following commands to add the 'upsteam' (original project location) as a remote branch so that you can get their <i>updates</i> into your branch. Replace the 'upstreamname' and 'projectname' values with that actual user/project name that you're trying to track.

</p><p>

</p><p>This will add the original project as a remote named 'upstream'. To get the code, type:

</p><pre>git fetch upstream</pre>

<p>Then, to merge it into your own project, type:

</p><pre>git merge upstream/master</pre>

<p>Tada! Now you'll have an up-to-date version of the upstream code in your current branch.

</p><h4>Setting Up A Development Branch</h4>
<center><img src="http://i.imgur.com/fI9qT.gif" alt="How to GitHub Guide Development Branch" title="How to GitHub Development Branch"/><br/><i>Guys, remember the old internet? Oh man.</i></center>

<p>Now you're getting ready to start hacking, you'll want to switch off of the 'master' branch and onto a different branch for your new feature. It's <b>important</b> to do this because you can only have <i>one</i> <b>Pull Request</b> <i>per branch</i>, so if you want to submit more than one fix, you'll need to have multiple branches. Make a new branch like this:

</p><pre>git branch newfeature</pre>

<p>Then switch to it like this:

</p><pre>git checkout newfeature</pre>

<p>Now you're on your new branch. You can confirm this by simply typing 'git branch'.

</p><h4>Hack!</h4>

<p>This part's up to you. Hack along as you normally would until the code is in the state where you're happy with it, it performs the task as described and it passes all the tests you've written for it. Yayyyy!

</p><h4>Squashing Your Commits</h4>

<center><img src="http://i.imgur.com/FgOPu.png" alt="How to GitHub Guide Squash Commits" title="How to GitHub Squash Commits"/><br/><i>Squash. Hur hur hur.</i></center>

<p>If you're a <i>heavy committer</i> like me, you've probably got lots of poorly messaged commits ('works!', 'broken', 'fuck', 'woo', etc.). This is a bad habit, but I haven't been able to break it yet and <i>I know I'm not the only one!</i>

</p><p>Before you submit your pull request back upstream, you'll want to <b>squash</b> these commits into a small handful of well-labeled commits. To do this, we're going to use the <b>git rebase</b> command. First, take a look at the commits we've made with <i>git log</i> and figure out the commits that we want to squash. If we wanted to squash the last 3 commits into one, we'd open up an an interactive rebase like this:

</p><pre>git rebase -i HEAD~3</pre>

<p>This will bring you into your editor with some text that will look something like this:

</p><pre>
  pick df94881 Allow install to SD
  pick a7323e5 README Junkyism
  pick 3ead26f rm classpath from git
</pre>

<p> To squash those commits into one, change to something like this:

</p><pre>
  pick df94881 Allow install to SD
  squash a7323e5 README Junkyism
  squash 3ead26f rm classpath from git
</pre>

<p>Then, save/quit, and you'll be brought to into another editor session. Describe the changes as well as you can and save/quit again. Hooray! You've squashed your ugly commits into one nice one. Now you're ready to submit a pull request.

</p><h4>Submitting a Pull Request</h4>

<p>Once you've commited and squashed your changes, push them to your remote like this:

</p><pre>git push origin newfeature</pre>

<p>Then go to that page on GitHub and change branches to the one for your new feature.

</p><center><img src="http://i.imgur.com/aAd2v.png" alt="How to GitHub Guide Submitting Pull Requests" title="How to GitHub Guide Submitting Pull Requests"/><br/><i>Submit a Pull Request!</i></center>

<p>Then, click on the little button that says 'Pull Request'. This will bring you to a page asking you to describe your change. Describe it thoroughly.

</p><center><img src="http://i.imgur.com/5Euiy.png" alt="How to GitHub Guide Describing Pull Requests" title="How to GitHub Guide Describing Pull Requests"/><br/><i>Describe your Pull Request.</i></center>

<p>Then press 'Submit Pull Request'. Hooray! You did it. Now, you're not quite done yet. If the maintainer finds some problems with your code, they won't want to pull your changes until you fix them. Fortunately, whenever you commit and push more things to that branch of your code, they will be included in that pull request until it is closed.

</p><h4>Accepting And Merging a Pull Request</h4>

<p>Bonus! If you're on the receiving end of a pull request, how do you merge the changes? Easy - press the button! GitHub now has an auto-merge button which does everything for you in one click. However, it doesn't always work, in which case you'll have to do the merge on your own machine, like so:

</p><pre>
git checkout master
git remote add contributor git://github.com/contributor/project
git fetch contributor
git merge contributor/newfeature
git push origin master
</pre>

<p>And then their changes will be properly merged into your main master branch.

</p><h4>So, Your Pull Request Was Rejected. Now What?</h4>

<center><img src="http://i.imgur.com/Qyyh5.gif" alt="How to GitHub Guide Fork Project" title="How to GitHub Guide Fork Project"/><br/><i>Some forks are unavoidable.</i></center>

<p>Sometimes, for technical or organizational reasons, your pull request will be <b>rejected</b>. This can feel really frustrating, and there are a few different ways you can proceed. Just remember to <i>act rationally</i>.

</p><p>The simplest thing is to simply <b>accept their judgement</b>. It's their project, and <i>a good maintainer knows when to say "no."</i> If their argument is logically sound, you should accept it. If you don't think it's a particularly important feature, hopefully whoever is looking at the project will check the Network and Issues tabs of the upstream project and will notice your changes. However, I think this is a pretty poor solution in cases when the upstream maintainer is wrong or unresponsive.

</p><p>A better thing to do is <b>write about it</b>. Write about it on your blog, start a discussion on a mailing list, and solicit opinions from the community about what the best way to proceed is. It'll also give some Google-juice to your project/issue, which will help other people who ran into the same problem you faced.

</p><p>The last option is to sever ties with the upstream and <b>declare yourself the new maintainer of the project</b>. This should only be as a <i>last resort</i> and should only really be done when the upstream project is dead or has gone completely off the rails. That being said, this kind of <b>software deadheading</b> can actually breathe a lot of new life into a project - just look at how LibreOffice has managed to revive the OpenOffice project by severing ties with Oracle.

</p><p>If you do this, you should rename your project to differentiate it from the upstream, explicitly state your reasons for the schism in your README, and be sure to give proper copyright credit according the the open source license they originally chose. <b>Maintaining an open source project carries quite a lot of responsibility, so make sure you're prepared to care for the project once you create such a schism.</b>

</p><h4>Wrap Up</h4>

<p>Hopefully this little guide was useful for getting you started with collaborative software development on GitHub!

</p><p>If you're a developer looking for more jobs, we at Gun.io would like to help! You can <a href="https://gun.io/social/login/github/">sign up with GitHub</a> and we'll automatically pair you up with freelance and full-time job offers based on your existing code portfolio!
</p>