The development model

null@example.com (De-Backer) — Thu, 09 Jul 2020 19:45:02 +0000

In light of, among others, git, the development of QElectroTech.
We will have to make a choice.

By Vincent Driessen March 5, 2020 wrote:

If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.
If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild,
then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years.

It comes down to this:

git-flow
two main branches, and of course a lot of temporary branches
We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.
benefit:
- a production-ready software
- Hotfix branches:
The essence is that work of team members (on the develop branch) can continue, while another person is preparing a quick production fix.
GitHub flow
one main branche, and of course a lot of temporary branches
We consider origin/master to be the main branch where the source code of HEAD always reflects a state with the latest delivered development.
benefit:
-support only one version, the last one
-simple

I recommend everyone to read the git-flow URL which contains the full text, my post may seem a bit difficult.

Why:
-to make full use of git.
-for the change log
-... and many many more

QElectroTech — The development model

The development model