If you do not have a computer of your own yet (first, let us know!), 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.

💡Tip

But if you have a computer from MigraCode or a computer of your own please download VS code and edit your code locally there (github.dev is only an emergency option).

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 MCB 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 MCB in your home directory.

5. Change directory into the MCB directory.

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

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🧶🧶 forkA 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.

📌 Understanding Forking and Cloning

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

Sketch this diagram in your notebook. When you inevitably get confused about where your changes live, this visual will help you understand the flow of changes between repositories.

In addition to using GitHub through the browser, we can also use Git on our local machine to perform similar tasks. So, here’s the key question:

How can we get a copy of an existing GitHub repository onto our local computer?

In Git terms, this means creating a local copy🧶🧶 local copyA repository on GitHub is a remote repository. A version of it on your own computer is called a local repository. .

The process of copying a remote repository to your local machine is called cloning. The resulting copy is referred to as a clone.

🌟 Goal: Clone a remote repository to your local machine

You’ll need to clone your fork of the education blog repository. Follow along with this video for step-by-step instructions:

🎗️ Reminder:

• Make sure you’re cloning your fork of the education-blog repository (not the original).
• Choose the MCB folder you created in the module prep as the destination for your clone.

💡 Industry Insight: While forking is useful for learning, companies typically don’t use forking when working on internal projects. Instead, developers clone the original (or central) repository and collaborate by creating branches and pull requests within that shared repo. Forking creates a separate copy under your own account.

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 that you will have already used in your application process. This is a refresher to make sure we are all on the same page.

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: