Etiquette of GitHub Contributing, Pull Requests vs New Issue

I was wondering what the proper etiquette to contributing on GitHub is?

Should you submit a “New Issue” first and discuss the problem?

  • How I can store some local changes that survives git reset --hard
  • How to build R package from GitHub?
  • How can I reference a specific repository using Git?
  • Convert a git subproject into a regular folder
  • How to set up Git source control for matlab?
  • github failed to push some refs after branch deletion
  • Or do you take some initiative, code, then do a “Pull Request” and discuss the code further there?

    My concern with creating a “New Issue” first is that if you do a “Pull Request” after, there would be two issues #’s created… seems like a waste.


  • SSL error when trying to PULL from GIT
  • Git best practice one or multiple branches
  • gem command not found through git bash
  • configuring user and password with git bash
  • Send to github via curl command line (Windows)
  • Replace GitHub repository with a new Android Studio project while preserving old commits
  • One Solution collect form web for “Etiquette of GitHub Contributing, Pull Requests vs New Issue”

    The difference is quite clear:

    • if you don’t think you can contribute back a patch, open a “New Issue” (following the same kind of checklist than the one described here).
    • if you think you can make some patch to fix the issue, fork the repo, and make a “Pull Request” (once you have pushed your patch back to your fork).

    If you make a pull issue first, and then create a pull request, nothing stops you to reference the issue URL in your pull request comment, in order to avoid writing again the context of your patch.

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