As software engineers, we have a responsibility to build code that not only fulfils the required behaviours of the programme but is part of a well-structured and “clean” codebase.

What is meant by “clean”?

Clean code generally means code that is:

• Understandable for other programmers. We achieve this through good variable naming, avoiding chaining too many methods in one line, good choice of syntax depending on the data type being used, etc.

• Avoids duplication. Not repeating code where it could be a reusable function, making more efficient choices in our conditional logic, using loops where relevant, etc.

• Passes all tests (if you have tests in the repository).

• And importantly, contains a minimal amount of “moving parts”. Removing any bulk that isn’t contributing to the behaviour we want to achieve. This means watching out for “dead code”.

Keeping to clean code helps us collaborate better, code more efficiently and accurately, and make programmes more readable.

It means products we build can be maintained in the future without wasting more developer time than necessary trying to work out what the code is doing.

What is meant by “dead” code?

A segment of code that is no longer used.

As a programme evolves there might be many changes, fixes, feature additions made to the code. There is a high probability that when those changes were made to the code, there was no time to “clean” up the existing or old code. This can lead to code being left in the repository that no longer has purpose, whether by accident or on purpose.

One common way to identify dead code in our programmes is by using a IDE🧶🧶 IDEA Integrated Development Environment, like VSCode. IDEs are special kinds of text editors which understand programming languages. This means they can add extra functionality, like syntax highlighting, and refactoring support. . An IDE can often make unusable or unused code obvious to us through its colour scheme.

When we remove dead code we can reduce the “bloat” of our code, making it easier to maintain and improving debugging processes. It means we don’t need to read and understand code that isn’t used.

In the related backlog item, you will look for dead code in an existing code base and handle it appropriately. Have fun!

So far you have seen two ways of interacting with your file system: your computer’s terminal application and its explorer GUI. You probably have a preference and you probably prefer using one over the other for particular tasks. Neither is the “correct” way of working, but it’s useful to know about both.

We have similar options for Git. So far we have been working with VSCode’s version control tools and they’re fine for what we need, but there are some things that are quite fiddly and some things we we can’t do at all. In this sprint we’ll look at using Git in the terminal and recreate our VSCode workflow, looking at some of the differences as we go. Both are using git.

Preparation

We’re going to recreate our workflow from the Onboarding module and sprint 1 of JavaScript Fundamentals exactly. We’ll create the same files and the same commits, but this time we won’t touch the source control tab at all.

Start by opening your terminal and creating a directory to work in. Call this one git-cli-practice

mkdir git-cli-practice

Initialising a repository

Everything we did using buttons in VSCode can be recreated using terminal commands. Think back to working with packages last sprint: we knew we were doing something with npm because the commands we used all started with npm. In a similar way our Git commands will all start with git.

We initialise a new repository using the init command in our directory.

git init

Our directory is now a local git repository. We can confirm this using the status command.

git status

This should give the following output:

On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

We are ready to start committing!

What have we actually done here? The ls -a command will list files and folders including anything which has been hidden and if we run it here we will see that a .git folder has been created. This is the directory Git uses to store our commit history and everything else it needs to do its job.

It’s time to create a file to work in. Use the terminal to create notes.txt then open the directory in VSCode.

touch notes.txt

Just like last time we’ll add some text to the file and save it.

Git in the Terminal

I'm learning how to use Git from the command line.
It's going well so far!

Staging changes

Let’s move back to the terminal. Your terminal may have some sort of indication that something has changed, but it may not. We can always use git status again to check the state of our repository. This time the output will look like this:

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	notes.txt

nothing added to commit but untracked files present (use "git add" to track)

This is the terminal equivalent of the big green “U” next to the file name in VSCode. Git is very helpfully telling us the command we need to stage our change so let’s go ahead and do it.

git add notes.txt

Now if we check our repository’s status again we see a different message:

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   notes.txt

We can add multiple files at once if we want to by passing multiple arguments to git add (this is what the ... in the status message’s command suggestion meant):

git add file1.txt file2.txt

Making a commit

The next step in the process is to commit our staged change. We still need to provide a commit message and it’s still very important that it tells our colleagues what we changed and why. We don’t have a text box to type it in though, so how do we supply the information?

We will use the git commit command to make the commit but we will use the -m flag to provide the commit message.

git commit -m "adding initial notes"

Our commit has now been made.

Another git status check will tell us we’re back at “nothing to commit”.

Viewing the commit history

We no longer have our repository’s history represented as a nicely-coloured timeline, but we do still have access to the information. The git log command will show us the same information, and will actually give us even more!

commit dc976c03d859a368281ff8875997d1afa6e643d8 (HEAD -> main)
Author: A. User <user@email.com>
Date:   Thu Sep 17 17:10:24 2026 +0100

    adding initial notes

We can see all the same information that VSCode provided us with:

• The commit message
• The user who made the commit
• The date and time of the commit
• The branch the commit was made to

We also have a long hexadecimal number on the first line which wasn’t there before. This is the commit hash which acts as a unique identifier for the commit. Any time we need to refer to a specific commit we use this hash. Typically we only need to provide the first seven characters when doing so.

Commits are listed with the most recent first and you can exit the log by pressing the q key.

The next step in the process is linking our repository to a remote so we can push our changes to GitHub.

Connecting a remote

