Home / Questions / 618
Accepted
Ruslan López
Asked: 2020-12-08 08:15:12 +0800 CST 2020-12-08 08:15:12 +0800 CST

How to make a historical commit pull request to another repository?

  • 772

I've been working on a fork of a project GitHuband I'm many commits ahead of the original repository.

I wanted to integrate it but they asked me to send it in several pull requests instead of all the commits in one (because there were more than 20). Is there a way to make a commit pull request that doesn't contain the latest commits I've made to my repository?

PS: Sorry for the Spanglish, but I really don't know how those terms are translated into Spanish.

git

2 Answers

  1. Best Answer

    If I understand your question, you can use rebase:

    git checkout master 
git pull
git checkout <branch>
git rebase master

    So you will have your branch above the current master.

    Or if you want to use only certain commits, you can make a copy of master, and then cherry-pick from your branch, only the commits you want in your pull request.

    git checkout master
git pull
git checkout -b branch_nuevo
git cherry-pick <revisión 1> <revisión 2> ... <revisión N>

    This way you'll have a fresh branch with just the commits you want, and you can use it like normal on GitHub.

    • 5

  2. The solution that I find the most fun to this problem is the interactive rebase, which also works in many other situations. The procedure is the next:

    1. You create a new branch with a name descriptive of what your pull request does.

      $ git checkout -b nombre-de-la-rama

    2. You do the rebase:

      $ git rebase --interactive origin/master

    That opens an editor, in which the commits that you would be moving are listed, there you can make various changes, including deleting lines which discards the commits that you will delete. When you're done editing the file, you save and history is rewritten (of this new branch we created, so your original commits are there in case all else fails).

    Then you push that branch and it makes a new pull-request with the part you're interested in.

    It is more comfortable than cherry-pick when the commits you are interested in are more than 2.

    conflicts

    If some of the changes that you want to keep depend on some of the changes that you don't, you will have conflicts as if it were a merge and they are solved in the same way.

    • 2