So you want to be a software developer? Here’s a look at version control

Jason Anton is a full-stack developer with Owings Mills-based software firm Bellese Technologies and project lead for civic tech org Code for Baltimore. He is going to walk us through his workflow in GitHub and illustrate “version control,” which allows developers to manage changes to a project. When working with a team of developers on a project, this is why and how a developer makes a feature branch from the main branch before they change a line of code.

“The best way to understand GitHub is to think of it as similar to time-travel in comic books,” said Anton. “Git works in what are called branches, which are similar to the idea of a timeline. There can be many branches —or timelines —but there must always be a master or main branch. Or, in comics, a prime timeline.”

In comics, what happens in the prime timeline, or canon, is the official depiction of a character. In one well-known example that dates back decades, Batman is known to never use a gun. The hero using a gun in the recently-released Snyderverse movies is odd, but ultimately not a big deal because the movie version of Batman isn’t recognized as the genuine or main depiction of Batman. But if Batman used a gun in new comic books released by DC, it would deviate from the prime timeline. Fandom would rip their hair out. Writers would have to scramble to explain, or write in circles to make the new version of Batman make sense with the old.

When coding on GitHub, don’t make fellow developers rip their hair out by making changes in the code that will mean they have to do twice as much work to make it fit with what’s already running. Branching makes this possible.

“Work and changes should never be made to the main branch,” said Anton  “Instead, it is important to create feature branches so that work can be done in parallel to other work while the existing working code is left unchanged.”

Leaving the working code alone is important, because fixing one issue can create five more issues. A feature branch allows a developer to make a copy of the code, and work with it in an environment that’s not running live on an application. Then, changes in the code can be reviewed and approved before inclusion in the main branch. This prevents bugs, and potentially even more work to fix those issues.

To get started, there’s a naming standard that tends to be unique to each development team. The goal is to always being to create something relevant and easy to understand for the team.

When contributors to the civic tech projects at Code for Baltimore make feature branches, they use the following convention:<github-username>/issue-<issue-number>

In practice for Anton, that looks like this: revjtanton/issue-42.

With that line, he’s making a copy of the main branch code from the backend of an application and working on issue 42 in the code. The issue could be that pressing a link crashes the application, or that text is turning gold they want silver.

To create a feature branch, first be sure you’re on the master branch and that it is up to date. Then simply run git checkout -b <branch-name>. 

For Anton that’s: checkout -b revjtanton/issue-42.

(Courtesy of Jason Anton)

Then, proceed to make code updates as usual.

Once you’re done coding, save your changes to GitHub.

(Courtesy of Jason Anton)

Lastly, push the feature branch up for peer review by running: git push origin <branch-name>.

For Anton, with Code for Baltimore, that looks like: git push origin revjtanton/issue-42.

This is Anton’s way of saying he’s fixed issue 42. Now fellow team members check his work, and make sure it doesn’t create issue 43, 44 and 45.

(Courtesy of Jason Anton)

This process of pulling the code into a feature branch then requesting peer review before integration into the main branch saves a lot of headache and debugging later down the line. Anton recommends every project create and enforce policies to protect the working code.