remy porter remy escaped the enterprise world and now works as a consultant. editor-in-chief for tdwtf. 




when nate was wrapping up his senior year of college, he hunted around for a job that would hire an undergrad on flexible hours. he knew that the kinds of companies that tended to hire on those terms could often have<u+2026> creative practices, but college wasn<u+2019>t about to pay for itself. 




he found a small shop that needed an extra hand. extremely small- there was only one other developer, gordon. nate was prepared to enter a tiny shop with no real practices or procedures, because with only one developer, you don<u+2019>t expect a lot of rules and bureaucracy. 




gordon was only one person, but he was able to create enough contrived, arcane, and downright mysterious bureaucratic policies and procedures for fifty developers. reading the style-guide was closer to reading a novel, but not a good novel where there was a clear point and narrative thread, but something meandering and pointless, like a douglas adams book. 




gordon wasn<u+2019>t just opinionated about style . he also had opinions<u+2122> on the proper use of source control. <u+201c>branches,<u+201d> gordon explained, <u+201c>are absolutely vital for separating units of work.<u+201d> 




gordon<u+2019>s explanation came after nate was stunned by the sheer number of branches- there were hundreds of branches in the repository. <u+201c>look,<u+201d> gordon said, <u+201c>you don<u+2019>t have to be intimidated by this. we can start you out, just do this small change in the main branch, then i<u+2019>ll show you how to release it.<u+201d> 




nate dutifully checked out master , made the change, and committed it. he sent gordon a pull request. 




<u+201c>you used the wrong branch. back out your change, and put it in the main one.<u+201d> 




<u+201c>which branch is the main one? it<u+2019>s not master ?<u+201d> 




<u+201c>it used to be, but we don<u+2019>t really use master anymore. use master_4513 .<u+201d> 




as it turned out, the <u+201c>main branch<u+201d> was usually whichever branch gordon touched last. there were five or six different branches that could be the <u+201c>main<u+201d> branch at any given time. maybe seven- it was very hard for nate to be certain. 




nate made the changes in master_4513 , but that was only the start of the nightmare. now, those changes had to be merged into the correct branch for deployment. <u+201c>this is pretty complex, do you want me to walk you through it?<u+201d> gordon asked. 




nate said yes, and so gordon sat down next to him, and started explaining each step that nate needed to perform. these <u+201c>explanations<u+201d> started with gordon pressing his fingers against nate<u+2019>s monitor and saying, <u+201c>click here.<u+201d><u+201c>no, fire up the gui, not the cli.<u+201d><u+201c>select this branch.<u+201d> the instructional process was recorded as a smear of fingerprints on nate<u+2019>s screen. 




changes merged outward from the main branch (whatever <u+201c>main<u+201d> happened to be that day). instead of merging back towards a known-good trunk of code, changes were made to the trunk, and then percolated outward, according to gordon<u+2019>s own twisted logic. <u+201c>you see,<u+201d> he explained, <u+201c>we<u+2019>ve gotta maintain, like, 15 different versions, and some of them depend on a different version of our framework lib. this main version builds against version 1.2 of the framework.<u+201d> 




<u+201c>but<u+2026> isn<u+2019>t your framework up to version 4.5? like<u+2026> for years now?<u+201d> 




<u+201c>yeah, but this change only goes out to the 2.0 users, so you need to merge from main to master_51 , then to frameworkupgradea1 , then to perky_peregrine . you<u+2019>ll need to resolve conflicts.<u+201d> 




nate ground his teeth hard enough to make diamonds between them, and fought his way through the merge conflicts. a few hours later, nate<u+2019>s one line change was merged into a releasable version, but nate had no idea how that change would migrate to any other version, if it ever did. 




nate<u+2019>s next assignment was to make a change to the same version, and since it was a larger change, he made a feature branch off of perky_peregrine , do the changes there, then merge right back into perky_peregrine after the work was done. then he could propagate the changes back to the current <u+201c>main<u+201d> branch, asdfg . this resulted in an angry visit from gordon. 




<u+201c>are you trying to mess this up?<u+201d> gordon demanded. <u+201c>there is a system . there are policies ! did you even read the development guide i gave you? feature branches are fine, but they have to come off the main branch, not one of the dependent branches!<u+201d> 




nate had tried valiantly to read it, but failed. <u+201c>i was just going to do the work, merge into perky_peregrine , and then delete the branch, why does it matter?<u+201d> 




<u+201c>merge back ?<u+201d> gordon shrieked. <u+201c>delete the branch? branches don<u+2019>t merge backwards , only outwards. like a tree. each feature branch is supposed to be an entirely new line of development. have you even used source control?<u+201d> 




something snapped in the back of nate<u+2019>s brain, because for a brief, terrifying moment, that almost made sense. nate had been puzzling over the bizarre state of their source control repository, and those words from gordon put understanding it within tantalizing reach. if he asked a few more questions, he might just see the method to this madness<u+2026> 




nate chose the wiser path. he smiled, he nodded, he complied with gordon<u+2019>s policies, and moved on to the next feature, weeks after cutting through the shrubbery that was gordon<u+2019>s branching system. 




the next feature was to make a change that only impacted users of the latest version of the base framework. the current <u+201c>main<u+201d> branch was back on version 2.3, so nate needed to start by making a branch from there. then he had to bring it up to version 4.0, then convert a few of the datafiles into a new format, then finish the upgrade to 4.5. this was about two weeks of hair pulling frustration. then he could make his changes. he spent that week asking serious questions about the career path he was on. finally , he could merge his changes into the actual 4.5 release branch, but never back into any master branch. 




this resulted in tens of thousands of merge conflicts. the next few weeks were spent cutting through them, and by the end of that time, nate discovered the semester was nearly over. he was about to graduate. he went to lindsey, the co-owner of the small company, and handed in his resignation. 




<u+201c>we<u+2019>ve been really impressed by your work,<u+201d> she said. <u+201c>you could stay on after college, if you like.<u+201d> 




her tone was even, perhaps even a little indifferent, but there was a plea in her eyes. nate vaguely recalled hearing that gordon was a friend of reggie, the other co-owner. nate saw a hint that lindsay knew what gordon was doing to their software product. maybe she thought nate could be her ally in fixing it. 




or maybe nate was reading too much into it. discretion was the better part of valor. <u+201c>i<u+2019>m sorry, i just don<u+2019>t think i<u+2019>m the right fit for this team,<u+201d> he said. they made the polite noises, she promised him a recommendation letter, they connected on linkedin, and nate went off to find a source tree that didn<u+2019>t look like a tangled briar. 




a few months after nate settled into his new job, he snooped on gordon<u+2019>s linkedin profile- he was unemployed. a message to lindsay confirmed that she<u+2019>d fired him over his inability to deliver new features. the last anyone had heard, gordon had retired to a cabin in the woods, where he could be alone with many branches that never merged back into their trunks. 




editors note : we meant no harm in teasing douglas adams, but your reaction was much more interesting than it would have been to another tired twilight joke. [advertisement] incrementally adopt devops best practices with buildmaster , proget and otter , creating a robust, secure, scalable, and reliable devops toolchain.
the world tree
remy porter