From which branch should feature branches be branched for development?

Question

git

Help with the choice. Several developers are working on the project. There are two regular branches. master and develop. From which branch should the branch be branched to develop a feature?
1) from the master, and then pour the finished feature into the development, because each feature must be ready at any time, at the request of the customer, poured into the master and into the release.
2) from the developer and then pour the finished feature into the developer again. And then at the end of the sprint,
pour everything into the master.
What are the pros and cons of each method? Share your experience, what method do you use for your development?

Answer 1

Share your experience, what method do you use for your development?

Personally, we use this method:
1. There is a master branch, only fully tested code gets there (note - not at the end of some sprint; not after the cancer whistles on the mountain; but after passing all the stages of testing)
2. Yes dev-branch, it is managed by a senior developer and, as necessary, "adds" feature-branches there.
3. There are many feature branches in which individual individuals work, and where they will take the code base for improvement is their personal tragedy. If conflicts arise during the merger - there is a senior developer, if something is not clear to him - there are code authors who can be called and asked "what's going on here?".
The best formula for working, from my personal experience, is to "think with your head", and not blindly follow some set of rules.

Answer 2

the second option, the first one works with hotfixes

Answer 3

There are different options even in git-flow. In your case, given that you make features and then choose what goes into release (it's not very clear how you form the sprint in this case), you don't really need the develop branch. The develop branch is for integrating different features and testing how they work together, in your case this is postponed until the final testing of the release. This way gives flexibility, but can increase the time of the final testing, is justified for simple projects and / or projects with really weak engagement, but even in this case, constant supervision by the team leader is required.