0

I am designing a Git branching strategy for our codebase. Till now, we have managed with a single master branch but given the size of the team and of our codebase, I want to enforce some basic Git discipline.

I am following the regular Git branching strategy. I have a production-ready master branch with the HEAD tagged as 2.224.0. Now say I checkout a development branch from this, and start developing my features. Note that the development artefacts are tagged over the tag of the HEAD of the master:

--->[Feature A(2.225.0)]---->[Feature B (2.226.0) (Signed-off by QA)]---->[Feature A Bug-fix (2.226.1) (Signed-off by QA)]

Now say I want to give a release containing Feature A and Feature B. What should be the release version of the artefact? Should I give a release with 2.226.1? This doesn't look fine to me because these are two new features from the perspective of the master branch. Ideally, I would increment the last number of the tag in master only when there is a hot-fix (for which I have a separate hot-fix branch). If I go with 2.227.0, my tag and release versions become inconsistent.

Prashant Pandey
  • 4,332
  • 3
  • 26
  • 44

1 Answers1

0

You don't really need to manually modify versions. E.g. you could work with 2.xxx where xxx is incremented with each build. There's usually not much sense in changing the version in source code.

When you decide to release the artifact you already know the version (because it was generated during the build). So you can tag your commit with that version once the decision about release is made.

Similar discussions on the topic: Gitflow Workflow with Maven - when to build what?

PS: large teams manage to work fine with single master branch, you can look up trunk-based development to see some materials on the topic. Usually the fewer branches you have the simpler the workflow. But you'd have to push to master frequently for this to work smoothly.

Stanislav Bashkyrtsev
  • 14,470
  • 7
  • 42
  • 45
  • I need to tag the different test artefacts for the following scenarios: Say I deploy 2.226.0 in PPE for testing but it broke some crucial feature. Now I want to roll-back to 2.225.0. I need to identify the corresponding artefact using the tag. Now say I am tagging every feature as SNAPSHOT. Now I can't roll-back as the previous artefact would have been overwritten by the newer SNAPSHOT. – Prashant Pandey Jun 15 '20 at 20:25
  • No, I'm not saying you need to tag every build. You may want to tag every _release_, but even that.. I don't know what this brings to the table. And you certainly don't want to overwrite builds (you shouldn't reference SNAPSHOT versions - only _resolved_ snapshots are acceptable). And I don't get why you'd rollback a version on your PPE (PREPROD?) env. Why not fix the problem and deploy the next version? And if you'd like to rollback - why not roll back to the previous version that was deployed? – Stanislav Bashkyrtsev Jun 15 '20 at 20:51