0

I have branches alpha, beta, and master. I also have branches feature_a, feature_b, feature_c, and feature_d. I then:

  1. Merge feature_a into alpha
  2. Merge feature_b into alpha
  3. Merge feature_c into alpha
  4. Merge feature_d into alpha

There are issues with feature_b feature_d (or perhaps they've missed a deadline and are still in the process of being tested), but the rest are ready to go to the beta branch.

How would I be able to merge only select "branches" into the beta branch from alpha, so that only feature_a and feature_c can be merged up? Will history and ancestry remain intact (assuming the feature branches get pruned or deleted)?

I'm guessing something to the extent of git merge beta feature_c...alpha , git merge beta feature_a...alpha (those commands won't work but that's the theory behind what I've attempted so far).

BLaZuRE
  • 2,356
  • 2
  • 26
  • 43
  • Assuming there were a way to do such a partial merge, would you plan on bringing in `feature_b` and `feature_d` at a later time? – Tim Biegeleisen Mar 24 '16 at 04:41
  • I'm not sure precisely where your concept of what git does when merging has gone off the rails, but I think it has. See http://stackoverflow.com/a/35954651/1256452 for background (this isn't an answer, just some background reading to, perhaps, get you out of the weeds, back towards the tracks). – torek Mar 24 '16 at 04:42
  • To add to Torek's dialog, in Git you generally don't bring part of a branch into another branch, so there is no real concept of partial merge. There is `git cherry-pick` and `git rebase`, both which would functionally give you what you want, but I suspect should rethink your workflow first. – Tim Biegeleisen Mar 24 '16 at 04:45
  • @TimBiegeleisen Possibly, but not definitely. Just like other branches, it could get deleted or merged into another feature branch. – BLaZuRE Mar 24 '16 at 04:58
  • @torek I understand how git is built and the model. How is git used in development when issues are found and the feature either can't go with its other merged features or one of the merged-in feature gets delayed? – BLaZuRE Mar 24 '16 at 04:58
  • 1
    You need to be a workflow where this is not a problem. If you don't want several commits in a branch which might get merged somewhere, then don't make the commits. – Tim Biegeleisen Mar 24 '16 at 04:59
  • Hm, well, the point (even more distilled) is that `git merge` merges *commits* (not actually branches, it's just that we usually point the merge at one branch-tip while being on another branch and hence at its tip). You can't pick apart a commit at this level. Git uses the current commit and the argument commit(s), uses the DAG to find the merge base(s), and then does the merge. You can, if you like, make *new* commits that contain less than the tip commits on your four branches in question, and then merge *those* commits. Just be sure you know what your merge base will be for later merges. – torek Mar 24 '16 at 05:06

1 Answers1

1

If you only want to merge some branches, you could just merge only those branches:

git merge beta feature_a feature_a

Now, if you want to merge only those branches at the state where they were when you started the release (ie: when you merged them into alpha), then, you could tag them at the moment of this merge, with tags eg feature_a_release-n, etc... ; so that to merge into beta you could do:

git merge beta feature_a_release-n feature_b_release-n

We can also think of an alternative, because you might rightfully want to actually merge the features between themselves in order to test them all together, before proceeding to beta. In that case, instead of an alpha branch, you might want to do a branch per release, eg: alpha-release-n. And if you notice an issue with a feature branch after creating this release branch, you could just create a new one, say alpha-release-n.2, which doesn't incorporate the un-wanted branch.

Final subjective though: this workflow, with a feature branch per team, was the one used by my company a couple of years ago. Since then, the R&D has more than doubled, and we found some flaws in this workflow. (for instance because late integration may reveal conflicts after a few days, which is a rather late feedback).

Without going into to much details, after dedicating a lot of efforts into setting up reliable non regression tests all across our codebase, we now only commit into master and we consider that it should be able to go into production at any time.

gturri
  • 13,807
  • 9
  • 40
  • 57