There are already more than 100 notes and only now have we got our hands on git. It probably seemed too obvious. There will be no commands in the note, but a general approach will be described. In the following there will be a working example.

Initially, git flow was very popular. Now – GitHub Flow (aka development through MR/PR). In general, the change occurred due to the fact that now it is rare to support multiple versions at the same time, because it is simply too expensive.

Development is normal

  • the dev/<ticket>-<short description> branch is being created from main. For example, dev/MY-123-adds-create-user-endpoint.
  • there is work going on in the branch. The corresponding MR/PR is created in Gitea/Gitlab/Github (hereinafter simply MR).
  • we don’t care about individual committees in the branch, the description of MR. is important.
  • after the end of development, MR is embedded in main with a single commit (squash). The description of the committee is taken from the description of Mr.

The release is normal

  • a tag is created for the commit in main. For example, v1.2.0
  • CICD creates a release in terms of Gitea/Gitlab/Github (and inserts the generated release notes there).
  • CICD creates the necessary artifacts (for example, docker image, installer or package in Maven)

Developing a hotfix

  • a hot branch is created from a tag. For example, release/1.2 from the tag v1.2.2 (before this fix, 1.2.1 and 1.2.2 came from main, i.e. they were not hot)
  • work is underway in the branch, usually MR is not created
  • in the first commit (so as not to forget, technically it is possible in any), we describe how in the commit for main to generate release notes correctly. The description of the other comits is not so important.
  • after the end of the release development, a regular development branch is created from main and fixes are transferred there (the complexity of the transfer, and indeed the need, depends on how much main differs from this branch). This new branch is already following the standard procedure.
  • at some point in time, the hot branch is deleted (if we expect that there may be more fixes in the future, we may not delete it immediately)

Hotfix release

  • as normal, but the tag is placed on the commit in the hot branch
  • of course, this is a change of only the 3rd digit in the version, because only the correction
  • otherwise, it’s like a regular release

Key points (aka architectural decisions)

  • I want to leave maximum freedom inside the branch and, conversely, the purity of the story in main, so squash embedding in main
  • the release does not change the repository code – release notes and versions – something external to the code. Why? It is not clear why automatic changes to the source code - this leads to all sorts of problems from time to time.
  • versioning follows semantic versions. So for the specified commit, the previous version is automatically calculated, and according to the notes left in the description of commits, it is automatically understood which of the 3 digits needs to be increased by one.
  • there is no need to make a release to deploy to test environments. In this case, the version will be of the type v1.2.3-7-g432e5, where 7 is the number of commits in the branch, and g432e5 is the id of the last commit.
  • There may be several features and bug fixes in one MR/PR. Why? The number of test environments is limited, and corrections can be in one line. The release note parser should support this. Therefore, the specification https://www.conventionalcommits.org/en/v1.0.0 / as it is, it does not fit (and few people use it for the same reason).
  • from the point of view of CICD, the manual launch of the release is performed from the main and hot branches
  • code checks at the CICD and code review level are not described here – yes, it all needs to be done

PS. It is clear that there may be other options, this is just my vision for backend projects.