JChauveau
JChauveau

Reputation: 11

git branching model and version to be tested

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

Answers (1)

TTT
TTT

Reputation: 29074

after merging to main branch, should I create a version from the main 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 to main 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:

  1. A bookmark to help you keep track of the version of code that is currently in Production.
  2. Maintaining the --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

Related Questions