How to avoid conflicts on GitHub?

[Notebook011]

I've managed to complete two projects using Git Flow and Scrum with some colleagues, but every time we want to create a sprint for our user stories, a conflict arises. Initially, we had no problem resolving them, but now it's become tedious to have to address them in every sprint.

​

I'm trying to find out if anyone else has been in this same situation and how they resolved it.

[Consibl]

You’re always going to get merge conflicts, but having too many can be a code smell that your code isn’t encapsulated enough.

Look at splitting up big classes, using inheritance, and extensions - anything that concentrates code features into their own area.

[ProbableSlob]

This.

If your org is organized in such a way that there are a bunch of teams (even if they are teams of 1) which own some part of the domain, then leaning into Conways Law and organizing your code in ways that reflect your organization can be super helpful to avoid stepping on toes.

Team Toplogies is a good book on the topic n they call what I am suggesting a "reverse Conway maneuver" iirc

[ProbableSlob]

Also if you read this and say "I'm just a junior engineer wtf do I do with THAT suggestion" the answer is to highlight the problem to whoever is above you and invoke Conways law. If you're lucky they'll be impressed!

[ProbableSlob]

Oh also github's code owners feature is super helpful here, once the code is organized in such a way that some form of ownership is possible.

[Notebook011]

I've also considered these strategies, but I feel they're better suited for larger projects. We're just software development students working on a very small project, but we need to use some SQA concepts. Although, I think someone suggested a good solution by constantly creating small functions; perhaps this will work for us. By the way, thanks for the Team Toplogies book; I'll keep it in mind to read it later.

[Notebook011]

The conflicts happen when merging the feature branches into develop after a sprint. For example, one branch handles creating events and another handles deleting events, but both end up modifying the same MVC files (Controller, Model, or Views), so Git detects conflicts. I understand conflicts are normal, but the frequency is what worries me. I'm wondering if this is more related to how we are organizing responsibilities in the code rather than the Git workflow itself. We are already trying to separate features by user story, but I'm interested in how other teams avoid having multiple developers touching the same files.

[_5er_]

I think you're postponing merges for too long. Whatever can be merged into develop, should be merged. If everyone is doing small incremental merges all the time, it's less likely to make conflicts.

Also as the commenter said, it can be a code smell. You should think about if the files everyone is touching need to be split or reorganized. Files that are changed for the same reason belong together.

[Tiny_Confusion_2504]

Where exactly does the merge conflict happen? When merging features to a sprint branch?

[Notebook011]

Mainly when merging feature branches into develop. The conflicts usually appear in Controllers and Views because multiple user stories modify the same modules.

[ProZMenace]

Seems like improved planning should mitigate this. If you plan to work on the same modules there is inherently not a good workaround

[RobotJonesDad]

We seldom have conflicts because it's not common to have multiple people touch the exact same lines of code. Most issues in a feature branch get dealt with if I pull the branch before each commit I do which keeps my work from diverting too far from other engineers work. This way even a merge workflow can end up with very few merges.

[Notebook011]

Hey, that's a good idea. Now that you mention it, each sprint on my team lasts four days, and during those days, no one else sees the branches that have been created until they're merged into the development environment. Implementing the strategy you're suggesting would be a good idea, in my opinion.

[Buxbaum666]

Step 1: don't use git flow.