Getting a Coding Job: Saving Your Code in a Repository

By Nikhil Abraham

Version control systems and code repositories allow developers to work together. The code for the front end or back end, along with the queries coders write to retrieve data from databases, are initially stored on your own computer. However, if you work on a team — and most coding jobs are team based — you need a version control system so that code on your computer can be shared with other developers without creating conflicts from differing versions.

If you’ve ever had a folder with filenames like Resume_Nov_2014_v1, Resume_Nov_2014_v2, and Resume_Jan_2015_v1, you’ve created a version control system for files. Similarly, the track changes feature in word processors is a version control system for content in a file. Version control systems for code track files and their content, and store code in centralized code repositories that are shared with other programmers. Typically, each developer has a local copy of the code, and everyone uses one centralized code repository.

Git is one of the most popular version control systems, and GitHub is one of the most popular code repositories. Other version control systems are CVS, SVN, and Mercurial.

The most basic version control system commands are checking in and checking out files. You check in a file when you add it to the code repository, and you check out a file by making a local copy of a file from the code repository. After you check out and change a file, you can either check in the updated file back to the code repository, or discard your copy and leave the original as‐is.

Every time you check in a file, add comments to the file so others can easily see at a glance what has changed without reading the entire file.

Sometimes conflicts can occur. For example, suppose you checked out a file with code for a restaurant’s home page, and you changed the image on the front page from a hotdog to a cheeseburger. While you were working on the file, a coworker changed the image on the front page from a hotdog to a milk shake and added an image of an ice cream cone.

If your coworker checks in the file before you, and you try to check in your version of the file, you would receive a warning from the version control system alerting you to a conflict. You would either need to overwrite your coworker’s changes with your own, or check out the version of the file with the milk shake and ice cream cone, replace the milk shake image with the cheeseburger image, delete the ice cream cone, and check in the file again.

Advanced version control system commands include branching and merging files. Imagine you had a crazy idea to add a cooking school to the restaurant web page. Instead of changing the existing files, you can make a copy of the master version of the files in the code repository called a branch.

You can keep checking in and checking out files from the branch as you add code and content for the cooking school. After you finish and the restaurant owner approves your cooking school addition, you can then merge the changes back into the master version of the files.

Branching code, making changes, and merging it back to the master version.

Branching code, making changes, and merging it back to the master version.

Before merging your changes, your coworkers may do a code review to check the quality of your code, typically making sure your code is bug‐free and well documented.