So you want to be a software developer? Here's a look at version control - Technical.ly Baltimore

Software Development

Dec. 15, 2020 10:59 am

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

Full-stack developer Jason Anton walks through his workflow for managing changes to code. “The best way to understand GitHub is to think of it as similar to time-travel in comic books,” the Code for Baltimore tech lead said.
A look at Jason Anton sending his code to peer review.

A look at Jason Anton sending his code to peer review.

(Courtesy photo)

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.

Advertisement

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.

A gif showing code.

(Courtesy of Jason Anton)

Then, proceed to make code updates as usual.

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

A gif showing code.

(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.

 

A gif showing code

(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.


Donte Kirby is a 2020-2021 corps member for Report for America, an initiative of The Groundtruth Project that pairs young journalists with local newsrooms. This position is supported by the Robert W. Deutsch Foundation. -30-
CONTRIBUTE TO THE
JOURNALISM FUND

Already a contributor? Sign in here
Connect with companies from the Technical.ly community
New call-to-action

Advertisement

Sign-up for daily news updates from Technical.ly Baltimore

Do NOT follow this link or you will be banned from the site!