Making a pull request

Question
1

I’m just trying to clarify the standard work flow for making a pull request to a Github project for which you don’t have commit access. Is it?

  1. Already-have / open a Github account
  2. Clone the project to your own Github account.
  3. Clone the project from your Github account to your desktop(or laptop).
  4. Branch the project on your desktop with a name that describes the intended commit.
  5. Checkout the branch.
  6. Make the changes.
  7. Stage the changes.
  8. Commit the changes.
  9. Upload the named branch to your Github account.
  10. Make the pull request on the project’s Github home account using the named branch from your Github account.

Can this be cut short, if you have no intention of maintaining a fork? Is it possible to make pull requests from the command line on your local machine? I’m asking partly to improve my own work flow, but also so I can teach others.

2

I think you do need a fork on Github in order to make a PR. If you had write access to the main repository you could make a PR from a different branch without forking. But we don’t do that, even those that do have access.

For the record, I never keep the branches in my fork up to date with the main repository. I pull the main branch from the main repository (to my local clone), create a branch, and only push that work branch to my fork.

If you prefer working from the command-line, check https://github.com/github/hub.

3

2 is usually called “fork”, 4 and 5 are sort of one step (git checkout -b branchname), 7 and 8 may also be one step (git commit -a), but other than that, that seems right.

Your description sounds very long, but really, it’s not that big a deal.

2: click fork (if you haven’t already forked)
3: git clone yourfork
4+5: git checkout -b yourbranchname
6: ???
7+8: git commit -a
9: git push -u origin yourbranchname
10: click pull request.

apart from step 6, it’s no more than a minute, step 1 is if you’re using github for the first time, and steps 2 and 3 are once per repo (though there may be a git pull instead of step 3 if you already cloned it before.

4

So merging 4 and 5 seems unproblematic.

I’m not sure its good to teach git commit -a to beginners. I think I’m right in saying that it modifies and deletes files, but doesn’t add files. Not very helpful in my opinion as deleting a file in git is more problematic than adding a file in terms of potential merge conflicts. I find it easier just to

git add -A
git -m "Blah blah"

every time rather than thinking about whether I’ve added a new file in the changes I’ve made.

So a relatively inexperienced developer might fork a project because there are no published executable artefacts or just to play around with it and experiment. Neither of those require a fork in their Github account. It seems to me that those uses for new comers to git should not be mixed with making a pull request, in order to avoid rebasing, stashing or git checkout --s. That beginners should just delete the directory and re clone, when attempting initial pull requests on someone else’s repository.

Step 6 (Step 5 after combining 4 + 5) could be very quick if its just changing a typo in a readme file.

5

You can actually do this from the github web UI if you’re logged in - you get a markdown preview and all. It’ll create a fork and a new branch for you. In fact, I sort of frequently do this.

Note that if that’s all you’re doing, the git commit -a is entirely unproblematic too. If you’re adding and deleting files, it’s not, but at that point the overhead of the git add (step 8) probably becomes negligible too.

6

I’d say the hardest part is when you want to make a second contribution somewhere in the future and your local clone is completely outdated.

1 Like
7

The trick for that indeed is to make the upstream remote your default branch to track on.

If your master (or 2.13.x, or whathaveyou) is tracking upstream, getting up to date is just a git pull away. I think this is also the workflow that @lrytz was suggesting.