We’ve come to the midway point in our capstone class and, while it feels like we’ve accomplished so much, there is still so much to get done! And the newest challenge, as we start integrating small bits of code with each other, is the dreaded merge conflict.

I’ve heard tell of this beast or pest (have your pick), but, because most of my work so far has been as a team of 1, have never come face-to-face with it. Until now.

The beauty of our buy, sell, trade website is the buying and selling and trading. And for these flows to work, entities and different services need to integrate with each other. Resources are shared, there are multiple touch points in the UI, for many entities. There are clicks and loads and writes and (sometimes) errors. A merge conflict appears when the space that our code occupies overlaps with another’s code space. And the version control system cannot have two different pieces of code in one space. The first time I ran into a merge conflict, it was novel. The second time and every other time thereafter, it was undesirable.

So I talked to some folks, at home, at work, about my newbie merge conflict experiences. Mostly, I questioned them about how teams working on more complex projects deal with merge conflicts. The answers all aligned with a common theme: unavoidable, but do your best to avoid them. I… was a bit confused.

So when I asked for elaboration, these seasoned devs helped me re-orient my thinking around best practices that lessen the chance of merge conflicts:

• Pull down changes often. The general recommendation is at least once a day. This is new for me, as I’m not used to thinking about the work others are doing. Out of sight, out of mind, is the opposite of what I should be thinking. After fetching, merge or rebase (the differences are discussed here).
  
• Commit often, push up changes often, and make pull requests as often as possible. Incremental changes seem to be key. And this makes a lot of sense because the quicker small changes are added in, the less likely for a merge conflict. Of course, the previous rule still applies, that the incremental changes are also being pulled down often.
  
• Review and approve PR’s often. This step is important to allow the previous bullet to succeed. We facilitate each other’s merges to keep things moving. This really is the opposite of out of sight, out of mind. Instead, this methodology is keeping everything in sight and in mind.

I really hope these tips will help lessen the number of merge conflicts during the latter half of this course, as we really get into the work of integrating disparate pieces. Having just started with integrations, it seems like the logic is much more complicated, and it is challenging to get the flows working as they should. It’s my goal to minimize the chance for merge conflicts so that I can devote as much of my focus as possible to these complicated flows!