If you have been developing websites for a while you might have felt at some point that there could be a better way of making changes to your site in a non-destructive way or having a remote back up of your project that you could restore your local working files from in the event that something went horribly wrong.
Well, if dealing with these scenarios in a manual and somewhat laborious fashion has been irking you, then GitHub might have a solution that fits your needs.
What is GitHub?
Github is first and foremost a remote hosting service with an integrated set of tools for assisting developers via a version control system.
We’ll talk a little more about version control later, but, for now what is important is that we recognize that at it’s core GitHub provides developers with a remote location to store the projects they are working on. However, this differentiates substantially from a trivial cloud storage facility in that GitHub is built on Git. This begs the question what is Git and how does it make GitHub better?
Git comprises much of the underlying functionality that GitHub presents in an easy to use Web-based interface.
Aside from the web hosting facility that GitHub offers it’s members (in free and paid versions) it also merges a harmonious relationship between local development leveraging Git functionality and extending that functionality remotely to the web using GitHub.
Tools for Developers
The process of developing non-trivial Software is generally not linear, the approach will often be iterative. For example, when developing a website you might like to try styling certain elements of your site differently. However, actually seeing these changes implemented in your site might require replacing your existing CSS with the modified version while not actually knowing if you’re going to like the changes you make. This could be particularly destructive to your site especially when the changes require modifications to the site’s structure or DOM, that is to say multiple files would get effected by the change. You might subsequently make these changes nonetheless, only to realize that you preferred the site before the changes where implemented but would still like to keep some other unrelated changes you made while updating the styling. Restoring your site to it’s previous state and keeping the other changes in this case could be extraneously, time-consuming as you manually sift though file after file, one line of code after another trying to identify and decide upon what should to be kept and what needs to be reverted.
Git and subsequently GitHub implement a unique Revision Control System that addresses this problem. Simply put for the purposes of this article the Git Revision Control System (RCS) provides us with automation tools for,
- storing, organizing and working with data locally,
- identifying changes between different data states,
- providing us with means of addressing these differences,
- uploading data to GitHub,
- and retrieving data from GitHub.
Distributed Revision Control
Consider this scenario, you are developing an application for a website and you would like to experiment with integrating some one else’s code into your app but you also don’t want to risk breaking the working version of the app. At the same time you would like to make sure that you can retain a remote backup of your working app and still permit other developers the opportunity to work on or assist you with your project’s source code, documentation etc.
Not all of the above criteria is necessary on every web app or website project, but atleast one or more will likely be applicable to any software development project. This is where Git and GitHub can help to meet your requirements.
Each user that joins GitHub becomes a member that is responsible for maintaining their own repositories. These repositories are storage facilities for different versions of your project’s codebase.
Along with all the development tools you need for your project you will also need to have Git installed on your local development workstation.
Git is a command line tool, with a very simple set of directives to get you up and running with a Distributed Revision Control or Version Control System project. Revision Control refers to managing your project’s different versions, for example version 1 with the original styling and version 2 with the styling modified (as per the example noted above). Git and GitHub’s type of Revision Control is Distributed because each user is responsible for their own repositories, both locally and remotely. Subsequently, each version of the project will mirror it’s previous version with additional changes where necessary. This alleviates reliance on accessing remotely stored data or data that might have become corrupt locally.
Solutions for Different Software States
Git refers to the software comprising our projects as being in one of three different States, Modified, Staged or Committed.
Initially when we start a project it is in the Modified state, continuing to work on the codebase does not modify it’s Git related state i.e. the software remains in the Modified State. However, in order for Git to track changes to the project and provide us with the functionality that allows us to revert to previous versions of the project (among other features) we need to make a commit, which is simply a directive issued to Git to tell it to track the current status of the project. But, before making a commit we need to tell Git which files we would like to add to the commit. Files that are added to the que to be committed, will be analysed for changes and placed in the Staging Area.
Lets Get Started…
When our software is in it’s primary state we have just began working on our project, subsequently we will be working locally and our project will remain in the Modified State. Once you are ready to make a commit, and it could be recommended that you start committing from the very beginning of the development process and regularly thereafter, navigate to the root directory of your project. eg.
Then initialize it for usage with Git.
At this stage all you’ve done is started the development process and set up your project for usage with Git, which has subsequently created a .git sub-directory in your projects root folder. This directory is where git stores all of the pertinent information relating to the different versions of your project.
Assuming you already have files in your project’s root directory, you might want to add them to the Git Staging Area so that they can later be committed.
To add all existing files and those within sub-directories of your main project to the Staging Area, simply run the following command,
git add .
This command will examine the contents of your project and check for files that are in a different state to those represented within a committed state. If this is the first time you are running the command, you will subsequently have no committed data. Therefore all the files within your project will be added to the Staging Area, ready to be committed.
To make a commit, simply run the following command,
git commit -m 'Type Your Message Here'
Making a commit must follow the sequence of directives as they have been stipulated above. In the git commit command the -m flag has been used followed by a string. Replace the text within the string with something relevant to your commit for example ‘ver 0.01’
At this stage you can run a status check to ensure that the commit was successful.
In this post we looked at what Git and GitHub are and how they can assist us with building websites and other software. We also setup a local repository and made our first commit. When I next return to this topic we’ll have a look at how to examine the differences between versions of the same file and how to resolve those differences. We’ll also look at branching and merging and finally uploading our project to GitHub.