How to contribute to an open source project on GitHub

A step by step guide that

22 Comments

  1. Sverrir Sigmundarson

    Excellent guide, but missing one very important and complicated aspect that is crucial.

    How do you successfully update your fork and then your feature branch while still retaining your change commits when the upstream branch changes?

    Add that and this is pretty much complete.

    Reply
    1. Kasim

      You fetch upstream from time to time and rebase your feature branch against upstream/master before pushing/time to time.

      To keep your fork updated:

      You fetch upstream and merge upstream/master into your origin/master, then push origin master.

      Typically, you don’t need to keep your fork updated if the goal is to contribute to the main repo.

      Reply
  2. Stefan Gloutnikov

    Great article! Only thing maybe to add is how to pull new changes from the original project into your local master, if there have been any since originally cloned:
    ‘git fetch upstream’
    ‘git checkout master’
    ‘git merge upstream/master’

    Reply
  3. Milosh Bilosh

    Great article. I’ll definitely reference it to Github newcomers.

    Reply
  4. Andrew Ribeiro

    I’ll pass this out to some people that I always have to go over this with. Thanks for the article.

    Reply
  5. David Phillips

    You can update your local branch using this command: git pull –rebase upstream master

    Reply
  6. Pd

    Point 1 should be Choose not Chose.

    Reply
  7. Adnan

    Awesome. Short and sweet. No useless nonsense.

    Reply
  8. Lalit Kale

    You didn’t have to even search github. There is http://up-for-grabs.net/ with which you can find the project where you can contribute your first commit. Just my 2 cents..

    Reply
  9. Adnan Siddiqi

    @Lalit: Interesting Website!

    Reply
  10. Patrick Masson

    I’d recommend adding something about checking that the license is actually an OSI Approved License. I did a quick review of the featured and trending projects on GitHub and a few were not assigned open source software licenses, another mentioned a license but did not include it with the source, and a few (e.g. universalcore/elastic-git / https://github.com/universalcore/elastic-git) were not licensed at all–meaning that the work is actually, “all rights reserved,” and cannot be copied/used with our express permission of the copyright holder.

    It might be kind of a drag, but understanding licensing is the first part of contributing to a project. Even if a license is present, contributors will want to be sure that their work (and expectations) are in line with those of the original author, for example, copyleft and permissive licences and the ramifications of such.

    Thanks for the post,
    Patrick

    Reply
    1. Davide Coppola (Post author)

      Good point. I added a quick note in the first paragraph.

      Thank you for pointing this out.

      Reply
  11. Roshan

    I’d started on a project to help first time contributors to start contributing right away. The tutorial is a hands on one. Could you give me your feedback about that?

    Reply
    1. Roshan
    2. Davide Coppola (Post author)

      It would be better adding more headers to highlight what the paragraphs are about like in my guide.

      Also mentioning how to stay in sync with the main repo shouldn’t be at the end, but before starting with the contribution work.

      Reply
      1. Roshan

        Thank you for your feedback Davide

        I’ll be adding headers to provide a better step by step organisation for the tutorial

        I’m not sure if syncing part should be in the beginning. I wanted my users (my target audience is people who are doing open source contributions for the first time) to try on something and get value as quickly as possible. That was why I had least explanation about what is being done. Could you explain why you suggested me to put in on top?

        Reply
        1. Davide Coppola (Post author)

          Because, as I mentioned in my guide, you need to make sure your local branch doesn’t create any conflict with the main project before generating a pull request.

          Syncing AFTER generating a pull request is just bad practice and might be trouble.

          Reply
  12. jayson Mathew

    cool and awesome description and knowledgeable

    Reply
  13. Chris G

    Great article, but Kent C. Dodds free Egghead.io tutorial is a little bit more comprehensive IMHO

    https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github

    Reply
    1. Davide Coppola (Post author)

      it seems it is, but I honestly don’t like video tutorials for anything dev-related. Too fragmented and time consuming.

      Reply
      1. Chris G

        Not these. Kent does a great job. but to each his own for sure 🙂

        Reply
        1. Davide Coppola (Post author)

          I am sure he’s doing a great job.

          I was referring to video tutorials in general. I don’t believe they work for dev material because:
          – you can’t fast read
          – you can’t search
          – you can’t copy&paste

          no matter how good they are.

          But this is just my opinion of course and, as you said, I am sure some people find them useful/better.

          Reply

Leave a Comment

Your email address will not be published. Required fields are marked *