Projects People Resources Semesters Blog About
Version Control & Git

Version Control & Git

Version Control

Software is only growing in size and complexity so it’s incredibly important to have systems in place to track when changes occur, who made the changes, and what the edits were. That’s where Version Control comes into play. Version Control, as the name implies, is a way to track the different versions of your project throughout development, and if needed revert to previous versions if something goes wrong.


Over the past couple decades multiple version control software have been release, but none have been as successful or well known as Git. Git is an open-source version control software that efficiently tracks changes on files. It’s used in practically every software company and is incredibly useful for any type of project large or small.

Local and Remote Repositories

With multiple people working on a single project it can be difficult to keep track of whose computer has the final version. That being said, the “final” or “production” version of your project might be stored in a Github Repository that can be accessed by all members of your team.

Local Repositories is the current state of the code on your local computer whereas a Remote Repository are where you push your updates and changes to. Systems like Git can be used only locally but almost always is it part of a project that is has a corresponding remote repository. Remote repositories are hosted by companies like Github, Bitbucket and Gitlab

If a repository is cloned git clone the remote repository is automatically added under the name origin git remote add <Name> <URL> will add the remote repository if needed.

Pulling and pushing are what allow you to stay synced up between the local and remote repository. git push gets the new commit from the remote repository. git pull adds your commits to the remote repository.


A commit is a snapshot of the repository at some point in time. The commits come together to form the repositories history. The term is both a noun and a verb. As a noun: A single point in the Git history As a verb: The action of storing a new snapshot of the project’s state in the Git history.

How to commit:

  1. Make changes in your projects
  2. Stage changes in your staging directory
  3. git add <File name>

  4. Commit changes to apply them to your Git repository
  5. git commit -m <commit message>


A git commit message is a short sentence explaining what changes you’ve made. As a good rule of thumb, you should commit often and push your changes to your remote repository once features are done.


Branching allows you diverge from the main line of development and continue to do work without interfering with that main line. In case you’re coding you create a bug that breaks your whole project the breaking changes will only be in your branch and won’t effect your teammates or your production version of code that people may already be using. A new branch should be created for each feature you begin working on. This is to make sure that the files you may be creating or changing don’t effect your teammates and the features they might be working on.


When you edit and create commits in a branch that isn’t the master or main the commit history is saved in that branch until it’s merged to the main.

Creating a Branch

git branch <branch name> Checkout (or begin editing) that branch git checkout <branch name> Do both steps in one git checkout -b <branch name>


After you finish adding a new feature, make sure your tests pass, and commit your most recent changes it’s time to merge it to your main branch. Merging is Git's way of putting a forked history back together again. The git merge command lets you take the independent lines of development created by git branch and integrate them into a single branch.


Merge Conflicts

Merge conflicts generally arise when two people have changed the same lines in a file, or if one developer deleted a file while another developer was modifying it. In these cases, Git cannot automatically determine what is correct. Conflicts only affect the developer conducting the merge, the rest of the team is unaware of the conflict. Git will mark the file as being conflicted and halt the merging process. It is then the developers' responsibility to resolve the conflict. A conflict will look like:

<<<<<<< HEAD
this is some content to mess with
content to append
totally different content to merge later
>>>>>>> new_branch_to_merge_later

Think of these new lines as "conflict dividers". The ======= line is the "center" of the conflict. All the content between the center and the <<<<<<< HEAD line is content that exists in the current branch main which the HEAD ref is pointing to. Alternatively all content between the center and >>>>>>> new_branch_to_merge_later is content that is present in our merging branch. The most direct way to resolve a merge conflict is to edit the conflict and create a new commit of the modified conflicted file.

Good Git Etiquette

One of the biggest factors when using Git or any other version control is making sure the changes you’re making aren’t affecting your group members. That means making all of your edits in new branches

More Information

Git and Version Control are wildly important to software engineering, but it’s also primarily a skill that’s refined through time and practice. However, it is really helpful to learn many of the basic commands and have an understanding of them before they might be needed. The Git Documentation is a very well-written guide on Git for developers of any skill level. The Atlassian Git tutorials also cover in-detail how Git commands work.