0

I want to do a pull in GitHub and want to perform a GIT Rebase to clean up intermediate commits before issuing a pull request. I want to know if the following procedure is proper.

While I'm pretty sure no one is building on top of my branch, for future references, I want to avoid rewriting history (avoid pulling the rug out from under others). I'm thinking of a cherry-pick procedure like the following (assuming my feature branch is called "feature_branch"). Note that my intention for the original feature_branch is to note that it is now abandoned.

  1. Create a new branch from the head of master, something like "feature_pull_rebase"
  2. Replay all commits (cherry-pick) from the "feature_branch" onto the "feature_pull_rebase"
  3. Make pull request from the "feature_pull_request" onto master.

Is this a proper way to handle this? Or is there some danger with this?

EDIT: The master branch is not under my control, it's a repository I want to contribute to.

ShuberFu
  • 689
  • 3
  • 15
  • I would like to understand you question better. What are you afraid will happen when you rebase? – mrrusof Jun 08 '16 at 21:43
  • @mrrusof My understanding is that rebase is like reset, in that it destroys commit histories. I don't want to run the risk that when I rebase, I wipe out the commits that other developer are depending on. – ShuberFu Jun 08 '16 at 22:11
  • @SterlingW are you trying to `sync a fork`? Can this help: https://help.github.com/articles/syncing-a-fork/ ? – Tomasz Kowalczyk Jun 08 '16 at 22:23
  • @TomaszKowalczyk Technically yes. However, some repo maintainers have policy to minimize the amount of merges and request for a rebased version so you don't get a bunch of merge commit for a fairly long feature branch (I think it was Leaflet who asked me to do that once). In short, sync creates a merge if it can't fast-forward, and I want to eliminate merges (and potentially allow the master to fast forward the pull into it). – ShuberFu Jun 08 '16 at 22:26
  • @SterlingW I understand, then follow the instructions from the link in my comment, but in step 5 do a `git rebase` and you'll be good. – Tomasz Kowalczyk Jun 08 '16 at 22:27
  • @TomaszKowalczyk Thank you. I do understand how to rebase. My current understanding is that rebase destroy commit history, I want to know whether I'm wrong or if the procedure I used in my question would help minimize the change of me destroying commit histories that other developer are basing their changes on. – ShuberFu Jun 08 '16 at 23:00
  • Your procedure is okay. `git pull --rebase master` also works. So does `git rebase master feature_pull_rebase`, which I need to have a test. I personally prefer `git cherry-pick` or `git merge --ff-only`. – ElpieKay Jun 09 '16 at 00:40

0 Answers0