Is a feature → develop → main workflow with merge commits expected to produce many merge commits?

Two levels of merges (develop and main) are expected when you require a true merge every time.

This main and develop naming suggests that this is inspired or taken from Git Flow. Git Flow provides very little benefit for all of this merge ceremony. All you get out of it is that you always know where “production” is by looking at main. (But some applications can have deployments to different installations which might be on different tags.) But this benefit could have just as well been provided by using a fast-forward merge from develop into main. Again, with the specific workflow that Git Flow dictates. Granted, a true merge into main also tells you that production moved say five feature branches worth of stuff forward, then eight, and so on. But Git Flow also dictates a tag for each commit to main. So the information is still there without true merges. Just less directly.

One might want an “integration branch” in the specific sense of a branch where things are tested before landing in main. But Git Flow is set up in such a way that everything in develop is destined for main since develop is never rewound. So you don’t get this benefit here. An alternative that does give you this benefit is to not merge develop into main. Instead merge feature branches into develop to test them. Then merge feature branches directly into main when they are ready.

And you can still follow that approach (merge features into main) and treat main as “ready for production”.

There are many nuances and points here and you don’t state what your goal is.

1. This commit history is expected. But I would not typically merge from develop to master after each individual feature branch merge. The point of having a develop branch is that integration of features can be tested without disrupting a release-worthy master. So, you get one merge commit for every feature branch and one merge commit for every merge into master.

2. What is a PR? Pull request? That does not exist in Git. What is a "direct merge"? When is a merge not "direct"? Git only knows about merges. You merge when you want or need a merge. Whether via a pull request or by using other tools is totally irrelevant.

3. It is not the number of contributors that decide whether you need a develop branch, but it is the number of features and whether these features pose a danger of eliciting incompatibilities when merged together. If that is the case, you want to have such problems eliminated in the development phase, that happens on branch develop. Of course, this assumes that master is meant to be the most stable version of your project that cannot afford temporary hickups after a fresh merge of a feature branch.

Note if you go with the alternative:

Instead merge feature branches into develop to test them. Then merge feature branches directly into main when they are ready.

This is an entirely different strategy, which is similar to gitworkflows, and in this case, I would highly recommend renaming develop to next.

I agree with #1 and #3. Regarding #2, I think it can be assumed that PR = Pull Request for a Git question, particularly one tagged pull-request. 😉 I think it's also obvious that by "direct merge", OP means fast-forward merge if possible, without forcing the merge commit. (For some reason I am defending the world from snark today.)

What is the problem exactly, we create branches on out local repository, we push/commit changes to the branch then raise the PR to the official Repo. Maintainer merges it.