Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I 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 -
@donuts if I understood the correctly, you have:
Dev:
#1
#2
#3
//brach
#5 //cherry pick
Release:
#1
#2
#3
#4 //remove feature
#5 //bugfix
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.
Main:
#1
#2
#3
#3.5
Revert 3.5
//Merge
#4
#5 - Release label
Revert 4
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. -
@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. -
Hm.
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.
Eg
product-1.0
product-1.1
product-1.2
...
These branches should never be deleted. -
When 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. -
@p100sch actually it's more like this
Feature 1, 2, 3, ...
When done merge, into Develop
Release time:
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
-Develop
-Feature 1, 2, 3
-Release X (with some extra changes and version in properties file bumped)
After release:
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?
Question about managing git branches.
For releases, we branch develop (the main branch) into a release.version branch in which we bump the version and do any last minute bug fixes for issues found in testing.
After the release we need it back into the main branch as well as master.
But also we keep the branch as well in case we need it such as for a hotfix release.
Is keeping it right though?
General issue on my team I feel is nobody deletes their feature branches after they are done and merged into the main branch. I think there is a feature in most Repos where it can auto delete these branches when a PR is merged.
And well branches themselves (at least the HEAD) are sort of just bookmarks. All commits can be accessed by their hash and basically is a full snapshot of all the commits that upto that point that it was based off of?
So you could just tag the last commit in the release branch with release.version and delete the branch itself? And that I think is the correct, normal way?
Not sure how to explain this to my boss or team as they aren't big on technical details...
question
git