26

I forked a project on Github.

Let the remote upstream be upstream and my remote repository be origin. My local master branch is set to track the remote master branch. Then I added some stuff in local master, and I merged with the upstream every now and then.

Not until today when I want to issue a pull request did I find the problem: the pull request consists those merge commits, and those unwanted commits that I did previously without care. However what I want is just to submit the last commit I did, which should be pulled as a single commit. What can I do to rescue this?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Ivan Xiao
  • 1,919
  • 3
  • 19
  • 30

5 Answers5

28

Instead of merging you want to rebase. You can do this manually, or automatically when pulling.

git pull --rebase upstream master
git push --force origin master

Once you've started doing merges though this will get hard to do, you'll need to reset the branch back to before you did a merge commit.

Arrowmaster
  • 9,143
  • 2
  • 28
  • 25
  • This one seems work. I am just not sure if I have to do step two, since every time I merge with remote master there will be a merge commit. – Ivan Xiao May 16 '11 at 18:17
  • 8
    -1 for the git push --force solution to be offered on the same level as git push --rebase. User needs to be warned of the possible pitfalls with push --force which is potentially more damaging, and other users of the repo must know how to react correctly if they branched off a commit that was entirely removed by the push --force and want to merge back – prusswan Nov 22 '11 at 08:37
11

If I understand your question, you want to get rid of the intermediate/throwaway commits that you did in your branch. Try something like this:

git checkout -b for-upstream remotes/origin/master (create a new branch from the upstream origin)
git cherry-pick <sha-of-the-one-commit-you-want-to-submit> (fix any conflicts if necessary)

this should give you a local "for-upstream" branch which contains just the upstream master + your 1 commit. You can then submit that branch for pull request

csd
  • 934
  • 5
  • 12
  • I think the first line needs to be `git checkout -b ...` and not `git branch -b ...` (make that change and I'll up-vote this here answer) – founddrama Jan 12 '13 at 12:40
6

On Github, You can't create a pull request for a single specific checkin on a branch that has multiple checkins separating it from upstream.

Create a branch specifically for each pull request you intend to make. This allows you to continue working without fear of polluting a pull request.

wewals
  • 1,447
  • 9
  • 9
3

Would this work: Create a separate branch with just the commit you want and issue a pull request on that branch.

Jay Sullivan
  • 17,332
  • 11
  • 62
  • 86
  • This is what I'd recommend. Don't be afraid of merge commits though, if the branch contained just that single commit you wanted pulled and a bunch of merges to keep it up to date with master, there's nothing wrong with that. – Tekkub May 11 '11 at 21:44
  • This is exactly what I am asking -- I don't know how to do this appropriately. – Ivan Xiao May 16 '11 at 17:57
0

This looks like an answer to your question (section "Update 2011-04-15" of the topic):

Git workflow and rebase vs merge questions

Micah describes the technique of squash merges which let you merge changes from your feature branch as a single commit to the master branch.

Community
  • 1
  • 1
Ivan Akcheurov
  • 2,173
  • 19
  • 15