This is definitely my biggest worry, too, especially since we rarely have merge conflicts on our 6 person team.
Merge conflicts are rare for two major reasons:
1. We plan our changes to avoid the likelihood of merge conflicts. Specifically, we try to avoid two people working on similar areas of code at the same time.
2. We have functionality split into a fair number of different repos (though I probably wouldn’t call them microservices), which not only makes 1. easier, but simply reduces the chance of two people pushing commits to the same repo.
Part of 1. also involves giving slightly bigger pieces of work to a single developer, so that person can see it all the way through from the start. That way, there may not be as many short PRs that are quickly merged, but that developer can really wrap their mind around the complexity of the problem and hopefully have a higher quality functioning product at the end.
Of course, we also have our use cases reasonably solidified when we start building, since our company is over 8 years old and we take the time to know our customers’ desires fairly well (and are always learning more, or course!).
Merge conflicts are rare for two major reasons:
1. We plan our changes to avoid the likelihood of merge conflicts. Specifically, we try to avoid two people working on similar areas of code at the same time. 2. We have functionality split into a fair number of different repos (though I probably wouldn’t call them microservices), which not only makes 1. easier, but simply reduces the chance of two people pushing commits to the same repo.
Part of 1. also involves giving slightly bigger pieces of work to a single developer, so that person can see it all the way through from the start. That way, there may not be as many short PRs that are quickly merged, but that developer can really wrap their mind around the complexity of the problem and hopefully have a higher quality functioning product at the end.
Of course, we also have our use cases reasonably solidified when we start building, since our company is over 8 years old and we take the time to know our customers’ desires fairly well (and are always learning more, or course!).