Git workflow: How to merge commits made only on new branch

We are using git to track development and versioned releases and ran into some issues merging branches. Here is our workflow:

production/1.0.0  A--B

stage/2.0.0       A--B--C--D

development       E--F--G--J--L
                         \
feature                   H--I--K

Feature development happens on a feature branch that was created from development and when ready is merged back for demo and testing.

This all works well, the issue is when the developer who created that feature branch goes to put their feature into a stage branch for deployment. Because they branched off of development at G, when they go to merge, it includes EFG when they only want to merge HIK.

The goal with our git workflow is to let developers mark their own code for ready for release and coordinating that the entire development branch will be able to be merged into deployment branch is not feasible as development happens around the world.

Is there a git command to just merge commits made on a feature branch? I know of rebase and cherry pick, but a feature can be made up of a large number of commits with merges from development catching up their feature branch. Is there a better solution?

Is this workflow correct? Are we trying to do something that is not sustainable?

That would be a git rebase --onto coupled with git merge-base:

git checkout stage/2.0
git rebase --onto stage/onto $(git merge-base development feature) feature

That would replay the commits of the feature branch after G (which is the "merge base" commit between development and feature) onto the stage/2.0 branch.

Result:

stage/2.0.0       A--B--C--D
                            \                   
feature                      H'--I'--K'

development       E--F--G--J--L

The old H, I and K commits are still referenced in the reflog (git reflog), but have been cherry-picked and replayed on top of stage/2.0.

Is this workflow correct? Are we trying to do something that is not sustainable?

It is, with the following caveat:
It needs to involve careful tests after such a rebase, because H, I and K where done on top of G, which is not present at all in the stage/2.0 branch.

If those commits depended on content based on G, that initial content would not be found in the staging branch. Some regression testing should make that apparent.

Using git cherry-pick (which also can replay multiple commits) would duplicate those commits onto the staging branch, leaving the feature branch as is (ie not rebased on the staging branch).
That seems strange, considering you will need to start which commits were cherry-picked, and which other new feature commits were not yet cherry-picked to staging.

What would happen if development was merged into feature between I and K? (The developer caching up their branch)
Would the cherry-pick also include that merge and all the development branch code along with it?

Yes it would include the merge commit, but not the all dev branch. In any case, it is not ideal. The best practice is not to merge dev to feature, but rather rebasing feature on top of dev (git rebase dev).
Then, when feature is ready, rebase --onto stage/2.0

So what the rebase --onto command does is basically move the feature branch onto stage/2.0.0?

Yes.

Does the feature branch go away?

No: it is re-created by re-applying each commit patch onto stage/2.0.0.
The old commits of the feature branch seen before the rebase --onto are still there, but invisible, referenced only by git reflog, as mentioned above.

The nested command $(git merge-base development feature) Is that applying the changes from feature to development before moving the branch to the stage/2.0.0 branch?

No: it is to compute a starting commit for that feature branch, that is: the development commit from which feature branch was started.
If I did not use that, but a simple git rebase, the commits from feature branch would include all commits accessible from feature HEAD (and that would include also the development commits)

Recommended topics

Hot tags