For all your git learning needs. This tutorial will focus how to interact with the cloud based version control system known as GitHub, using GitHub Desktop to do so.
You will need an account on GitHub in order to participate in this workshop. If you sign up using your school email, you can potentially get a free upgrade to a pro account. You can always change the email on your account later to reclaim your account for yourself once you've graduated. If you're interested in getting a free pro account using your school email address, you can find more information here.
GiHub is a user friendly, cloud based version control system. With a GitHub account, you can make repositories to store your source code, keep track of your changes make to your code (known as commits), and access the entire commit history of each and every file you add to a repository. You can keep track of multiple projects, generally having them all logically separated into their own repositories, and each of them will keep track of their own file history.
At its most basic level, GitHub gives you the tools to:
- Save your code to a cloud server, allowing you can access it and update it from anywhere
- Consolidate your code to a single location, called a repository, so you never lose it or wonder where the most current version of the code is on your computer
- Track changes you make to your code, giving you the ability to easily recover old copies of your code if you need to
- Discard changes to your code before committing it to GitHub, for when your current code changes are completely broken
- Collaborate with others on the same codebase without having to continuously send each other individual files to be manually updated
- Help make sure nobody's code changes are lost when you're collaborating on a project together, especially when multiple people are working on the same files at the same time
There are many ways you can interact with your GitHub repositories, including through the terminal, through your code editor, or using a separate GUI program. In this tutorial, we're going to focus on that last option, in the form of GitHub Desktop. Visit that link and download the program for your computers operating system.
When you install GitHub Desktop, it will also install the latest version of Git along with it. Git is the underlying open-source technology behind services like GitHub, providing us the version control system functionality.
Once you've installed GitHub Desktop, you'll need to connect your github account to it. Note that if you're working on a public machine, you need to make sure you log out of the program to disconnect your account from the program.
You can make repositories either directly on github.com or in the GitHub Desktop program. We're going to go through the process using GitHub Desktop, which you can find the steps for here.
It's important to note that once you make a repository on your computer (or clone one), GitHub Desktop is essentially watching for changes you make to any files inside of the folder that contains your repository. It knows to watch for changes in this folder because of a hidden item called the .git folder. Any files you add, change or remove will be determined to be changes to the repository. What you do with those changes is something discussed in the Making your first Commit section.
If you want to work on a repository on your computer that you didn't create from your computer, you need to clone that repository. Cloning allows you to make a local copy of the repository on your computer (we'll talk about local copies of repositories in the next section). Once you have a local copy on your computer, you can change the code on your local copy, and as long as you have permissions set on the repository you can publish your changes up to the repository on github itself.
You can find the steps to clone a repository here.
When you're working with your GitHub repository code on your computer, there are always at least 2 copies of that repository: One is the copy on the GitHub servers themselves, on the cloud (known as origin or remote). The other copy is the local repository on your computer.
When you make changes (aka commits) to your code using GitHub Desktop, you are updating the local repository code. Those changes will not make it to the remote copy of the repository until you push those changes to origin. That means that if you are collaborating with someone on a repository, they will not be able to receive your changes to the code until you push that code up. Once you do push the code, it will be sent to the GitHub servers, and you'll be able to see the changes on your repository on github.com.
Once you've got your repository setup on your computer, your local repository is now watching for any changes you make to any files inside of the repository folder (i.e. the folder that contains the .git hidden folder inside of it).
Once you make changes to a file, GitHub Desktop will display those changes on the left hand side, indicating whether it's a new file, a change to a file, or if the file has been deleted. These are different types of changes that GitHub wants to track once you commit them. Each change is tracked on the history of each individual file.
These changes are not part of your local repository history, until you have committed them. They are pending, waiting to be committed to the repository. In order to commit your changes, you must select the files you want to include in the commit (all the files that have changed are selected by default), add a commit summary message that indicates what changes were made to the repository, optionally add a description to go into further detail about what changes were made, and then click on the commit button. This will add the changes to the history of the respository, solidifying those changes as part of the official changes tracked on the respository.
Committing your changes only updates the local copy of your repository. It does not update the code on GitHub's servers. In order for your committed changes to be added to GitHub's servers, you must push the changes.
Since there are two copies of the repository that you're interacting with (the local copy and the remote copy on github.com), you need to make sure that your local updates are making it to the remote server, and you also need to make sure that you are receiving the updates from the remote server to your local copy of the repository. That's where fetch, push and pull come in.
Fetch is a the command you use to check if the remote server has any changes for you.
Pull is a the command you use to retrieve those changes from the remote server and pull them down onto your computer.
Push is a command you use to send your changes from your local repository up to the GitHub servers.
Every commit you make to your repository is adding to the history timeline of the repository. You can view this history directly in GitHub Desktop or you can view it on github.com. Each item listed in the history is a commit that someone made to the repository, and will show you all the files changed due to that commit at that time. This gives you a nice way to view code changes you've made to any individual file, so you can always retrieve old versions of code if you need it.
You can also revert commits from the history, to undo changes to the repository code, outlined here.
One of the other very useful aspects of using a version control system is the ability to maintain multiple versions of the code at the same time. Oftentimes you need to maintain at least two copies of your code:
- A stable copy of the code, usually referred to as the production copy of the code
- A development copy of the code where you are building new features, fixing bugs and testing everything new before moving the code into production
In order to maintain multiple copies of the code in a repository, you need to create separate branches of the code. A branch is essentially a copy of the repository code and its history. Commits you make to a branch will not be visible on other branches.
By default, your repository comes with a single branch: the main branch. You can make a new branch off of the main branch, as outlined here.
Just like when you commit code to your repository, creating a branch on your local copy of the repository does not add the branch to the GitHub servers by default. In order for your new branch to be available on github.com, you must publish your branch.
Once you've made a new branch, and added commits to it, you will eventually want to switch back to the main branch (or another feature branch). In order to switch branches, you can follow the steps outlined here.
You can make changes directly to your repository from the github.com website. This automatically makes changes to the remote copy of the repository, instead of your local copy. In order to see those changes on your computer, you will need to fetch and pull the changes down.
Editing files on github.com is useful for small changes and updates, but is not as viable when you are trying to add multiple files or changes at once, especially in complex folder structures. That is a task better suited for being done locally on your computer and pushed to the GitHub serveers.
Once you've created a repository, you can invite other github users to collaborate with you on your repository. Collaborators can be given various different permission levels, based on the roles they are going to play in your repository. The steps to invite collaborators to your repository can be found here.
Users who are invited to collaborate on a repository will need to access their email and accept the invite they receive there.
Sometimes there are files we don't want GitHub to track on the repository, such as automatically generated files when you compile your code, large library files that are added via tools like npm (see npm packages and modules), or files that contain information such as security tokens and passwords. These files are important to run your application locally, but we need a way to ignore them when we are making commits to our repository.
We can do this by creating a .gitignore file. Once you create this text file, you can add file and folder names to it that you don't want to be added to your GitHub repository, even though they're in the folder that GitHub Desktop is watching for changes. You can fine more information on how to use the .gitignore file here.
Here they can change privacy levels, archive repository, delete repository, etc.