CODEWITHSUNDEEP
gitgit-merge
Jonathan Arciaga
Jonathan Arciaga

Reputation: 1

Is the master branch identical to release candidate branch after merge?

Currently, all our code is off of a master branch. We want to start creating a dev/candidate branch that would be designated for a release. For example, we branch off of master and create a branch called "1.2". As developers, we branch off that 1.2 branch into individual feature branches which we'll work in. After the work is done, we merge the feature branch into the "1.2" branch till the "1.2" branch is complete. At that time, our test team will test the "1.2" branch, if the branch passes testing, then it gets blessed to be merged into the master branch for official release.

What I'm wondering is if Master branch will be identically the same as the "1.2" branch after we merge "1.2" into Master?

We have strict rules of the tested binaries being exactly the same as what is released. Is this current structure of branching possible? Is the "1.2" branch identical to the Master after merge?

Or do I have a incorrect understanding of proper branching strategy for our needs, which is entirely possible.

Thanks!

Upvotes: 0

Views: 231

Answers (1)

TTT
TTT

Reputation: 28869

tl;dr: If no new commits appear on master after branch 1.2 is created, then Yes, the code will be identical on master and 1.2, and they may point to the same commit also if you allow fast-forward merges.

Details:

  1. To expand on the initial scenario, if new commits appear on master after branch 1.2 is created (perhaps for a hotfix into production), then master should be merged back into 1.2 to keep it up to date (or at a minimum, the same changes need to be merged or cherry-picked into branch 1.2 also, but merging master back would usually be preferable). If none of those happen, then the branches will have diverged and later when you merge 1.2 into master, you will not have the same code on both branches.
  2. When 1.2 contains the tip commit of the master branch (the normal case as you described), a fast-forward merge is possible. When a fast-forward merge is possible, if you do perform a fast-forward merge, then both branches are identical, from both a code standpoint and a commit standpoint. If you instead elect to use --no-ff with the merge, the branches will be identical from a code standpoint, but master will have one additional merge commit. Both builds would still produce the same output. (See the next point for caveats to this.) Note a fast-forward merge is the default, when it's possible.
  3. Theoretically, subsequent builds of the same code should provide the same functional output, however, it is often the case that subsequent builds of the same code will not produce identical binaries, due to differences in timestamps that are often baked in, or other environment variations that exist at the time of the build.

Regarding your goal of achieving identical binaries, as long as you don't bake the commit ID into the executables, then whether you perform a fast-forward merge or not shouldn't affect the resulting binaries. The result would be the same whether you build 1.2 or master after merging it in, excluding other environment factors such as timestamps, etc.

Upvotes: 1

Related Questions