Irecently worked on a 1-week quick prototype project with a few junior developers. Most of the developers on the team preferred that we use storyboards because it’s what they’re most familiar with.
Though I’m one that prefers working in storyboards, I was not looking forward to the incessant merge conflicts. Meeting after meeting of “which side do I pick?” — storyboards are written in XML if you didn’t know (right-click a storyboard file -> **Open As -> Source Code **if you want to see for yourself). This makes it difficult for some developers who aren’t familiar with XML to decipher what’s what.
The Good News Is… At The End Of The Week, We Had… One Merge Conflict. Just one. Here’s how we did it…
One thing you’ll notice throughout this story is you’re going to hear a lot of “we” as opposed to “I”. That’s because teamwork is paramount to avoiding merge conflicts, and we truly worked as a unit. That’s not to say someone wasn’t the lead — a team needs a leader, after all, someone to provide direction.
When I say we had one merge conflict related to storyboards, I don’t mean one merge conflict that we couldn’t figure out. I mean one merge conflict. Period. We had more merge conflicts related to what I refer to as “greedy” lines of code. That is to say lines of code we don’t agree with others on, and change or lines we change to shortcut something for our own development experience and forget to change back before merging into a common branch.
Each Developer Gets Their Own Storyboard, Each Developer Gets Their Own Branch
The size of the storyboards is up to you and your team, but the less that’s going on in each storyboard, the less of a chance there is for a merge conflict. Two of our storyboards only had one View Controller each!
We may have gone a little overboard with branches, but the strategy worked. We had a master branch, a common develop branch, and each of us had personal branches. I organized my personal branches by feature, some went by day, some seemed to have no coherent strategy for their personal branch strategy. One thing we all agreed on was that the common branches needed to remain as clean and up to date as possible.
We each picked an MVP feature to own. None of the MVP features resided in just one storyboard, so occasionally, it was necessary to delve into someone else’s storyboard file. That said, each file had an “owner”. This person was responsible for knowing what should be going on with that storyboard. That doesn’t mean whatever they said was what happened, it just means that was the point of contact for working in that file.
So
if Developer A wanted to work in Developer B’s storyboard file, Developer A would shoot them a message on Slack, and say “Hey, I’m working on feature X, and I need to work in your storyboard file. Is that ok?” Then they would wait for Developer B to respond before even starting to work in the storyboard file in their own branch.
This is key takeaway number 1. Developer B owns the file and should know if Developer C is working on it (or obviously if they’re working on it). They can then let Developer A know to hold off because someone else is making changes to that file.
Let’s say Developer C was working on this particular storyboard file at the time. When they’re done, what they’re going to do is commit their work, pull down from the main develop branch, handle any conflicts (if there were any) in their own branch, then push up to the common develop branch. If there were any question whatsoever about what line of code to pick in a conflict, a meeting would be held between any involved parties, but normally we’d already have it figured out beforehand because we talked about it.
Before they push up though, they’d let everyone know that their changes were being pushed up to the common develop branch so everyone had an opportunity to review their changes if they wanted to — though we rarely needed to.
At the end of the day, we’d review the common develop branch together and decide if it was clean enough to push up to Master.
#programming #git #ios-development #xcode #github
