What is the workflow for contributing to an open source git repository?

I have to admit I’ve never contributed to an open source project because I do not understand the workflow. I’ve looked around many times at the git documentation but found it too hard.

I have made pull requests to private repositories for my client using a front-end like Team Foundation Server (TFS) or Visual Studio Team Services (was Visual Studio Online) for git repositories. I can also easily work alone on git repositories using the git commandline because that workflow is simple. But I would like to learn the git workflow using its commandline to contribute to open source projects.

  • How to see unmerged commits on emacs magit branch
  • Progress not displayed in Github contribution chart?
  • Undo a git merge, keep commits that came later
  • Continuous deployment to Dev/TestProd on Azure
  • Is there any way to list up git repositories in terminal?
  • Deploy specific features from the master branch
  • I read the following articles from the github documentation. I think I kind of know the workflow but I am not sure and I am scared to try it out on someone else’s project.

    1. Fork a Repo
    2. Syncing a fork
    3. About pull requests
    4. About collaborative development models
    5. Creating a pull request from a fork
    6. Creating a pull request

    What I really need is for someone to simplify the steps in a few, easy to understand bullet points.

    From my research so far, here is what I understand.

    Let us assume we want to contribute to an imaginary project named Boo Boo, the owner of which is named Baabaa. Let us assume that I, the person who wants to contribute to Boo Boo, have a github account at https://www.github.com/Water-Cooler-v2/

    Below are the steps I know the workflow till. After these steps, I don’t quite know what to do.

    1. First I fork Boo Boo from https://www.github.com/Baabaa/Boo-Boo into my own github account. Now, I have my own Boo Boo fork at https://www.github.com/Water-Cooler-v2/Boo-Boo.

    2. Then, I clone my own Boo Boo into a folder on my computer like so:

      MrWaterCooler@WatersComputer MINGW64 /c/WaterCooler/MyFolder/
      $ git clone https://www.github.com/Water-Cooler-v2/Boo-Boo.git

      This links my local copy of the repository in the folder MyFolder/Boo-Boo with the remote named origin that points to my own fork, i.e. at https://www.github.com/Water-Cooler-v2/Boo-Boo.git

    3. Then, I link my local repository in Myfolder/Boo-Boo with Baabaa‘s remote repository also. I do this by copying the url of Baabaa‘s repository and typing:

      MrWaterCooler@WatersComputer MINGW64 /c/WaterCooler/MyFolder/Boo-Boo
      $ git remote add upstream https://www.github.com/Baabaa/Boo-Boo.git

    4. Next, I verify that the new remote named upstream has been linked to:

      MrWaterCooler@WatersComputer MINGW64 /c/WaterCooler/MyFolder/Boo-Boo
      $ git remote --v

    5. Next, I fetch all the branches from the remote upstream into my local repository in my computer by typing:

      MrWaterCooler@WatersComputer MINGW64 /c/WaterCooler/MyFolder/Boo-Boo
      $ git fetch upstream/master

    6. Now, I checkout my local master branch, which would anyway be checked out by default, but I’ll check it out anyway just to be sure:

      MrWaterCooler@WatersComputer MINGW64 /c/WaterCooler/MyFolder/Boo-Boo
      $ git checkout master

    7. Then, I’ll make some changes to the files in my local repository. In this case, I’ll edit an existing file (not shown below because that doesn’t use any git commands), and I’ll add a new file named MyNewFile.txt.

      MrWaterCooler@WatersComputer MINGW64 /c/WaterCooler/MyFolder/Boo-Boo
      $ touch MyNewFile.txt

    8. Now, I’ll merge the upstream/master branch into my own master branch.

      MrWaterCooler@WatersComputer MINGW64 /c/WaterCooler/MyFolder/Boo-Boo
      $ git merge upstream/master

    And then, now is the step I am not so clear about. Do I push? To where? My own fork (remote origin master) or Baabaa‘s Boo-Boo (remote upstream master)?

    Or, do I create a pull request?

    Could you please validate the workflow for the first 8 steps listed above, and then complete it?

  • staging all files except specific files using glob patterns in git
  • Apartment (ruby gem) to host customers' websites?
  • Is my C# Entity Frameworks project haunted?
  • Why does 'git checkout' work only for some branches?
  • “git branch -d” doesn't delete branch
  • How to download a branch with git?
  • 2 Solutions collect form web for “What is the workflow for contributing to an open source git repository?”

    You just fork the repo, clone it to your local machine, optionally create a branch and do your changes. It really doesn’t matter how you work locally or in your own repo. You don’t have to use GitFlow. You can do Trunk-based development or whatever works for you. When you are done, you push it to your own repo. Then go to GitHub and open a PR against the original repo. That’s all there is to it.

    Regarding adding the original as a remote: the main reason to add the original repo as a remote is when you intend to update your fork with changes from the original repo (merging, rebasing, cherry-picking, etc). If you just intend to do a one-shot contribution to the original, like fixing some bug, it’s usually not necessary to have the remote. It makes sense to add it for long term contributions though.

    Your workflow is correct.

    • Always create your own branch on your fork and push that to origin. Creating the branch helps the maintainer when reviewing your branch.

    • Once your changes are pushed, go to original repo and there should be a button at the top of the page prompting you to create the Pull Request.

    Typically, the most challenging part of contributing to open source projects is finding where to start. To help with this problem, there are two sites to help find projects with nice jump issues.


    Git Baby is a git and github fan, let's start git clone.