- What are Version Control and Git?
- Version Control
- Local and Remote Repositories
- The Basics
- A typical workflow
- Getting Started
- Fetching, Pushing, and Pulling
- How to get the latest changes:
- How to commit:
- Creating a Branch
- Merge Conflicts
- Good Git Etiquette
- Adding Collaborators
- More Information
What are Version Control and Git?
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.
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 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.
- Click the
Codebutton on a Repository’s page
Open with GitHub Desktop
- If this does not work, copy the HTTPS Link
- In GitHub Desktop, choose
File > Clone Repository > URLthen paste your URL and click
A typical workflow
A typical workflow for setting up and using Git in a project normally consists of the following:
- Create a repository on GitHub
- Clone the repository to create a local version by clicking the
Codebutton on your remote repository’s page. Add collaborators if it’s a group project.
- Initialize a project files and any project-specific setup (
File > New Project, etc.)
- Branch for a new feature
- Make some changes to the code in your local repository.
- Create a commit based on those changes.
- Repeat steps 5 and 6 a few times.
- Create a Pull Request to merge the branch to main
- Repeat steps 4 through 8 a few times
- Tell all my friends about this really awesome project.
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:
Git - Installing Git
Before you start using Git, you have to make it available on your computer. Even if it's already installed, it's probably a good idea to update to the latest version. You can either install it as a package or via another installer, or download the source code and compile it yourself.
You will also want to create a GitHub account in order to store in a remote repository and collaborate with others:
Build software better, together
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:
Installing GitHub Desktop - GitHub Docs
You can install GitHub Desktop on supported operating systems, which currently include macOS 10.12 or later and Windows 7 64-bit or later. If you have an account on GitHub or GitHub Enterprise, you can connect your account to GitHub Desktop.
Fetching, Pushing, and Pulling
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.
How to get the latest changes:
git pushand the latest changes will be synced.
Fetchand check if there are any changes.
- If there are changes, click
Pushto receive the changes.
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:
- Make changes in your project
- Stage changes in your staging directory
- Commit changes to apply them to your Git repository
git add <File name>
git commit -m <commit message>
- Make changes in your project
- Write a commit message to describe your change
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>
Current Branch > New Branch. Give your new branch a name and click
- To checkout a different branch, choose
Current Branchand then select the branch you want from the list.
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.
- Once you’ve made commits to a branch, you’ll see an offer to create a
Pull Request. When you’re ready to combine your changes with another branch, click
Create Pull Request.
- This will open GitHub on the web. Follow the instructions and finish making a Pull Request.
- Then you can merge your changes. In the case you have collaborators, they can comment on the change and review your code before agreeing to let you merge the change into your project.
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 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:
Inviting collaborators to a personal repository - GitHub Docs
Repositories owned by an organization can grant more granular access. For more information, see " Access permissions on GitHub." Pending invitations will expire after 7 days, restoring any unclaimed licenses. If you're a member of an enterprise with managed users, you can only invite other members of your enterprise to collaborate with you.
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.