In the below Gitflow,
after Release branch is successfully merged with master branch, Release branch is also merged with Develop branch to update the fixes given during Release-Master merge.
Production bug fixes for that release will be given by branching Release branch and other branches, as well.
Problem is, if Release branch is merged into Develop branch but not deleted then Develop branch cannot be deleted(in future), after developers are done with their project. Down the line, Develop branch will end up with multiple Release branches merged but not deleted... At any point, if there is no developer working on a repository, then Git should have a Master branch and multiple Release branches only.
Can any branch(say Release) be in a state, where it is merged but not deleted?
答案 0 :(得分:2)
Can any branch(say Release) be merged but not deleted?
Merge and delete are completely independent actions. Though there's some protection in place to avoid its unintentional use, unmerged branches can be deleted. And merged branches are not automatically deleted in git
.
Github has an option to automatically close branches that were merged, but that's happening "above" the git layer in the github business logic.
Down the line, Develop branch will end up with multiple Release branches merged but not deleted... At any point, if there is no developer working on a repository, then Git should have a Master branch and multiple Release branches only.
You seem to want to make the existence of branches reflect something meaningful. This decision is up to you and your other git coworkers. But consider this: As long as a branch exists, its relationship to other branches can be seen ( most directly by git diff
, and by seeing which branches are head of and/or behind which other branches). Once the branch is gone, no such comparison can be done. So it's up to you to decide whether removing the branches is your favorite way to express work in progress.
I for one champion continuous integration with a few long lived branches ( develop -> master for example ), tagging points in master if you choose to cut releases, and removing short-lived feature branches after they've been merged into develop, whenever convenient. But I would never assume their existence, or for that matter, absence , to mean anything. git
can tell me exactly what the differences are. I'd stick to that. Removing the feature branches is a maintenance task that doesn't compound interest very quickly when deferred indefinitely.