Our team has a project with three applications for the same micro-controller. Those work together in a greater setup and use some shared libraries. In order to keep things simple, we put everything in one repository at the start.

By now, the project has grown bigger and we frequently run into

• merge conflicts - fixable
• auto-merges which accidentally introduce run time errors - only discovered at live testing.

There seem to be a few solutions around. E.g. submodules or this article, which describes a many branch approach. Unfortunately, most developers on the team are not experienced with git and right no it is not practical to teach them. I.e. simple actions is the maximum to expect (push, commit, maybe checkout). But not feature branches etc.

Is there fast (dirty if it has to) way to prevent destructive run time errors, e.g. from already fixed bugs which are reintroduced due to merging?

Our idea is to create a separate stable branch, maybe even one for each project. Then, the majority of the team will use main as a kind of development branch and see no difference. Features which are ready can then be merged into the stable branch(es) by a person who knows what they are doing.

Does this sound like a sensible approach?
If so, are there (known) significant drawbacks to it?

CodePudding user response：

So I think this is when a good architecture and design come with agility working,

What I think is that teams should be able to try some methods and methodologies and at last find their right working process, there isn't one.

And technical speaking - working with submodules can be a huge help if developers know what they are doing and always update and pull updates, from main repo, and the submodule, On the other hand, it can also be a headache to maintain three repositories.

Working with multiple branches I think is the same idea, if people are trained, it should be fine, if not, could be a major headache, You could have 3 projects, and 3 staging areas (dev, tests, prod)... Sometimes even more.

Train dev teams to work with git, for what I think, is a bonus for the developer, and the organization as well.

I hope my answer doesn't confusing.

CodePudding user response：

I don't think either of the problems you mentioned (merge conflicts and run-time errors) will be fixed by either submodules or a different branching strategy. Merge conflicts are caused by multiple people working on the same files independently before either is merged. The solution to that is better coordination, or just accept that conflicts will happen and this is normal. That being said, you did mention that certain people are more likely to resolve conflicts correctly, so in that case it might worthwhile to have the developers schedule mini review meetings (or "conflict resolution meetings") to ensure they are resolving the conflicts properly when they aren't obvious. Ultimately though, the final code review before merging will show all the of changes being made, and if conflict resolution was done incorrectly you should see in that final review, for example, some useful lines getting deleted and you could ask why. Some code review tools allow you to see different iterations of every push to a branch with an active Pull Request. If you have such a tool you could request that when conflicts exist on a PR, after resolving them they push again before fixing others parts of the PR, and this way you can see exactly what changed at the conflict resolution portion. (Perhaps this would make it easier to determine if a mistake was made.)

As for runtime errors, this implies a lack of code coverage, so the solution for this would be more unit tests, or automated system tests, and consider running them against a temporary merge commit as a gated check-in. Even if you don't have any tests yet, you could still manually test a temporary merge commit to make sure nothing weird happened during an automatic merge without conflicts.