First - a philosophical question. You started developing on the
feature/users-endpoint branch. However, when doing so, you introduced highly modular code. Maybe in your head you realized that this would be necessary, but it may have taken you longer to develop. Would a better option have been to not DRY up the code before it was repeated to begin with? Would you have been able to get
feature/users-endpoint progressed through the workflow sooner - a pull request open for review, merged into a
develop branch for other developers to use, or even deployed to a test or production environment for users or user proxies to interact with and get faster feedback?
Second - another philosophical question. What does it mean to be "done" and to "limit work in progress"? We know that limiting work in progress improves quality - it improves focus on one particular thing with less context switching which improves quality and it tends to get work through the workflow and to the next workflow faster. Should a single person have two feature branches open? What does that imply about their focus and attention?
I think that's enough of the philosophical discussion. Let's say that you're in this situation. What do you do?
Looking at the pros/cons, I believe you would almost need to branch from the
feature/users-endpoint branch, but ensure that the
features/users-endpoint branch is merged into the
develop branch first. This reduces merge conflicts (reducing your workload), reduces the bulk of the pull request (reducing the mental load on code reviewers, making them more effective), and even lets you get some feedback on your
feature/users-endpoint design, putting you in a position to find defects or perform refactoring (perhaps even before the
feature/users-endpoint branch is merged).
Although, I do think the best thing is to not have two open feature branches. And if you must, try to make them not dependent on each other at all and have both branched from