p100sch115518dI don't think that your approach would lead to the desired outcome. As Releases are branches with only some changes (Bugfixes) of the main branch, merging the release into the main branch is kind of unnessecarry and the state of main on the last commit from the release would differ from the state of the release.
While this is of no concern for a feature branch and you just delete it after the merge, the release branch is only discarded after the release is no longer needed. Whe have branches going back to our 2017 release because one customer refuses to sign a update contract, despite paying more in support fees because of the missing features and automation (yes, it's just running some SQL queries for them that the newer versions execute automatically).
@p100sch but technically a repo is just a list of commits. So you can remember the hash of the last commit in the release branch. Delete the branch itself but then rewind the repo to that commit.
The state would be the same as the release branch before you deleted it?
Maybe I'm calling the branches wrong. We user release, master, develop.
New features go into develop then when we release we cut develop into a release branch and maybe do some edits to remove things that aren't ready for release.
But yes I do see your point then merging back to develop would be a problem...
Have to do some cherry picking
p100sch115517d@donuts if I understood the correctly, you have:
#5 //cherry pick
#4 //remove feature
If that is true, than merging Release into Dev is only possible if you revert the commits that where not present in the Dev branch and reverting possible commits in the Dev branch that were not in the Release branch and revert the revert after the merge.
#5 - Release label
Revert Revert 3.5
Now it is possible to checkout #5 and get the release. But it is more cumbersome if not done automatically, confusing people that don't really care that much about a clean git tree.
p100sch115517d@donuts I don't mean to tell you it is not possible or that it is stupid to do so, but that other people probably won't understand and let your clever solution and effort go to wast.
If you think that they value the clean git tree and understand the solution, then go for it and show them the result on your local machine.
I'll try to put it in words, but it's not easy. There are several things intertwined which should be kept seperate imho.
1) What is a release?
A release should be a non mutable state of the source code which can be identified.
Wording sucks - but my point is: When you release a version, the version number must be unique and must point to a fixed revision.
This should _never_ change. Release a new version when fixes are necessary, but _never_ include fixes after the version is released.
2) What's a GIT tag?
https://git-scm.com/book/en/... Read this. ;)
A git version tag makes only sense if you have a branch like "main" which will never be deleted.
Otherwise your git tag's would be invalid if the branch get's deleted.
Which brings me to the next point...
3) Semantic versioning
Depending on your versioning, it might make sense to have seperate major version branches.
These branches should never be deleted.
IntrusionCM330917dWhen you have these branches, you could create new version tags targeting the branches.
product-1.0 would eg. have a GIT tag for 1.0.1
So the minor number would stem from the GIT tag, the major number is used for the branch.
The approach works well as long as you keep the semantic versioning intact: New features shouldn't be deployed to a product-* branch, a product-* branch receives only hotfixes / bugfixes.
+1 for tags for releases
Though I disagree about long lived releaes. There's no value in keeping merged branches around in git. They're reffable by commit id and tag.
@p100sch actually it's more like this
Feature 1, 2, 3, ...
When done merge, into Develop
Branch Develop to a Release, make adjustments,
So at this point have branches
-(Master) Basically the golden source, if server hardware dies, restore it from this code
-Feature 1, 2, 3
-Release X (with some extra changes and version in properties file bumped)
Merge Release into Master, Develop
But still have all the branches.
So what I'm thinking is Feature should be autodeleted the moment it is merged to Develop.
Same with Release when it is merged back into Dev and Master
**But you tag the last commit on the branch with release-X before deleting**
So if he need a hotfix like release X.1, just create the branch from this tag.
The effect is the same as branching off release-X? But would this be cleaner and make the repo more efficient?
@IntrusionCM I sort of imagine a git repo like the blockchain. The moment something is committed to remote, it cannot be undone or changed. Unless you Rebase the whole remote repo but that's really rare? Only done if someone maybe screwed up and commits a huge file?
So if you check out the commit, you get everything that is was based off of and that will never change?