Our development process is similar to the one described in this question and requires creation of many small features. Usually 4-8 features per day. All features should be deployed to the same test environment, so there should be single test branch.
Which branching strategy should we adopt? Creating separate feature branches seems like a big overhead, at the same time trunk-based development lacks flexibility. Is it OK to mix those approaches (direct commit to test for small features and separate branches for relatively big features).
We are totally new to Git and common branching strategies (like git-flow), and trying to find strategy that fits best for small frequent features.
We will be very grateful for any help or pointing in the right direction, since there are not a lot of articles describing branching for small features. Thanks!
Considering that you have at least two main branches:
production or the master branch, the one to be publishedtest or the working branch, where you test all new featuresConsidering your approach to develop all the new features directly on test and then merge those new features to production (merging test to production). In some point you will have features that you developed that you don’t want to publish to production. Then you will be forced to reset your test branch to keep working on it or you will end with many unwanted features published to production. Or you will need to discard the test branch and branch again from production to have a clean copy to work on. Then if many team members are working on the test branch and all merge their changes to test, it will be hard for each team member to track the features that other team members are working on, so the conflict resolution will become harder to accomplish.
I think the best option will be to treat each feature as a different branch, branched directly from production. So, for example in a day you want 3 new features, you will branch from production and create: features/one, features/two and features/three. When each of those features are ready (at a different time, by different team members) they’re all merged to test (each team member will need to be aware only of the changes he made for conflict resolution because he works on a controlled branch with inly the changes that he made to the project ) and then showcased to a client or the team leader. Maybe all the features are approved, but maybe one of those features gets rejected. With this branching strategy it’s very easy now to discard all unwanted features and publish the approved ones: you just need to merge the approved features and discard the others.
Working on different branches for the different features will give you a more granular control of your project, where you work each feature separated and they don’t ever get mixed.
In your case maybe you do small fixes to the project (maybe the project is a website and you just fix typos), you could then have a hotfix/quick-fixes branch (branched from production) where you work all those small changes (that will be published for surely) and then merge those changes to test to make a quick review of those changes or you merge directly to production for publishing.
Hope this point of view help you solve your branching strategy.