0

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?

Paul Smith
  • 299
  • 2
  • 13
  • 2
    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. 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. – TTT Jul 02 '22 at 03:43
  • 1
    Okay, then merge conflicts will be part of our work in the current setup. That is somewhat acceptable. Unit-tests are not possible right now, but in future we try to create them. So right now, social and procedural changes could probably be worth more than new git setups, right? Also,I think your comment is a valid answer to my question, too. – Paul Smith Jul 02 '22 at 12:06
  • I agree that was nearly an answer. I added one based on my comment. – TTT Jul 04 '22 at 20:59

2 Answers2

3

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.

Shachar297
  • 599
  • 2
  • 7
  • 1
    I totally agree that knowing Git is great and valuable, but what if there is no time to train others at the moment? – Paul Smith Jul 01 '22 at 21:44
  • 1
    I would say consider working with contractor if possible, I have seen it so many times when companies can not afford to lose time, and contractor saved them. Or - Working as organized as possible,. always have backup and the ability to roll out,.git also can rebase to last commits if things go down., Technically I think your idea might work if there will be no garbage in these branches. – Shachar297 Jul 01 '22 at 21:49
  • 1
    Sorry, I did not specify before. We are not a company and do not make profit. My main objective is to find out if there already exists a simple solution to our problem. Or if our idea has a drawback I do not see. – Paul Smith Jul 01 '22 at 21:55
  • 2
    Ok haha, so I that case I think your idea is very much acceptable. – Shachar297 Jul 01 '22 at 21:58
2

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.

TTT
  • 22,611
  • 8
  • 63
  • 69