Topic: The development model
In light of, among others, git, the development of QElectroTech.
We will have to make a choice.
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