Git Workflows and release branches: many, one or not?

Question

For our web development, we have daily weekly deployments. There are times when we implement something in QA, but don’t check it for a few days, and then we have a production fix or a new improvement that needs to be released. Two questions:

(1) What will be a good workflow for this?

(2) What are the advantages and disadvantages of having one continuous, long-lived branch called production or release, as opposed to a new release branch for each release or just doing everything for the host and tagging it accordingly? Again, this is for web development with frequent releases that can be copied.

Answer 1

I'm not quite sure that I understand your problem correctly, but my situation is similar to yours, and I used (modification) the following approach: http://nvie.com/posts/a-successful-git-branching-model/

In short, we are talking about two main branches (master and development) and several types of supporting branches (functions, releases and corrections). Speaking of your case, you are likely to deploy your release branches in QA, and then, when you have a production patch, you would do it in the patch branch, and then merge it with both the lead and release branches.

As for your second question ... well, you know, there are many different opinions about branching strategies ( example ...) I would say that the continuous manufacturing industry works fine (and this does not mean that you cannot have a release branch to support your workflow).

Answer 2

In my previous work, we used a similar approach to what @Alexis mentioned, with one major difference. Keep in mind that we were working on a new version of some fairly large software (our code base was several million lines of code, between Java, flex and COBOL), and we had beta testing for partners. The releases were two- / weekly, including for the client (although they would usually be one release after the last, since he would first go through QA), and this week we had to perform a “cut”, test, basic QA a client of our code, who was another developer in the company, and then released a real QA.

In fact, the master was our dev branch. If the dev element should have taken more than one or two days, it was completed on the function branch, and then merged into dev when it was ready. There was another “future” branch of dev, which was reserved for fairly serious work with new functions (which significantly changed the program) or major refactoring. At some point, this will become the main “dev” when we decide that we have time to properly test and fix bugs, or that it is time to introduce new features and deal with the inevitable pain :)

When the time came for the release, a new branch was created with the name "release_x", then all the corrections that came from QA were implemented there and merged "up". By this, I mean that we can have two or three versions in the game at any given time, so the client will obviously have the oldest one that we could fix if they found showstopper. This will be done in the patch branch coming out of the corresponding version, which at some point will be merged with this version and removed (so that you can easily see outstanding corrections in the list of branches) and another assembly executed and sent to the client. The “fixes” sections existed so that we could select and select what fell into a particular assembly, which functioned both for the client release and for the developer release, in order to avoid potentially risky fixes for small problems that violate the release of the fix for showstopper.

Then it will be combined with the release that the QA guys had, then it will be combined with the release that other developers used (always the latest version due to their dependence on our plugins and the j2ee infrastructure to do their work), then back to dev. just to keep everything up to standard.

All releases that currently play the game have their own automatic build loop in Jenkins, as well as the dev branch, with some automated functional tests running on the more important ones (dev and QA mostly). Each assembly added a tag to the commit report, which was used as HEAD, and the assembly number was available from the program so that we could see exactly which version the error reporter used.

In fact, there are two dev branches, one of which for major work will be released later as a new major version. Unlock branches for each version, with patch branches resetting from them. Finding the latest version was no easy task; look for the release branch with the highest number.

The only drawback was that if you made many corrections when releasing several versions back, then the merging of the charts was ... interesting to perform :)

Answer 3

You should definitely

• create release branches
• Paste corrections made after feedback with feedback.
• combine them back into the master.

This is a natural and efficient workflow.

Answer 4

We used the Gitflow flow model , which is obtained from Vincent Drissen in nvie, as Alexis mentioned.

The idea is that you will have two main branches, "Development and Master." Developers can have their own function branches, which eventually merge back into Develop once the function is ready. When development is completed by any function, you will open a development release branch, which will begin the release cycle. Testing will be carried out in this branch, and if errors are detected, as a result, they will also be fixed in this branch, but new functions will not be added to this branch. When everyone is happy with the release, it merges into Master and is marked with a version number. You will also merge it back into Develop.

If an error is found in the production code, you will open a new master patch branch. Once the fix is ​​complete, you merge Hotfix into a Master. If a patch was created during the release cycle, you must merge it into Release otherwise in Develop.

without correction:

Feature → Develop <=> Release → Master

corrected during the release cycle:

Feature → Develop <=> Release <- Hotfix <=> Master '

corrected after the release cycle:

Feature → Develop <- Hotfix <=> Master '