-1

I have a class Foo with lots of fields and have two tickets to refactor that class.

  • the first ticket is to rename it to Boo and two move it to another package.
  • the second one is to rename some fields in Foo

I have implemented the first one in a branch. It is not merged yet. Now I'm stuck with a second branch.

One option is to create it from the master, but in this case, after merging the first branch, git will not be able to resolve that movement and renaming of Foo. I'll get merge conflicts and in order to resolve it - I'll have to make all my changes related to the second ticket once again.

Another option is to create a second branch on top of the first one. But in this case - branches become dependable, what is not correct, because according to the definition, these branches should be able to be merged independently.

What is the most effective option in this case?

4

If two tickets would give a lot of merge conflicts when they are being worked on in parallel branches, the very best option is to complete one ticket (and merge it) before starting on the second ticket.

If that is not a viable option, and it is likely that the first ticket will be merged before you are done with the second ticket, then you should create the branch of the second ticket off the branch of the first ticket. Although the branches are not completely independent, that becomes a moot point when the tickets are merged in the expected order.

If it is not likely that the first ticket will be merged before the second ticket, then you will have to either take the hit from the merge conflicts, or you have to accept that the second ticket cannot in effect be merged to master (or develop if you use that) until the first ticket is also merged.

If you decide to take the hit of the merge conflicts, then you should work on ticket 2 as-if ticket 1 doesn't exist (or wasn't started yet). After ticket 2 is merged, the branch of ticket 1 can be updated with the latest changes on master/develop and the merge conflicts can be resolved.

If it is decided to effectively delay the merging of ticket 2, you would branch off from ticket 1's branch and then also merge back to that branch.

0

Unless you have simplified the example for the question, none of the tasks has a business meaning. Developer(s) should be free to arrange them according to the technical merit. So I think it should be ok to make them sequentially.

If they are part of some bigger user visible features, the provided scenario is the reason why it is better to make the refactorings separated branches which are integrated to common codebase as soon as possible.

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.