- 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
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?
(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)