0

I'm a Rails developer and I've always had this doubt, let's say I have to develop things for the user's controller and views (branch feature/users-endpoint) and imagine I end up developing several helpers (sorters, paginators, etc.) and concerns to modulate the code a bit. Then let's say I have to do the admin's controller and views (branch feature/admins-endpoint) and I want to use the helpers and concerns I developed in feature/users-endpoint, should I branch from feature/users-endpoint or develop?

If I branch from develop:

  1. Could get more merge conflicts when merging to develop (not in the exposed example, but in other cases in were I edit the same files it could).
  2. Would produce a smaller Pull Request in the case of feature/users-endpoint.

If I branch from feature/users-endpoint:

  1. Less or zero merge conflicts.
  2. Would produce a much larger Pull Request in the case of feature/users-endpoint.
  • The will depend on how you deliver, and how large and slow your team is. If its just you, do what works - just be mindful of what you must deliver in order for dependent features to work. Perhaps consider Feature Toggles? If you are in a larger/slower team you will need some standards. Either try and get reviews working faster (so the feature is in develop before you start your next) or if that won't work you may need to pull out that functional subset into a common branch to share with the next feature. – Kain0_0 Aug 21 at 3:11
0

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 develop.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.