We have are a small team of 6 people working with Scrum and Git.
We are developing a quite complex webapplication with the ZK Framework. It uses Java and a MySQL database.
We have adapted the "Git workflow" by Vincent Driessen from:
https://nvie.com/posts/a-successful-git-branching-model/
This results in the following diagram, showing our model:
When we develop a new feature, we branch off of the "develop"-branch.
After a feature has been completed, we do 2 stages of testing - internally (the developers) and externally (the customers that suggested the feature).
For the customer-test, we have a "sandbox", which is more or less a 1:1 copy of our live-system. It has it's own database and branch.
It has it's own branch "sandbox" and is sort of a "pre-release".
Our problem:
We have 1 person doing the merges from the feature-branch into the sandbox-branch, including solving all merge-conflicts.
(We know this is not scalable and soon every developer might need to merge + conflict-solve their own feature-branches. We are still learning and adapting)
Then the customer goes into the sandbox, tests the feature and says either "fail" or "success".
1) Fail - we fix the feature.
2) Success - we close the feature and merge it into develop.
And this is where we are not sure if this process is optimal - you basically need to merge + conflict-solve at least twice, because while testing on the sandbox, the develop-branch keeps getting new commits, which often can result in the feature-/sandbox-version being different from the develop-verson -> merge-conflicts.
Is there a way to solve this more elegantly?
And / Or is there a way to reduce the merge-conflicts?
No data flows back from sandbox into the feature. The arrows labeled "Test: Fail / Success" are merely used to show that the customer tested it and gave his "okay".
We also do not develop on the sandbox.