Software can be very complex, but it’s important to feel comfortable taking risks. It’s 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 revert to previous versions if something goes wrong.

Git is an open-source version control software that efficiently tracks changes on files. Nearly every company uses it, and it’s great for projects of any size.

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 hold the current state of the code on your local computer whereas a remote repository is where you push your updates and changes to. Systems like Git can be used only locally but almost always are part of a project that 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.

A typical workflow for setting up and using Git in a project normally consists of the following:

The rest of this page will explain the necessary terms for following a workflow like this one.

Follow this guide in the official documentation to install Git:

You will also want to create a GitHub account in order to store in a remote repository and collaborate with others:

Finally, we suggest using GitHub Desktop because it obfuscates many of the Terminal commands newcomers can find complicated and lets you focus on strictly what’s necessary. To install GitHub Desktop, follow this guide:

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.

fetch is another term you might see. A fetch is a check to see if there are any changes, such that you need to push them from 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.

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.

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 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:

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.

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 and then folding them in using a Pull Request.

To add collaborators, you’ll need to be using a remote repository like GitHub. Once you’ve added your code to the remote repository, add collaborators using this guide from the GitHub documentation:

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.