Merge Conflicts :(

While working in a team should *theoretically* speed up the process of application development, for a team new to the git-flow process, the task of mastering the “pull request” can prove a more daunting task than the project itself.

As the most experienced coder on this project, I was designated the “scrub master” — I created the original Github repository from which team members forked, and I was the node through which team members were updated with one another’s code. In retrospect, the choice for us all to work on the same HTML and script files was a mistake, but we didn’t know that when we began. Even so, the git flow could have worked IF carried out properly as follows. ALL work needed to be done on a separate branch from the master in each member’s fork. For each fork from the scrub master’s repository, the coder needed to submit a pull request to update their fork from the scrub master BEFORE merging his/her own development branch with the master. Then, and ONLY THEN, should each member submit a pull request to merge work with the master.

Why all the capitalization? Because we did not follow these protocols. Often, I would make a series of changes to my own master, and a team member would do the same. Then, that team member would merge his/her branch into the respective master without pulling from my main master first. I would also merge my branch with my own master. If they submitted a pull request to merge with me, my new changes would be lost, as the incoming master would have an old version of my code.

The mechanics described above only became clear to me toward the end of the project. While the lesson was valuable, it also cost me much time rewriting code that was lost.

The result? 201 commits. By my count, that’s the high-score in the class.