It’s almost October, which for most people means apple cider and crisp autumn air. But here in Arizona, the only indication of fall is a higher-than-normal level of smack talk in the office due to our intense fantasy footballing.
We have a 16-team league here at the office, and we use GitKraken to manage our fantasy football teams. So when a player gets injured, all of us sneakily scramble to grab their backup. This is a great way to get an edge on the competition, but not exactly great if you’re making sneaky changes in your repo that could have unintended consequences.
For example, we have two fantasy football teams named Kief Away From the Donkey and GitKraken Skulls (don’t ask). Last week the Vikings All-Pro running back, Adrian Peterson, had surgery on a torn meniscus, and will now be out for most of the season. His backup, Matt Asiata, shot up in value because he’ll get significantly more playing time while Peterson recovers from the injury.
If Matt Asiata was a free agent in the league, then the first one to add him to their roster would get him on their team.
Fighting Over the Waiver Wire and Merge Conflicts
In order to introduce a little bit of fairness in fantasy football, most leagues have waiver systems, which give all teams an opportunity to pick up a player, based on that team’s priority.
Most of the time, waiver priority is the opposite of the current leaderboard, meaning that the team in last place would have the highest priority, to give them an advantage; the second-to-last team would have the second priority, and so on.
Asiata is on waivers until Wednesday, so whoever wants to, can add him to their roster. On Wednesday, the team with the highest waiver priority gets him.
Let’s see how this would look in our repo. Both teams pull down the repo when Adrian Peterson gets hurt, my team, Kief Away from the Donkey, pushes the change first to pick up Asiata, followed quickly by GitKraken Skulls.
If everyone is just pushing changes to the same branch, and two different teams (GitKraken Skulls and Kief Away from the Donkey) try to pick up Matt Asiata, there would be a merge conflict, as both teams are trying to pick up the same player.
GitKraken Pro has an interactive merge tool that allows you to select which of the changes in the conflict should be made.
In this case, GitKraken Skulls has the highest priority, so when resolving the merge conflict, we would select the version where Asiata is added to the GitKraken Skulls team, and then push.
The problem with this is that it’s only addressing the conflicting lines, and not addressing the other portions of the code that may be relying on the changes that caused the conflict.
My team, Kief Away from the Donkey, dropped Adrian Peterson, expecting I’d be able to pick up Asiata, but since the merge conflict only looks at changes to the same line (changes made to different lines of code don’t conflict), I still dropped Peterson!
If I would’ve known the player I wanted was already taken, I may have tried adding someone else.
Enter the Commissioner with Pull Requests
I’m the commissioner for the fantasy league here at the office, which means I sometimes have to push through roster changes and make sure everything goes smoothly with trades and adds/drops. Overall, I make sure everything is fair.
It also helps to have someone on our dev team, like the Product Owner, review changes that our team is making, and to see how our updates might affect other parts of the code.
Instead of us pushing to the same branch like in the previous example, if all roster changes are made on separate branches, then the commissioner can review and pull in changes on each branch, one at a time.
If there are any conflicts, the commish can facilitate those changes to get the best result for all of the teams.
Each team member creates a branch (using their team name), makes the same commits to pick up Asiata, and pushes up to GitHub.
Then each team creates a pull request that is reviewed by the commissioner and their changes are merged in if everything looks good.
Any branches with active pull requests will show an icon like this:
You can also view pull requests in the left panel.
GitKraken Skulls is in last place. This team now has the highest priority, and their pull request will be merged in first. Therefore, if the commissioner tries to merge in Kief Away from the Donkey’s pull request, there will be a merge conflict because Asiata has already been picked up.
I can rebase the Kief Away From The Donkey branch on master. More specifically, this means I take all the new changes made to master (for example, Asiata getting picked up) and then place any of my changes on top, add another player like Terrelle Pryor, who is available, and then simply commit and push.
This new commit will be automatically added to the pull request, and GitHub will notify the commissioner that I can successfully merge the updated pull request.
When other team members are making changes to a shared piece of code, it’s important to examine all other changes they’re making on that branch. You need to see why that change was needed to resolve the merge conflict so you can make sure that you can account for more necessary changes.
A good way to do this is by using pull requests, so all changes are reviewed by another team member. This person can find a solution that works the best for all the different goals your team is trying to achieve.
Fantasy football: it really is a lot like your daily life in the dev room. Who knew?!
Stay on the cutting edge of software development by getting innovative tips, trends and stories delivered to your inbox every month!