Imagine that two people are writing a blog.
Ahmed and Naima are writing a blog together about their struggles learning coding.

The published blog is live here 👉 Educational blog

Ahmed and Naima are using the following development process for writing their blog:

• writing the blog in a single file on a single computer
• saving multiple versions of the file on the same computer
• taking turns to use the computer during the day

At the moment, the computer has a folder with the blog that looks like this:

To improve their way of working, Ahmed and Naima realise they need the following:

• a way to both know what the most recent version is
• a way to know what the old versions were, and in what order (i.e. how they got to the current version, and what content they may have deleted that they may want to get back)

To manage the different versions of the blog project, they decide to use Git.

In Git, we create different versions of a project over time by creating commits.

A commit is a snapshot of our project at a particular point in time. You can also think of a commit as a particular version of a project.

Commits store the following information:

• what changed in this commit
• who created the change
• what time the change happened
• what the previous commit was

A typical timeline of commits might look like this:

Earlier on, Ahmed and Naima realised they also need the following:

a way to share the history of the project between different users and different computers

To share a project and its history, we can use an online platform called GitHub

GitHub is a platform where teams can store projects along with a history of their different versions.

By storing projects on GitHub, multiple users can gain access to the history of a project.

We can use the Github interface to explore the different commits (versions) of a project too.

Recall that a commit is a snapshot of our project at some point in time.

Therefore, we should be able to check out a previous version of our project and look at the files and folders there.
We can use the Github interface to check out the files and folders at a previous commit.

We can view the different commits of a project on Github. This means we can see what the website looked like before, in previous versions.

Often we want to take an existing project and start working on it independently. In other words: we start making our own versions of the project separate from the original project.

We may have a repo with the following url:

We might want to start creating our version of this project in isolation from the original project.

So we can create a fork 🧶 🧶 fork A fork is a copy of a repository that exists on Github .

When we create a fork on Github, the new forked repository gets a new url:

We can also use Git on our local machine to perform similar tasks as we do on GitHub. So we need to address the following question:

In other words, we need to get a local copy of the repository which is on GitHub.

Once you’ve got a local copy of a codebase on your local machine you can start to view the files and folders in that codebase. You can use a code editor like VSCode.

VSCode is an application that enables developers to view and edit files on their local machine.

Here is a diagram representing how the repositories interact after forking and cloning:

We can check the commits on the remote repository as before:

On the left page of the page, we see additional information:

So what is main?

main is a branch.

Commits form a sequence that look like this:

A branch represents a particular history of development in a project - the different versions there have been.

There can be different branches with different names, which may have different versions.

For example, if we were testing out some different visual styles, maybe we would have one branch with some extra changes which make the website more blue, and a different branch with some extra changes which make the website more purple. These branches may share some commits in history, but have some extra different commits separately.

The main branch is often treated as a special branch - it’s where we put commits which people working on the project have agreed on. Other branches (e.g. the experimental purple branch) may have extra changes, and if people working on the project agree the changes are good, we’ll add those changes to the main branch.

When we’re working on something new, we haven’t agreed with other people that our new thing is good yet, so we often don’t add our changes to the main branch straight away. Instead we make our own branch to experiment on.

We can start to create independent branches like this:

In the diagram above, we can continue to commit on the “week-1-coursework” branch without altering the history of the main branch.