What is Git and Git Hub (Part 2): A summary of terms and definitions

“We can Fork it before we make any changes to the code.”


The obscure sentence was one of several the two developers exchanged as we were going through a development proposal for a new client.

By the end of the session, it felt as if I had the means to compile an entire dictionary of new words, technical references and jargon - most of which I wouldn’t have been able to understand if it we were having this meeting several months prior.  

In an earlier article we introduced “What is Git and GitHub?”. Whilst we’ve had some fantastic feedback from marketers who have finally been able to ‘get it’, it’s unlikely the article would have helped them decode the lexicon used in by Git and Github’s most prolific users; developers. 

As a result, we’ve prepared our top list of Git and GitHub references with their definitions so that you can impress the pants off your technical team at your next development WIP.

Share this Image On Your Site



The most fundamental element of GitHub, a repository is essentially a project’s folder, much like the kind of folder you would see in a Dropbox or Google Drive folder.  

Repositories store every single project file, its documentation and its revision history of every document. Repositories can also accept multiple private or public collaborators.



Commits are easily one of the most frequented activities by a developer using GitHub. Simply put, a commit or revision is like ‘saving’ an updated file to its original folder and overwrites an older version (though as we already know, Git is great for version control). GitHub, for example describes a ‘commit’ as:

“an individual change to a file (or set of files). It's like when you save a file, except with Git, every time you save it creates a unique ID (a.k.a. the "SHA" or "hash") that allows you to keep record of what changes were made when and by who. Commits usually contain a commit message which is a brief description of what changes were made.”help.github.com



Clones are literally clones (copies) of a repository that sit on the developer’s computer instead of a server elsewhere.

Clones are great since you can download a code file to tinker around with offline or to be edited in a preferred code editor or integrated development environment.



A branch is a parallel version of a repository (ie; it literally branches out or away from the main repository, kind of like a temporary sub-folder).

It is contained within the repository, but does not affect the primary or master branch allowing you to work freely without disrupting the "live" version.

The beauty about ‘branches’ is that you can merge it back into the master branch when you’re ready to publish your changes.



Fetching refers to getting the latest changes from an online repository (like GitHub.com) without merging them in. Once these changes are fetched you can compare them to your local branches (the code residing on your local machine).



According to help.github.com, a ‘fork’ is a personal copy of another user's repository that lives on your GitHub account.

Forks allow you to freely make changes to a project without affecting the original, enabling limitless opportunities for experimentation and learning from other people’s work. 

A forked project also remains attached to the original, allowing you to submit a pull request to the original's author to update with your changes, ensuring you’re always working off a recent or up-to-date codebase.



Pushing refers to sending your committed changes to a remote repository such as GitHub.com. For instance, if you change something locally, you'd want to then push those changes so that others may access them.



Issues unsurprisingly are exactly as they sound. Issues are suggested improvements, tasks or questions related to the repository.

Issues can be created by anyone (for public repositories), and are moderated by repository collaborators. Each issue contains its own discussion forum, can be labeled and assigned to a user.



The role of the Blame feature on GitHub passes ‘blame’ on the version of the code file that resulted in an error occurring. As it states on GitHub:

“The "blame" feature in Git describes the last modification to each line of a file, which generally displays the revision, author and time. This is helpful, for example, in tracking down when a feature was added, or which commit led to a particular bug.”help.github.com 



Merging takes the changes from one branch (in the same repository or from a fork), and applies them into another.

A merge can be done automatically via a Pull Request via the GitHub.com web interface if there are no conflicting changes, or can always be done via the command line. 

By now you should be equipped with knowledge of Git and GitHub top terminologies and features of which you should hopefully start putting into practice. Of course, there are plenty of other rich features of GitHub especially, which we implore you to discover on your own.

P.S.: Why not check out Core dna’s GitHub profile and say hi!


Leave a comment

fancybox backgroundimage preloader fancybox sprite image preloader

You’re awesome! Now go and check your inbox.