Replies: 2 comments 1 reply
-
Rebasing alters the commit hash history when a branch is not up to date. In GitHub "rebase and merge" always alters the commit hash history, even when the branch is up to date. "Merge with merge commit" keeps the commit history intact. I resorted to releasing from a release branch up to date with the main one with only the version commit included. |
Beta Was this translation helpful? Give feedback.
-
I wonder what would happen when a release branch needs rebasing because of a conflict. Perhaps it's an idea to figure out a way to use tags alone for deciding on a new version and make the commit hash irrelevant. |
Beta Was this translation helpful? Give feedback.
-
I just noticed that the release commit has a different commit hash than the created tag. I run releases on release branches that then get merged into the main branch after the release is done. This seems to break versioning for a second release on a new release branch (after merging the first release branch into the main branch). I am guessing the reason for this is that you can skip commits but not entirely sure. Has anyone else had this issue?
Beta Was this translation helpful? Give feedback.
All reactions