2

Background

  • Support and Sprint are the test branches for bugs and tasks
  • Each bug gets a new branch from master, which is merged into Support, when tested good, a pull request is made between the Support branch and master.
  • Each task gets a new branch from master, which is merged into Sprint, when tested good, a pull request is made between the Sprint branch and master
  • Allows for any given bug fix to go live at a moments notice when tested good, and allows for any given task to go live as and when its ready.
  • Allows for any part of a task to be tested in isolation
  • Allows for any bug to be tested in isolation

Problem

If Task 123 and Task 234 both change method DoSomethingToX, this creates a conflict in Sprint which must be resolved. This will break one or both, or neither of the tasks. The fix will be made as part of the merge (because its resolving a conflict), so will be committed to Sprint, not Task 123/234.

I do not want to merge Sprint back into a task, because that will then merge all other In Progress tasks into that task, and could potentially put those task-parts live

How would i better manage these conflicts?

Is this what cherry-pick is for?

Is there a way to go with this type of architecture and avoid these conflicts?

Are there a set of coding standards that would help avoid these conflicts?

Branch flow

(Support and Sprint are only there to give a branch to create deployment builds from for testing, this is already pretty finely ingrained into the entire process and is unlikely to be changed)

1 Answer 1

Reset to default
2

I don't see any process to merge the RC or Master branches back into the working branches (Bug###, Task###, etc).

This is fine, as long as each Bug/Task make minor changes to Support/Sprint branches and are not affected by the other ones.

You want branch drift to be low. You don't want to merge other changes into the task/bug branches, which means these branches are going to by definition drift from their targets.

If multiple features that are being worked on simultaneously are changing the same method so meaningfully you have problems that also suggests either:

  1. The method is too complicated/large
  2. Your features should be developed in sequence

You can also work to make your tasks smaller so they are easier to finish quickly. This is more important if you are unable to merge upstream changes. Or have some sort of communication between your teams to know when they should pull these changes (standups? or something?).

I do not want to merge Sprint back into a task, because that will then merge all other In Progress tasks into that task, and could potentially put those task-parts live

This will also mean you are delaying any problems resulting from other tasks. For example, consider Task1 and Task2 both modify similar code. Task1 is committed/tested/pushed to the Sprint branch but Task2 takes another five days. Because you are never pulling the updated Task2 code and rebasing to it, when you push Task1 you are now running the risk of breaking your Sprint.

How would i better manage these conflicts?

Rebase your commit from Task2 onto the current Sprint branch, before pushing to Sprint.

4
  • i chose "method" because i could have GetEntityByCategory(long categoryId), which could be changed to GetEntityByCategory(long categoryId, bool excludeArchived) in one branch, and GetEntityByCategory(long categoryId, long subCategoryId) in another. With the (terrible) specifications we get for new features, it is not always possible to know that two specifications collide (this is a business issue, but not one that is easily resolved)... (more to follow)
    – bizzehdee
    Commented Jul 21, 2015 at 21:02
  • If i merge Task 1 and 2 into Sprint, and task 2 conflicts, if i then rebase task 2, wouldnt i then end up consuming task 1 or at least part of task 1, and if task 2 ends up going into master first, features from task 1 will leak live before it is ready. how is this avoidable?
    – bizzehdee
    Commented Jul 21, 2015 at 21:03
  • If task 2 is the one getting rebased, doesn't that mean task 1 has been merged "cleanly" without issue? The rebased task may need some rework but the merged task should be a perfectly releasable commit.
    – Ixrec
    Commented Jul 21, 2015 at 21:06
  • If task 1 is merged into sprint, that doesnt mean its live, it just means it is in the "beta" environment, it is only after task 1 has been tested good that a pull request is made from task 1 to master. but, if in the meantime, task 2 is merged into Sprint, and a conflict arises in that merge, a fix will be committed to Sprint rather than either of the task branches. Task branches will always be kept up to date with master, but never merged back from Sprint to avoid features from each task leaking. Sprint is where tasks go to get tested together. master is where they go to meet the public
    – bizzehdee
    Commented Jul 21, 2015 at 21:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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