CODEWITHSUNDEEP
gitgithub
Phrogz
Phrogz

Reputation: 303520

Create pull requests from messy GitHub fork

I've forked a project on GitHub. I've made a small of pile changes, all in my own master branch. I'd like to get them accepted upstream, so I want to create clean pull requests for each.

I have created an "upstream" remote in my repo. I believe that for each pull request I want to make I need to:

  1. Create a local branch, and check it out
    git checkout -b mynewfeaturename
  2. Set this branch to the current state of the upstream (not-my-project) repo. (Rebase? Reset?)
  3. Look through my own commits and "cherry pick" them to apply them to this branch.
  4. Push this branch to GitHub.
    git push origin mynewfeaturename
  5. Create the pull request from the branch.

My question is twofold:

To help others in a similarly bad state as myself, I'd recommend that the ideal answer would list explicit commands for each of the above steps (or whatever the correct steps may be), holding our hand and walking us through the process from start to finish.

Upvotes: 0

Views: 64

Answers (1)

larsks
larsks

Reputation: 312770

  1. Create a local branch, and check it out. (git checkout -b mynewfeaturename)
  2. Set this branch to the current state of the upstream (not-my-project) repo. (Rebase? Reset?)

The combination of the above two steps doesn't make sense. You can get to the same place by:

git checkout -b mynewfeaturename upstream/master

That is, create a new local branch mynewfeaturename based on the current state of upstream/master, and then build that branch by selectively applying commits.

  1. Look through my own commits and "cherry pick" them to apply them to this branch.
  2. Push this branch to GitHub.
  3. Create the pull request from the branch.

This is largely correct, although you'll want to make sure that if a particular change depends on a previously submitted PR that it is based on that PR, rather than directory on the upstream state.

That is, if you have previously submitted a PR for myfeature_A, and you now want to submit a PR for myfeature_B which depends on the changes in myfeature_A, then:

git checkout -b myfeature_B myfeature_A

Depending on the state of your local repository, your life may also be easier if you first start with an interactive rebase of your own branch to clean up the history by squashing together related commits.

Upvotes: 2

Related Questions