By Craig Lockwood10 May 2017Tutorials
If the sight of a terminal or command line frightens you, this guide by Craig Lockwood will teach you to use GitHub to collaborate with others without ever touching the command line
If the sight of a terminal or command line frightens you, this guide by Craig Lockwood will teach you to use GitHub to collaborate with others without ever touching the command line
This guide will teach you how to:
GitHub is now the largest online collection of collaborative works that exists in the world. Developers, engineers and designers all over the world are using GitHub to collaborate and share code with others.
Once GitHub has become a part of your working routine, you will wonder how you managed without it. However, there is quite a steep learning curve to using GitHub. There are hundreds of tutorials on the web to help beginners get to grips with GitHub, but most require extensive knowledge of using the command line. There is, however, a way of using the most commonly used features without ever having to open a command line.
Before we learn about GitHub, it is important to understand what Git is.
Initially developed in 2005, Git has now been become the most popular choice amongst developers and engineers to manage code. Git is what’s known as a distributed version control system. That means when you clone a repository you take a complete copy of the entire repository including its history. Think of a repository as a database where records of all changes to your files are kept. A distributed system like Git means that anyone who has a copy of a repository on a local computer essentially has a complete backup. Git has gained popularity over recent years for this and a number of other reasons.
A local repository tracking our commits is fine, but it’s not a fail-safe and doesn’t lend itself to collaboration. This where services like GitHub come in.
Tip: GitHub is not unique. There are many alternatives, such as Bitbucket, Beanstalk and Codebase. GitHub, however, is a very popular service and offers a free account, which makes it an ideal choice for us to use in this guide.
Creating an account on GitHub is straightforward, best of all, GitHub is free to use for public and open source projects. If you would like to keep your projects (repositories) private and not publicly available there are paid plans - in this instance, a free account will serve our purposes just fine.
Visit GitHub.com and pick a username. Once you have submitted an email address and chosen a password your account will be active - you are ready to go.
A repository (sometimes called a repo) is a container used to organise a project. Repositories contain all of the folders and files needed for your project. This can include text files, images, videos, or any other kind of file you could think of.
For the purpose of this walkthrough, we will create a repository called TEST-REPO
.
TEST-REPO
.A repository called TEST-REPO
will then be created and you will be taken to the repository page. Note that the URL structure for the repository will be github.com/account-name/repository-name
.
Here you will see a list of all the files associated with this repository along with a commit message (more of this later) and a date/time of when that file was last changed. In our case, we will only see the auto-generated README.md file.
Branching involves diverging from your main line of development and continuing to work without affecting that main line. When you initialize a new Git repository, by default you’re checked into the master
branch. Branching can be a great way of working on a feature of a project without affecting the master
code. When you have finished working on your new feature you can then merge your new code into the main codebase, the master
branch.
The diagram above shows a branch from the master
branch called development
. After multiple changes, the development
branch is then merged back into the main
branch.
Let's create a new branch called development
.
branch: <strong>master</strong>
.development
.At this point, you should have two branches, master and development. Both branches will be identical as we have yet to makes any changes. You can check in and out of the two branches by selecting from the branch drop down list.
Before we go any further, make sure you have selected the development
branch as we are about to make some changes. When a change is made, these changes are saved as commits. Each time you commit it is a good idea to add a short commit message, this creates a readable history of the project and allows others who may be contributing to the project to understand what is going on at a glance.
Let's start by making some changes to the README.md file.
README.me
file.The changes just made to the README.md
file on the development
branch will only be visible on the development
branch, the master
branch will still show the old, unchanged version of the README.me
file.
So now we have two branches, each slightly different as the development
branch has had a change which we have then committed. To keep the master
branch up to date, we will now look to pull any updates into the master
branch - this is done using a Pull Request.
Pull Requests are what makes GitHub such a great tool for collaboration. At this point we have made changes to a file ourselves, but in theory, anybody could make these changes and then ask for a Pull Request, allowing their edits to be merged into a project. A Pull Request needs to be reviewed before the changes are merged, this prevents bad work from entering a branch.
A Pull Request will highlight the differences (often called Diffs) in the content between branches. Changes can be additions or subtraction to the content. Additions are highlighted in green whilst subtractions are highlighted in red.
So let's open a Pull Request for the changes that we made to the READEME.md
file.
master
to compare with the branch which includes the changes made, in this case development
.The Pull Request is now open. This means that the changes are ready to be merged into the main
branch.
The final step to merging the differences between branches is to merge the Pull Request. To do this, select the green Merge pull request.
We mentioned earlier that as well as an excellent platform for keeping track of versions of your work, GitHub is also great at collaboration. Thankfully, Github has a great mechanism for discussion in the form of mentions.
When you make a Pull Request, you may want to make a note to a particular collaborator. By using the @ symbol followed by a GitHub username, you can send a message to a collaborator, colleague, or anybody within the GitHub community. This feature is great for flagging issues, errors or areas for further discussion.
You have now learnt to use GitHub for collaboration with others. There are plenty of further resources should you wish to learn more about using GitHub. Some of our favourites are listed below: