0

I have forked a project form GitHub. I do my own development in the master branch (by creating branches for developed features/fixes and merging them back to master).

Now I created a branch bugfix-123 in my fork in order to fix an issue 123 in the original project. I want to create a new pull request in order to incorporate my fix into the original project. But I have noticed that the pull request does not contain only the bugfix itself, but also all my commits in the master branch since the fork was created.

How can I create the pull request containing only the single commit? Do I have to create another fork for that? What should I have done differently in order to be able to create pull requests in the original projects and also to perform my own development of the forked version?

xarx
  • 627
  • 1
  • 11
  • 27
  • Why your Pull request does not contain only the bugfix itself ? Have you done a `git merge master` on your new branch (`bugfix-123`) for incorporate in `master` ? – R. García Mar 04 '19 at 17:57
  • Possible duplicate of [Send a pull request on GitHub for only latest commit](https://stackoverflow.com/questions/5256021/send-a-pull-request-on-github-for-only-latest-commit) – Code-Apprentice Mar 04 '19 at 18:01
  • @R.García It sounds like the OP has several other features and/or bug fixes that they merged into `master` prior to creating the `bugfix-123` branch. – Code-Apprentice Mar 04 '19 at 18:02
  • @Code-Apprentice Thank you for the link, but the solution therein does not satisfy me. – xarx Mar 05 '19 at 13:11
  • @xarx In order to help you further, please [edit] your question to include the exact commands that you tried. Then describe the result and how it differs from what you want. – Code-Apprentice Mar 05 '19 at 17:21
  • @Code-Apprentice Thank you, I have already resolved my problem in my answer below. Your link helped me a lot. – xarx Mar 05 '19 at 18:44

2 Answers2

1

As already mentioned in Send a pull request on GitHub for only latest commit, it is necessary to create a separate bugfix branch for the pull request. Edit: While I thought my answer differs from the accepted answer in the link, I probably mis-read it - I did it the same way:

git fetch upstream              #synchronize local repo from upstream

git checkout upstream/master    #the upstream repository master has already a local branch, upstream/master, it's not necessary to create another copy
git checkout -b PR-bugfix-123     #create a branch dedicated for the pull request, and make it your current branch
git cherry-pick <commit hash>   #merge changes from a specific commit; cherry-pick also allows picking a range of commits

git push origin PR-bugfix-123   #publish the branch to the fork in order to create the pull request

Notation:

I decided for the following convention:

  • The development branch is master, still, no need to rename it
  • The development bugfix branch is still bugfix-123
  • The pull request branch is prefixed with "PR": PR-bugfix-123
Code-Apprentice
  • 81,660
  • 23
  • 145
  • 268
xarx
  • 627
  • 1
  • 11
  • 27
  • I'm glad to see that you figured it out. This answer seems to be the same as the accepted answer to the question you linked. Note that my answer using `git rebase` will basically provide the same result with fewer commands. The only difference is that it will move the existing `bugfix-123` branch to point at the cherry-picked commit rather than creating a new branch. – Code-Apprentice Mar 05 '19 at 20:13
  • Yes, but this difference is substantial to me :-) And yes, you're right, I mis-read the accepted answer in the link, probably. – xarx Mar 05 '19 at 22:02
0

First, you should add the original project as a remote:

git remote add upstream <URL to original project>

Now fetch the branches from the original:

git fetch upstream

You will now have a branch named upstream/master which mirrors the master branch from the original repository. You can move your bug fix branch by rebasing on top of this branch:

git checkout -b PR-bugfix-123 bugfix-123
git rebase --onto upstream/master master
Code-Apprentice
  • 81,660
  • 23
  • 145
  • 268
  • I already do this, but this does not solve my problem. I don't see how `git rebase` could help. – xarx Mar 05 '19 at 13:10
  • @xarx `git rebase` will modify your branch so that it only contains the changes that you wish to include in your PR. – Code-Apprentice Mar 05 '19 at 17:19
  • It seems to me that `git rebase` would remove the bugfix commits from my development branch and insert them into the PR bugfix branch. Which would break my development branch. – xarx Mar 05 '19 at 18:41
  • @xarx Rebase doesn't remove any commits. Rather it copies the changes in a sequence of commit to create a new sequence of commits. It will then move your bugfix branch. This does not affect any other branches, including the development branch. See https://git-scm.com/book/en/v2/Git-Branching-Rebasing for an illustrated example. (Note how the original commits are still in the history as illustrated by the greyed out commits.) – Code-Apprentice Mar 05 '19 at 20:08
  • @xarx Perhaps the confusion here is due to my unstated assumptions. For example, I am assuming that you want to include all of the commits on your `bugfix-123` branch, but which are not in your local `master`, as part of the PR. – Code-Apprentice Mar 05 '19 at 20:16
  • I have my development tree, i.e. my master branch and my bugfixing branches. And I do not want to modify them anyhow. I want to create a pull request for one of the bugfixes, alone. `rebase` would re-arrange the commits and modify my development tree by moving the bugfix commits outside the development tree to the PR branch. This is what I want to avoid. – xarx Mar 05 '19 at 22:00
  • @xarx I think you misunderstand how rebase works. It does not "rearrange commits". It copies them in the exact same way that cherry-pick does. The only difference is that after cherry picking, it also moves the bugfix branch, which seems like something you don't want. I have edited my answer to create new branch instead. Now the commands in my answer will have the exact same result as your version using cherry-pick. – Code-Apprentice Mar 05 '19 at 23:37
  • @xarx Note that our answers are identical only in your particular case where you only have a single commit on your bug fix branch. My answer has the advantage of being more generally applicable to multiple commits. – Code-Apprentice Mar 05 '19 at 23:43
  • I have tested your answer, and it doesn't work. It simply creates a new branch `PR-bugfix-123`, and points it to `upstream/master`. Nothing else. I was investigating this a bit, and this is because I have my bugfix merged to `master` already. Nevertheless, thank you for your hint, I was aware only of the basic usage of rebase, as described in https://cs.atlassian.com/git/tutorials/rewriting-history/git-rebase, the first diagram in particular. – xarx Mar 06 '19 at 07:29
  • @xarx Since `bugfix-123` is already merged into master, then yes, the rebase won't work as I intend since the unstated assumption is that these are not merged. You can change the rebase command to `git rebase --onto upstream/master HEAD~` to get the most recent commit. The last argument here can be replaced with any so-called "commit-ish". See the documentation for `git rebase` for details. – Code-Apprentice Mar 06 '19 at 16:04