Issue: We cannot find a way to not have Merge Conflicts when starting a new feature on an app while waiting on another feature's code review/QA.
When a merge conflict occurs the app's JSON must be hand modified to to get the changes in, this is too dangerous and time consuming to be part of our regular process; the issue is compounded as very few changes in an app do not create merge conflicts.
If anyone has a successful workflow that avoids this while allowing developers to continue work on an application please let me know.
What we have tried:
After completing a feature and making a merge request for it, making a new branch off of main
Making a new branch off of the feature that is in Code Review/QA
Avoiding the issue by having each developer bouncing between two projects/apps
Method 1 creates a merge conflict every time.
Basic example:
Create merge request B
There are now three possibilities:
Merge request A passes code review and is merged, merge request B does not have a merge conflict and can be merged in as expected.
Merge request A fails code review, the required changes are implemented, and it is now merged. Now merge request B has a conflict and cannot be cleanly merged.
Merge request A fails code review and is still being worked on. Merge request B is approved, but cannot be merged as bad code from merge request A is present in it.
Generally speaking, the first strategy you've described here is considered the most hygienic, in the sense that it maintains a certain level of granularity and separation. Merge conflicts are, to an extent, the natural byproduct of branch-based development but we do have some recommendations for minimizing them.
I also answered a somewhat similar question over here, which might give you some insight into best practices. The big benefit of this particular pattern is that you shouldn't ever have conflicts after approving a PR, only when rebasing in-progress feature branches.
The method you mentioned is what we have been doing, but adds steps that are not required in full code solutions.
One thing that would help us is further use of modules. We have been staying away from then unless repeatability is needed due to the performance issues they had. I will revisit this as improvements have been made here: Improved performance of apps using modules | Retool Docs
We break tasks into small pieces, so that our branches last less than a day in most cases. This allows us to pivot quicker but adds the overhead of frequent context switching and is still not fool proof.
An example is we had someone working on a new feature for an app for a day when a critical bug was found. We hotfixed the issue but then spent 30 minutes to an hour working on the merge conflict for the feature branch and confirming that everything worked as it should.
Yeah, the realities of software development can interrupt the best laid plans.
We are making consistent improvements to the way app data is serialized, so hopefully this experience will improve over time. And it sounds like there's definitely an opportunity for you to utilize modules more frequently. In addition to the performance improvements that you noted, we are currently in the middle of a fairly significant overhaul of modules, in general.
