0

We use a master/staging/feature branch strategy. master & staging are long lived, and feature branches only exist until merged with staging.

When merging staging into master, our jenkins server squashes the commits to create a single "release" commit in master that's tagged with the version.

Unfortunately, some changes are missed, i.e. files deleted in the feature branch are still present in master.

We want staging to have the entire commit history, and master to only have a single commit that's tagged with the release number.

I know that the issue is with squashing the commits & a lack of a shared history, my question is how to achieve a single commit on master with staging having the full history automatically (this has to happen on a jenkins server).

I have looked at rebase but I can't figure out if it can do what we want automatically (this has to happen on a jenkins server with no manual intervention).

aj-ee
  • 1

1 Answers1

0

You could use reset --soft to achieve that so that the branches are "the same". So, you did your last release on master (at this point staging and master are "the same"). Then 1000 commits happen on feature branches and merges to staging. At this point you want to release on master again:

git checkout --detach staging
git reset --soft master # here is where the magic happens... all changes between master and staging are placed on index, branch pointer is set to master
git commit -m "New release" # if you want to have a more detailed comment, find the way to do it.
git branch -f master # move master pointer to new revision
git tag blahblah # tag revision or take it from here and do whatever you need

no merging involved. by the end of the process, branches will be identical.

eftshift0
  • 26,375
  • 3
  • 36
  • 60