But you're not integrating other feature branches, that's where most merge conflicts come from.
What a process allows this case? As far as I understand, a feature branch can stall for a while, but, when it is prepared to review/merge, it shall be actualized, and that is responsibility of the branch maintainer, not his colleagues from another branches.
I've seen plenty of that in projects following Gitflow or similar strategies where there are several long-running feature branches.
I guess there is a misnomer between two concepts: feature branch in its typical meaning, and "train" (there could be synonyms). Feature branch is usually a short-term beast; a few commits are made for a task, they are merged, and then, even if development continues under the same branch name, it is principally a new development. But, if trains are used (for example: "stable" train for customers; "testing" for QA games and "devel" as the current developers achievements, and changes are migrating over the way devel -> testing -> stable), yes, there will be lots of conflicts when changes are ported over older codebase. I've seen examples of train-based development, but, in general, it is too specific and hardly used. (Is there statistics?) People prefer release branching to it, because it's just simple.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What a process allows this case? As far as I understand, a feature branch can stall for a while, but, when it is prepared to review/merge, it shall be actualized, and that is responsibility of the branch maintainer, not his colleagues from another branches.
I guess there is a misnomer between two concepts: feature branch in its typical meaning, and "train" (there could be synonyms). Feature branch is usually a short-term beast; a few commits are made for a task, they are merged, and then, even if development continues under the same branch name, it is principally a new development. But, if trains are used (for example: "stable" train for customers; "testing" for QA games and "devel" as the current developers achievements, and changes are migrating over the way devel -> testing -> stable), yes, there will be lots of conflicts when changes are ported over older codebase. I've seen examples of train-based development, but, in general, it is too specific and hardly used. (Is there statistics?) People prefer release branching to it, because it's just simple.