When we want to do something with a remote through terminal we will use the git remote command. First we need to add the remote to our repository. Copy the url for your repository from GitHub and use it with the command below:

git remote add origin https://github.com/your-username/git-cli-practice.git

• git remote tells us we are using a Git command specifically for managing remotes
• add tells us we are adding a new remote
• origin is the name we attach to the remote
• the final part is the url

We can create as many remotes as we like so long as they have unique names - this allows us to work with different people’s forks of the same project. By convention we will keep using origin as the name for our remote source control repo. We can see a list of all available remotes by typing git remote with no other arguments.

Occasionally we may need to disconnect a remote from our local repository. If that ever happens we can use the command git remote remove {remote_name} to break the connection.

Our repositories are linked and it’s time to push our changes. Once again we can condense many button clicks down to a single command in the terminal.

Pushing changes

The command we will use is git push, but it needs two extra pieces of information:

• The remote we are pushing to
• The branch we are pushing

We only have one of each at the moment so our command will be pretty straight-forward. We’ll see how to push a different branch in a later section.

git push origin main

This will take every commit on main which has not yet been pushed and upload it to the url specified as origin. In our case this will be GitHub and if we check the repository now we will see our files there, just like when we used VSCode.

Default upstream

When we push to GitHub we are pushing to an upstream branch. If we are regularly pushing to the same branch we can configure a default so that we only need to type git push without the remote or branch name. Handle with care! When we are working in the terminal we don’t have any of the safety features VSCode has and it would be very easy to accidentally push something to the wrong place if we rely on a default.

We can set a default by using the -u flag when we push.

git push -u origin main

After doing this we can just run git push without naming a remote or branch.

Pulling

The commands to pull are similar but use the pull keyword instead of push.

git pull origin main

It is possible to pull one branch from GitHub onto another locally, eg. pull the remote main onto the local my-feature-branch. This can lead to conflicts though and is best avoided in favour of keeping each local+remote branch pair in sync.

By now you have had lots of experience creating branches and raising pull requests on GitHub. When it comes to merging work we won’t make any fundamental changes: we will still use GitHub to manage PRs and to complete any merges when working on group projects. Pull requests are a feature of GitHub specifically rather than Git so we can’t recreate them exactly using the terminal, but in this section we’ll look at how we can create and merge branches.

Creating a branch

For this section we’ll revisit the educational blog from the JavaScript Fundamentals module. Open the project in VSCode and navigate to that directory in your terminal.

We’re going to follow a similar workflow to begin with by creating a branch. For this we’re going to use the git branch command along with the name we want to give our branch. Since this will be our second update we’ll call it update-blog-2.

git branch update-blog-2

At this point we diverge from how VSCode handled the process because we haven’t actually switched to our new branch, only created it. We can confirm this by typing git branch without any arguments and checking the output.

* main
  update-blog-1
  update-blog-2

We have our main branch, our new branch and update-blog-1 from our previous Git work. The asterisk indicates which branch we are currently working on. If we want to work on our new branch we can move over to it using git switch.

git switch update-blog-2

Checking git branch will confirm the change.

  main
  update-blog-1
* update-blog-2

If we know we’re going to switch immediately we can do both steps at once by adding the -c flag (for “create”) to the switch command and providing the name of the branch.

git switch -c update-blog-2

Merging

With the tools we have had at our disposal so far, at this point we would publish our branch to GitHub and raise a pull request. Once everything was reviewed and merged we would pull the updated version of main and continue. To be clear, this is still the recommended way of working!

It’s not the only way of working though. We can use git merge to complete the merge locally and bypass GitHub. This has its drawbacks though, in particular the fact it is only possible to get your changes reviewed if your colleague is in the room with you.

We need to think carefully about how we manage the merge. We don’t want to end up with any broken code on our main branch, so if there are any issues it’s better to sort them out before they get there. How will we know there are going to be issues?

Before merging our branch onto main we can discover any conflicts by merging main onto our branch first. If there are problems (such as merge conflicts) we fix them on the branch and leave main unpolluted for everyone else. Once the conflicts are resolved we merge our changes to main.

First we need to ensure we are on the correct branch. Use git branch to check if you are unsure. Then use git merge and the name of the branch you want to merge.

git merge main

We are asking Git to merge the named branch onto the current branch. If there were commits on main which we did not have on update-blog-2 they would be moved across, but since there aren’t we will see a message confirming this.

Already up to date.

The next step is switching to main:

git switch main

Pause for a moment and look at the files in VSCode - see how the new tips you added have disappeared? That commit only exists on update-blog-2, so the changes we made don’t show up on main yet. We can confirm this by checking git log and seeing that the commit isn’t listed.

Next merge our working branch:

git merge update-blog-2

This time we do have some commits to merge so we get a summary of the changes:

Updating 4244c24..438484a
Fast-forward
 blogs/1.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

And now our changes are visible in VSCode while we’re on main.

Deleting branches

When working on longer projects we will likely end up with a lot of branches. This can get very confusing very quickly so we’re going to practice good Git hygiene by deleting branches we no longer need.

We’re going to use the git branch command again but this time we’re going to add a flag. By including -d before a branch name we will delete the branch locally, but not on GithHub. Likewise if we delete a branch on GitHub the local version will remain. Let’s delete update-blog-2 since we’re done updating our list for now.

git branch -d update-blog-2

Checking with git branch will confirm the branch is gone.