At work we squash feature branches instead of merging them to keep release branches clean and disconnected from the feature branch.
We're currently doing that with:
git checkout release
git merge --squash feature
git commit -m 'Squashed Feature 123'
But due to some backend automation system requirements, we would like to know what sha in the feature created the squash commit without merging and without modifying the feature branch.
The goal of the automation is to tell management that the feature has been squashed into release (regardless of conflicts and its resolution). The only consistent way of doing it would be to somehow "register" the feature HEAD sha into the squash commit. If the developer pushes more commits to the feature, the automation system would flag it as "unsquashed" again, since the feature HEAD now points to a sha that has not been squashed.
I've found 3 ways that could flag the squash commit so that the automation system could identify feature as squashed into release, but none are satisfactory:
1) git merge -Xours feature after the squash will create an additional commit that could serve to indicate to the automation system the feature sha that was merged into release. But now we have 2 commits plus the whole history just like a merge, so not a solution since we don't want the feature history.
2) git replace --graft release release~1 feature after the squash will make feature an ancestor of release. This works too, but just like 1), this will bring history again, which we want to avoid, so not a solution either.
3) git commit -m 'squashed from [SHA=$feature_squashed_sha]' the string can flag the automation system the squash commit is actually a merge from a certain commit. This could be a solution.... The problem is that getting that commit message right is messy and prone to errors.
Any insight on how to accomplish this in a manner that is both robust for the automation to parse and easy enough for users to implement into their merge workflow?
Now, we don't have to use a git merge --squash, any other non-mergeable approaches are welcome if it makes the squash point to its original sha in a consistent way.
Also, the automation system can be configured to run any command, as long as it gives the answer to the question has the feature HEAD been squashed into release?
How about...
git checkout release
git checkout -b feature-123-abcd1234
git merge --squash feature-123
git checkout release
git merge --no-ff feature -123-abcd1234
Obviously this ends up with merges again, but they are maybe trivial enough to be allowed?
Another solution would be to store the squashed SHAs in a growing text file within the repository itself.
Finally, you could simply tag the feature branch each time you squash it...