Why, before merging the f1 branch into the develop branch, do you need to merge the develop branch into the f1 branch?

Question

git

While researching the git branching standards, I come across this recommendation: "Before merging the f1 branch into the develop branch, you need to merge the develop branch into the f1 branch."
This recommendation is justified by the following reasons:

• All conflicts must be resolved on the side of the f1 branch;
  
• Updating the branch f1;
  

But I have a question. If, when resolving conflicts on the side of the f1 branch, we choose implementations from the f1 branch, then will these conflicts not arise again when the f1 branch is merged back into the develop branch? Or I misunderstood something? Is such a recommendation redundant?
An example of such a recommendation is in this document (Supporting Branches -> Feature Branches -> 2nd paragraph -> 2nd suggestion):
https://gist.github.com/digitaljhelms/4287848

Answer 1

Or I misunderstood something?

Yes, you do not understand the essence of merging branches in Git.
Let's start with the fact that when you merge branches, by and large it doesn't really matter which branch you merge into. You are ALWAYS creating a merge commit, and the creation of that merge commit (and therefore the conflict resolution that occurs when you create that commit) implies that you have merged two branches together. This means that starting from the merge commit, all subsequent commits (children to it) will have changes from BOTH branches. There will no longer be a difference between what was done in the first and in the second branch, from now on "they are one" (c).
The other question is which branch to put this merge commit into and the INDEX of which branch to MOVE to the new merge commit. Theoretically, we can move both pointers, but in most cases we only need to shift in one branch (and often only in one of the branches, in your case f1, we have the right to move the pointer).
When you try to "back-merge f1 into develop", if there are no new commits in develop (that are not ancestors of the merge commit you created), then in fact there WILL NOT be any merge. After all, you ALREADY have a commit that takes into account changes in BOTH branches. All you have to do is move the develop branch pointer to this commit. Another thing is that the decision that this can and should be done, thereby accepting the changes in the f1 branch into the develop branch, is made by the maintainer of the develop branch, and this is not necessarily the same person as the one working with the f1 branch.
Why do we shift the branch pointer f1 first? Well, obviously, because this is a branch in which development is being carried out, and it is usually customary to accept already fully prepared edits into the general branch (which apparently you have develop). Ready - including those integrated with the current state of the codebase. Usually it is the task of the person working in the f1 branch to resolve all conflicts and integrate with the fresh state of develop so that the project maintainer can quickly and painlessly merge f1 into develop.

Answer 2

Usually there is a branch into which the developers merge all their changes (we have this develop). By merging develop into f1, the developer can resolve all conflicts and run tests on their own branch. And then send a pull request to develop.