Reputation: 11
I am willing to addopt the git branching model described here (which led to git-flow branching model).
From my understanding:
My question is the following: after merging to main branch, should I create a version from the main branch and retest it? Indeed, when merging from release branch to main branch, there may be conflicts to be resolved, so I want to retest it before deploying it. But this extra step makes me question the value of having both release and main branch.
So far, I am using the release branch to create versions that go to production, for I do not see the advantage of having a main branch.
Upvotes: 1
Views: 57
Reputation: 29074
after merging to
main
branch, should I create a version from themain
branch and retest it?
No. In a proper implementation of Git Flow, the release
branch will always1 be either equal to the same state as, or fully ahead of, main
.
when merging from
release
branch tomain
branch, there may be conflicts to be resolved
In a proper implementation of Git Flow, it is not possible to have conflicts when merging release
into main
, for the same reason as above.
Git Flow shared branch merges that can have conflicts (due to simultaneous development on different branches, such as develop
and release
, or hotfix
):
release
(or main
) into develop
.hotfix
(or main
) into release
or develop
.Git Flow shared branch merges that cannot have conflicts:
release
into main
.hotfix
into main
.I do not see the advantage of having a
main
branch.
Git Flow is a general branching strategy with some optional features that not everyone will need. The main
(or master
) branch serves 2 functions:
--first-parent
history of each deployment to Production.In one of my repos where we use Git Flow, I will commonly get asked, "What applications are being deployed with this release?" I can quickly answer this question by looking at:
git fetch
git diff --name-only origin/main..origin/release
Many Git UI tools also enable you to easily see the diff between any two commits, and searching by branch name is very easy.
Similarly, if you want to look at code changes between deployments, it is very fast and simple to compare the diff between any two commits in git log --first-parent main
.
That being said, you can still do all of this without having a main
branch. The difference is you would instead need to know, or lookup, the tag names that you wish to diff against. Also, when a hotfix is needed, you would need to look up the latest deployed tag name, vs being able to simply say "Go branch off of main
."
Side Note: some repos that use Git Flow use the branch name production
instead of main
(or master
) to help make it a little more obvious what it represents.
1One exception to "always", is after merging a hotfix
branch into main
, there may be a brief window of time before merging main
(or hotfix
) back up into the release
branch. During that time window of course release
would not be "equal or ahead" of main
. This should only be for however long it takes to complete the merge back into release
(or develop
if there is no active release
branch at the time).
Upvotes: 1