0

At some point in our project we started a new development environment in which, in order to run properly, we were forced to make many changes in our code. Those changes are in a branch named "dev-test" that was created from "master".

This environment (that started as a test) is actually becoming our development environment, so when a new feature has to be done, our flux would be:

  • create a new branch from "dev-test" (let's call it "feat1")
  • develop and test in local
  • merge to "dev-test"
  • test it in "dev-test" environment
  • if everything is OK -> merge to "master" (and eventually deploy to production)

Well, this last step is actually the problem. How could we get the changes from "feat1" without getting the changes from "dev-test"?

A small graphic to clarify:

                 f1---f2             feat1
                 /      \       
      d1--(dn)--d2--d3--d4--(...)    dev
     /     
m1--m2--m3--m4--m5--m6--m7           master

What we want would be to add commits "f1" and "f2" to branch "master" (after "m7"). If we just merge "feat1" to "master" we will have all "dn" commits on master (what we don't want). We can always cherry-pick "f1" and "f2" from "feat1" to "master" but I'm afraid that in more complex cases we can miss some commits or messed up with merges.

There are any good solutions for this problem? Something like "merge all commits from A branch to B branch"?

jolmos
  • 1,565
  • 13
  • 25
  • Rebase or cherry-pick (same thing, really) is the only way: the existing `f2` commit ties back to the existing `f1` commit which ties back to `d2`. **No existing commit can ever be changed** so you must *copy* the commits that have some unwanted thing about them to new-and-"improved" commits that lack the unwanted aspect. Rebase works by cherry-picking, then making the *branch name* select the last of the copied commits. – torek Nov 30 '22 at 14:27

1 Answers1

1

You need to rebase on top of master (as a new branch, say)... something like:

git branch blah feat1
git rebase dev-test blah --onto master

Now the branch with the changes from feat1 only can be merged into master.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • Thank you. I was playing around with `merge-base --fork-point` and cherry-pick, but this is much cleaner. If someone it's curious about it, check this repo for testing that I have created: https://github.com/jesusolmossanchez/git-merge-test I will try it with examples in real life next days, I hope not having problems. By the way, I'm sure you mean `git checkout -b` not `git branch -b`. I got it, but edit it if you can, so none can be confused. – jolmos Nov 30 '22 at 15:41
  • 1
    Actually, no `-b`. I do not mean to checkout because `git rebase` will do a checkout so no point in going there. – eftshift0 Nov 30 '22 at 15:42