If you do not have a computer of your own yet, here’s how to complete your work directly on GitHub without a local environment.

Each repo on GitHub has a .dev environment so you can edit the code in your browser using an online VSCode.

You can go to this environment directly by replacing github.com with github.dev in the URL. For example, to open the Module-Onboarding repo, you can go to

https://github.dev/CodeYourFuture/Module-Onboarding

We use VS Code to write all of our code in the course. It is known as an Integrated Development Environment (IDE) and really helps you write great code.

🔗 Download and install VSCode now

💡 Tip

If you are working on a library computer, use the online version of VSCode called Github.dev.

The interface is mostly the same, but you cannot install extensions or use the terminal. You can complete all the tasks in the onboarding module without these features.

Git

You will use Git continually as a developer. We will cover Git in more depth later in the course. Right now, we will just check that you have it installed.

Open up a terminal and run the command git --version to double check you have Git installed. If it is installed successfully, you should get a version number (which may not be exactly the same as this example, but should look similar):

git version 2.40.0

Otherwise, you will need to install it or ask for support on your Slack channel.

You’ll need to create a CYF folder to store your projects on the course. You can do this any way you like, but here we are using the terminal.

How to create a folder using the terminal

1. Open a terminal on your computer.

For each of the steps below, you’ll need to use the command line in your terminal.

Use this cli documentation to remember terminal commands.

2. In your terminal, print your current working directory.

3. List the files and folders in your current working directory.

You’ll need a place to store your work for the course.

4. Make a new directory called CYF in your home directory.

5. Change directory into the CYF directory.

6. Double check you’re in the right place by printing your current working directory.

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 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:

https://github.com/CodeYourFuture/cyf-demo-repo

When the user EagerLearner forks this repo, the path changes from CodeYourFuture to EagerLearner.

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

Sketch this diagram in your notebook. When you inevitably get mixed lost about where your changes are, you can refer back to this diagram to help you understand what’s happening.

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:

How can we get a copy of an existing GitHub repository on our local machine?

In other words, we need to get a local copy 🧶 🧶 local copy A repository on GitHub is said to be remote. A repository on our own computer is said to be local. of the repository which is on GitHub.

We call a local copy of a GitHub repository a clone. The process of copying a remote repository on to a local machine is called cloning.

🎯 Goal: Clone a remote repository to your local machine

You’ll need to clone your fork of the education blog repo. Follow through the steps in the video “How to clone a repository from GitHub to Visual Studio Code”.

🎗️ Reminder:

• Use the URL for your fork of the education-blog repo when you are cloning
• When selecting the location to clone your files, choose the CYF folder you created in the module prep

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.

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 that have not been agreed on. If people working on the project agree the changes from the purple branch 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.

In software development, we break down complex projects into smaller, manageable parts, which we work on for a week or two. These periods are called “sprints.”

A sprint backlog is like a to-do list. It lists what the team has decided to work on this sprint. It’s chosen from a larger list, usually called the “product backlog,” which holds the entire project to-do list.

In this course, the backlog is a set of work designed to build understanding beyond the concepts introduced in the course prep. For your course, we have prepared a backlog of mandatory work for each sprint. You will copy these tasks into your own backlog. You can also add any other tickets you want to work on to your backlog, and schedule all of the tasks according to your own goals and capacity. Use your planning board to do this.

You will find the backlog in the Backlog view on every sprint.

Copy the tickets you are working on to your own backlog. Organise your tickets on your board and move them to the right column as you work through them. Here’s a flowchart showing the stages a ticket goes through: