We're using a tool (STM32CubeMx) which provides a GUI to configure embedded microcontrollers, and generates a full C project based on that configuration. This includes C files, Header files, and other things. These files are complicated enough that most developers use the GUI tool to generate.

After these files are generated, you sometimes need to edit certain parts by hand. This, however, is the exception: most of the time, you either use the GUI, or put code in new files that are not generated.

Our workflow is:

1. Create a project by hand project
2. In a separate folder, called mx, use the GUI to generate code (a new project, which we never build)
3. Selectively copy in needed files from mx to project (we only copy in the files we actually need)
4. Edit those files as needed (under project)
5. If need be, use the GUI to update mx, and [*] merge in the newly generated files into project.

It's step #5 that's tricky, because we want to bring in any changes to those files, but not throw out our changes done in #4. We also don't want to copy files in that we chose not.

I believe git could be used to do this, because this is essentially a git merge. However, git merge is designed to work with files in the same tree, not subdirectories with commonality.

How can we use git to support this process? What should be the best way to manage the autogeneration, select, edit, and merge cycle? I'm open to any recommended workflow.

Update

This question is definitely not opinion based. No one has suggested it is. It was closed because someone first commented that "There is no correct answer, or even a good answer" - then, that very same person commented "You could [solve it this way]... [or] There are probably dozens of other ways." Is there no solution or dozens of solutions?

It's true this question isn't a simple "here's the API you use" type of question which is very popular. But it's a well defined, on topic question which admits factual answers (even if they're not obvious). It meets SO requirements and should be reopened.

While this is not what you're trying to do, I still want to tell you how we ended up doing it after years of trial and error:

1. Use CubeMX when bringing up projects. Generate the required drivers & HAL files that you require (for now). You can version the resulting project in a CubeMX folder for example. This will act as reference. This step is useful to accelerate board bring up. However, CubeMX ties you with the structure of their pre-made projects and this might get in the way in the long run. So...

2. Make a copy of anything you'd rather do your way, for example, write your own SPI driver instead of using the ones provided in the CubeMX project. You can still use the ST HAL under the hood and base your work on what CubeMX gives you. Keep that in a dedicated folder, you could call it bsp for example. This is your own drivers that you fully control. You dissociate from CubeMX so that you can have full control over your code & improve your ability to maintain it.

3. If you need to regenerate (reason might be to get an example driver for another peripheral, or update the HAL version for your MCU), use CubeMX to recreate a project and bring back the resulting modifications to your project. If you kept the original from step#1, it will be easier to find what was changed: you can use a diff tool like Meld to compare your current "cubemx" folder with the newly generated project.

You would end up with a file structure like so assuming that you wrote your own drivers (example for a STM32G4 MCU):

.
├── app
│   └ your application code
├── bsp
│   ├── board_name.c
│   ├── board_name.h
│   ├── board_name_def.h
│   ├── board_name_spi.c
│   ├── board_name_spi.h
│   └── GCC
│       ├── startup_stm32g473retx.s
│       └── STM32G473RETX_FLASH.ld
├── lib/third-party/
|   │── arm-software
│   │   └── cmsis_5
│   └── stmicroelectronics
│       ├── cmsis_device_g4
│       └── stm32g4xx_hal_driver
├── cubemx
|   └── This contains the auto-generated CubeMX project
└── toolchain

In the end, it'll pay off. The drivers provided by ST are generally bloated and sometimes contain errors. Same goes for NXP. You also rarely modify the hardware functions once it's designed, unless you're working with dev kits and doing different projects with the same hardware. You might entirely drop the CubeMX project in the end, like we did.

We tried it your way, but the maintenance cost is not worth it. Trying to modify auto-generated code and still keep the ability to regenerate that code simply doesn't work. Taking full ownership of your driver's is also beneficial in the sense that you'll get to know your hardware much better.

What I'm trying to say is that you shouldn't try to do 3-way merges of CubeMX generated files (your version -> old cubemx <- new cubemx), but rather maintain your own code, and only compare changes in the vanilla CubeMX projects. You'll need to understand the code differences, but that is an investment that will benefit you in the long run.