0

I've encountered a workflow on a new team I'm a little unfamiliar with. The goal for most pull/merge requests is to have a single, squashed commit, in an effort to have a clean history.

That is fine and well, as usually the squash commits occur once a PR has been tentatively accepted (to be merged once squashed and push --forceed). Thus, working from the develop branch is usually safe.

However, I have a conceptual problem with this strategy when branching work from a commit with a high likelihood of being re-written. This diagram illustrates current and desired states for such a scenario.

crude is as crude does

  1. Work is completed on feature/foo and is squashed in preparation for peer review
  2. Work begins on feature/bar (branched from commit A)
  3. WIP commits are added (E & F)
  4. Peer review reveals minor changes which are added to the Pull Request (commits B & C
  5. Pull Request is approved, pending squash commit
  6. Branch feature/foo is squashed and re-written to commit D

This is where I'm unsure how to proceed. My question is how can I best "replace" the ancestor of branch feature/bar? Some solutions that come to mind are branching off of the new squash commit (D) and cherry picking F..E and then overwriting (deleting and re-checking out) branch feature/bar. Is there a better solution to this i.e. using rebase?

jahsome
  • 881
  • 8
  • 18
  • Why don't you just rebase your branch feature/bar onto new branch origin/feature/foo ? – Vlad May 17 '16 at 23:41
  • 2
    Rebasing won't give the desired result here because the `A` commit would then appear in the history of `feature/bar`. The easier way out of this is to not squash commits in `feature/foo` after the branch has already been pushed and made public. Instead, squash locally and then push. – Tim Biegeleisen May 17 '16 at 23:48
  • i agree with @tim. rebase will not work since it will only "re-order" the commits but not squash them. What you can do is to squash and then use `git pull --rebase` or to use `cherry-pick` and to bring those commit range to your squashed branch – CodeWizard May 17 '16 at 23:55
  • Rebasing will work, but it won't give the desired result, because squashing `feature/foo` effectively _rewrites_ the history of that branch, thereby changing the base. And rebasing is all about sharing a common base which we want to retain. – Tim Biegeleisen May 17 '16 at 23:59

0 Answers0