I would always merge often, usually after every commit. It takes time to resolve the commits. If we pill up commits and wait to merge, there will be a chance that we might forget what we have done in earlier commits, and when we merge it, resolving the issues will take longer time and thus a massive headache.
Another option for really long lived changes that may be finished but not ready for use is to put them behind a feature flag so they can be merged in to master but have no risk of breaking anything. Then when they are ready to be used the feature flag can be removed.
Usually Often is better than a massive one.
Smaller more frequent pull requests are almost always better.
I've started using configuration flags primarily so that I can do early smaller pull requests so that I can, in turn, merge code more easily but leave the feature deactivated. The smaller the pull request, the easier it is to review the code, even if ...
Assuming your intention is to eventually merge A, B back into master and maintain a single code base, it is never a good idea to deviate from master too far. Deviating from master for too long, especially when bug fixes and other development are merging to master as A, B are being developed, will certainly cause conflicts.
I would consider strategies ...
In Refactoring by Martin Fowler, the advice that he gives is never to let a branch be branched off from master for longer than a day. IIRC, you should make a small change, test to make sure that you did not break anything, and then merge it back.
The longer a branch lives, the more it is able to diverge from the main branch and the messier and more complicated the resulting merge will be when it's finally finished. Ten small conflicts are easier to resolve than 1 massive conflict, and may actually prevent developers from duplicating or wasting effort. Given that, you should merge master into A and B ...
To some extent, you can do this as you like. At my place there I ONE iron rule: We release something that is in git ( not on a developers machine) and tag it, so we can get that exact code again in a few years. That is the one rule that must never be broken, everything else is secondary.
Secondary is: At certain points, we merge a release branch to the ...
This sounds like you have been following git-flow, and are looking for something simpler. I think most teams should use something simpler than git-flow. I would agree that you don't need the 'master' branch. You can delete it, and then may want to consider renaming the 'develop' branch to 'master' or 'trunk'.
That gives you something like the the 'Branch ...
What's needed here is clear definitions of the categories. Chore needs some attention.
A Semantic Commit Message looks like this:
feat: add hat wobble
| +-> Summary in present tense.
+-------> Type: chore, docs, feat, fix, refactor, style, or test.
seesparkbox.com - semantic commit ...
The introduction at the top of the criteria for that initiative includes this sentence:
For example, some practices enable multi-person review before release, which can both help find otherwise hard-to-find technical vulnerabilities and help build trust and a desire for repeated interaction among developers from different organizations.
The mention of "...