Understanding Git and GitHub: The Basics Made Simple

Table of contents:

Understanding Git and GitHub

Key Terminology

Other Uses of GitHub

A Topic not Touched on…

A Note for Beginner Developers

If there’s one thing I’ve realised over the past few months, it’s how unaware I was of the intricacies surrounding Git and GitHub. I’ve learnt a lot, and finding the right information wasn’t always easy. What better way to help others than by providing this information to others - I say to myself!

The world of Git can be daunting for newcomers. There are countless YouTube videos and articles offering tips and tricks for seasoned developers or advanced commands, but there aren’t many resources for the basics. Existing resources for beginners are often too convoluted and never quite got through to me. By the end of this post, you should understand the differences between Git and GitHub, key terminology as well as the other uses of GitHub beyond just using it for code storage.

Understanding Git and GitHub

When we develop software, we want to save our changes, just like when playing a game or writing an essay. This is where version control systems come into play - that is what Git and GitHub are. These two are often used interchangeably and mistaken for being the same, but they are two distinct tools.

Using the Save Button in a Code Editor

Imagine you're playing a game and you hit the "Save" button. This action saves your current progress at that very moment. If you continue playing and something goes wrong, you can revert to this save point, but if you want to revert to an earlier version, you're out of luck as you've overwritten your previous work.

Committing to Git: Your Personal Save System (The ‘Single Player Experience’)

Now, imagine a game that lets you save and also keeps a detailed log of every significant checkpoint you create. If you need to go back, you can choose from any of these checkpoints. This is what Git does when you commit changes. It tracks your project's evolution, allowing you to experiment, make mistakes, and recover easily. When you’re using Git, you’re working with a local repository, and only you can access this because it is stored locally on your computer. Git is a piece of software that you install.

GitHub: The ‘Online Multiplayer Experience’

Finally, imagine an online game where you can log in from any console and pick up right where you left off because your code is no longer just stored locally on a computer system but remotely on a server. Additionally, your friends can join your game, and everyone can work together to contribute to its progress. This is what GitHub offers. It's a remote repository that stores your code on the cloud, making it accessible from anywhere. Using remote repositories, multiple developers are able to work on the same project (but you can keep your repositories private too). GitHub is a website, but other version control platforms exist such as GitLab, Bitbucket, and Azure Repos (part of Azure DevOps).

Recap

Key Terminology

Repository or “Repo”

In the simplest explanation, a repository is a container for source code. You can initialise a repository both before a project has begun and after a project has started development. When a repository is initialised, it creates a .git folder; this doesn’t show up in most file explorers by default. This .git folder contains a lot of intricacies that we don’t need to see, but it is like a super folder, and this is what tracks every change to every file that is made. There are two types of repositories:

• Local Repository: This is stored on your own computer. You can work on your project locally, making commits and creating branches without needing an internet connection.
  

• Remote Repository: This is stored on a server accessible via the internet or a network. Platforms like GitHub provide remote repositories. A remote repository allows multiple developers to collaborate on the same project from different locations.

Commit vs Push

Committing your changes takes a ‘snapshot’ of your code and saves it to your local repository. Afterwards, you can then Push the changes up to the remote repository, where it updates on whatever remote platform it is being hosted on. Alternatively, if you want to do this all in one go, you can do a Commit & Push to save the changes to your remote repository right away.

Pull

As you can guess, Pull is the opposite of Push. Doing a Pull will effectively sync your local repository and code editor to your remote repository.

Pull is the combination of two other Git actions:

• Git Fetch: When Git downloads all changes from your remote repository.

• Git Merge: Git immediately applies those changes to your local repository.

It is good practice to perform a Pull or Fetch before beginning work on a new Branch to avoid Merge Conflicts (more on these two terms below).

HEAD

The most recent commit. The HEAD moves each time a commit is made.

Staging Changes

When you’ve worked on your code for a while, you’ll see a list of changes made since your last Commit. Maybe you don’t want to Commit all of those for one reason or another, and you only want to Commit specific changes. This is where you add the changes to what is known as a Staging Area. Then, when you press the Commit button, only the items in your Staging Area are committed, and everything else isn’t.

Branch

Software development is often something that is carried out in a non-linear fashion. When we have multiple teams working on multiple features all delivering the same project how do we enable this and keep track of all changes? The answer is to use branches. 

Think of them as parallel versions of a repository. It allows developers to diverge from the main code base to work on different features, fixes, or experiments without affecting the main code. Once the work on a branch is complete, it can be merged back into the main branch.

Main/Master Branch

The primary branch of all repositories - depicted in the above image. All committed and accepted changes should be on the master branch. You can work directly from the master branch or create other branches.

Merge

The act of combining branches into a single codebase. Merging is typically thought of as merging feature branches to the master branch, but it can also refer to merging a sub-branch to a feature branch. You can merge branches using a pull request.

Merge Conflict

When the merging of branches goes wrong. An example of this can happen when two people make different changes to the same line of a file or when one person edits a file and another person deletes it. Git can't determine what is correct and will mark the file as conflicted and stop the merging process. The developers are then responsible for resolving the conflict.

Pull Request

Used to merge branches and also allows you to submit a contribution to another developer's repository. To make pull requests, you need to Fork a repo; this means making a copy of the repo to your GitHub account. The Fork maintains a link to the original upstream repo, which means you can Pull in future changes when necessary. Then you'll want to Clone your Forked repo on your local system to start developing your changes.

When creating a pull request, you are contributing to another developer's repository. It is always good etiquette to follow their contribution guidelines, which should be mentioned in their project’s README.

Clone

To download a remote repository to your local machine.

Origin

The name of the remote repository that a project was originally cloned from.

Upstream

When you Push changes, create Pull Requests, or Merge Branches, you are transmitting your updates and changes "upstream" to a remote repository.

Downstream

When you Pull, Clone, Fork, etc. from a repository, you are having information flow "downstream" to you from a remote repository.

Other Uses of GitHub

We've covered why developers use version control, the distinctions between Git and GitHub, and some helpful terminology. It's also good to know some of the other uses that developers like to use GitHub for.

1. To showcase their latest projects

2. To build their personal/developer brand

3. To contribute to open-source projects

4. To show how much better they are than others by how populated their contribution history is

Okay, the last one is just me compensating for my lack of contributions…

But my point still stands, dammit! On a side note, check out this great video, which helps you make your GitHub profile look much better. Maybe this will give you the motivation needed to take your graveyard of abandoned projects to a showcase of stuff you might actually finish - but probably not.

A Topic not Touched on…

When you look at different tutorials for how to use Git and GitHub, you’ll find some tutorials that do this from a command line:

And others are demonstrating this with a nice, user-friendly interface:

What’s up with that?! In truth, they are doing the same thing, and both are perfectly valid ways to set up and use version control, it all comes down to preference. Of course, older 'real' developers will tell you that using the command line interface is the proper way to do this while newer devs prefer the UI - after all, it's easier to blame the mouse when something goes wrong.

A Note for Beginner Developers

Before setting up a form of version control, make sure you can get a simple 'Hello world' program to run beforehand. It sounds simple, but it's an easy mistake to make when you're eager to get going on a project and you're using an unfamiliar language or code editor. A good general lesson in software development is to walk before you can run.

If you spot any inaccuracies or have suggestions for improvement, please don’t hesitate to reach out. Either leave a comment or feel free to message me on LinkedIn - your contributions will help to make these posts better and improve readability for future readers.