The problem goes deeper than simply merging large text files.
The .touchgfx project file is a JSON file, and the usual source control merge strategies are geared toward code. There seem to be solutions for merging JSON out there, so that would be one part of the solution.
The bigger issue has to do with how Designer allocates text identifiers. When you add non-resource text, Designer creates a TextId such as "SingleUseId106". If multiple people are adding any sort of new text (e.g. for widgets), their local copy of the project file will allocate SingleUseId106, SingleUseId107, etc. along with the references to such IDs in the code and text xlxs spreadsheet.
When you attempt to merge Alice's work with Bob's work, you will have conflicts with SingleUseId106, etc. within the JSON project file. The sensible thing to do is to keep Alice's IDs (106-109 for example) and add N new IDs for Bob's, renumbering his (e.g. 106-108 to 110-112). But then you have to change all uses of Bob's IDs in the project file to match the number numbering, which frankly beyond your typical merge tool. You'd also have to change the references to Bob's IDs in the generated code, but it might be more sensible to regenerate the generated code at this point.
Merging the text xlxs spreadsheet is a different sort of problem, since it is not a text file and would probably need to be merged manually with a spreadsheet app. TBH I don't know if there are any important relationships between the spreadsheet entries and the project json file (order of elements?), but that could probably be figured out. One approach to consider is a merge rule to convert it into a text-friendly format (such as CSV), merge tool it, and then convert back to xlxs.
Image IDs at least are based on the file name, so other than merging JSON elements this isn't the same kind of problem as text IDs.
My suggestion to the Designer developers would be to adopt a different naming scheme for SingleUseId. It would be 10x better if the generated ID was based on the screen name. For one, it is easier to manage localization with IDs such as SettingsScreenTextID001, since the prefix points to where it is used. I would further suggest that rather than sequential numbers that the postfix be based on the default text or on the widget using it: SettingsScreen_TextID_Factory_Reset. Again, better for translators and avoids name/ID conflicts except when Alice and Bob add widgets with the same name etc., which is more of a development process problem than a source control problem.
There may be other merge related issues lurking in the system I'm not aware of. We are no longer using the tool-chain project files (gcc, EWARM, etc.), so beware.
We have had to institute processes to avoid touchgfx project file merges altogether. Specifically we have a master-touchgfx branch which is the one and only branch where the touchgfx project can be edited via Designer. Only one developer can work on this branch at a time, and must pull-edit-add-push the branch while they hold the virtual mutex. This is OK but not great when, for example, resources are deleted or renamed, since the corresponding non-touchgfx-project work is to be done on another branch and merging from master-touchgfx to a different branch will break the code that depends on those resources until the corresponding work is also merged from the corresponding working branch. The general rule of thumb is no avoid removing or renaming resources except for maintenance periods.
Sadly this is the best I can recommend. In its current form, Designer projects cannot be branched and merged in practice, and developers will need processes such as described above to avoid the inherent pitfalls.
