JWS Docs / FAQ's, Info & Tips

VS Code Web Editor

The github.dev web-based editor won't open?

You need to be logged into your GitHub account to use this.

Minimap

The Minimap which is a page overview on the top right hand side of your editor. Can be turned off if you want more editor space on smaller screens, or if you just don't want it available, by right clicking over the map and then selecting Minimap option.

To turn it back on should you want to at any time head to the hamburger menu then View then Appearance and then click on Minimap.

You can also control features within VS Code by setting values within the user or workspace settings

To turn the Minimap off you would set "editor.minimap.enabled": false

This page in the VS Code docs covers how to and what the user or workspace settings are getstarted/settings

Whilst you are in the setting for Minimap you can also choose to autohide the Minimap so it will only show if you mouse over the area where the Minimap is. Which can make the screen a little more clear for you to focus on what you are typing or reading.

Adding MARK:

When you are working with CSS or HTML files sometimes it can be a little over whelming to know where you were working last time. So it can be helpful to add what's called a comment.

In HTML this can be done by pressing Ctrl + / which will add <!-- --> You can then type a short note or title between these tags <!-- Working on this section -->

In CSS this can be done by pressing Ctrl + / which will add /* */ You can then type a short note or title between these tags /* Trying out new colours here */

Which is great but what if you could see these highlighted in the Minimap view from where you could just click and travel to that point of the file. Well we've got some good news for you by adding MARK: within the comment you can. It will show up on the Minimap in a large font for you to easily locate and click on.

You can also change the appearance of the text by going to the settings and doing the following:

Click on the cog icon in the right hand panel then choose settings

Click to expand the Text Editor section

Then click on the Minimap we can then freely adjust the values of "Section Header Font Size" which is set to 10 and "Section Header Letter Spacing" which is set to 1

So to make the text larger and the Letter Spacing closer "Section Header Font Size" set to 14 or 16 or any value you choose and "Section Header Letter Spacing" set to 0 or 1 depending on your choice.

This MARK: feature can also be useful to plan out a page with headings then you can work your way down the list of headings to add the needed content or markup.

Just before we end this tip you will see "User" and "Workspace" in the settings. So "User" means change this for you, and "Workspace" means change for just this project.

Gutter indicators

When you open and begin making changes to a folder in your Git repository, VS Code adds helpful annotations in the gutter and to the overview ruler.

•   Red triangle highlights where lines have been deleted.
• Green bar highlights new added lines
• Blue bar highlights modified lines

What do the numbers in the blue circle mean?

This depends where its being displayed:

• Over the files icon means you have unsaved file or files
• Over the source control icon means you have pending changes
• Over the Extension icon means that an update is available. To update the Extension click on the blue text saying Restart Extensions

Working with CSS variables ( Custom Properties )

When you are working with CSS variables ( Custom Properties ) it can be a real pain as they are defined at the top of the CSS file and you might be in the middle of the file so you end up scrolling up and down constantly if you want to make changes. But there is a handy shortcut to this problem.

You can right click on the variable name within a var( ) for a CSS selector, lets say nav a:link {color: var(--color-one-nav-btn ); right click on --color-one-nav-btn and choose Go To Definition ( Ctrl + F12 ) which will take you to the :root area and place you at the definition of the current var. Once we have made the change if we wanted to go back to where we were before, we can click on the var --color-one-nav-btn and choose Go To References ( Shift + F12 ).

However we can do much better than that so lets again right click on the --color-one-nav-btn within the ( ) and this time choose Peek then select Peek Definition ( Alt + F12 ) this will open a view of the :root section right under the current line you are on. Within this view you can inspect the values or make changes the value of the var.

This is great as no scrolling is needed and you don't have to lose your focus to where you are currently working. To close this view click the X on the top righthand side.

Git & GitHub

Oh No, I just closed my web editor tab!

Firstly don't panic, if you head back to your repository page on GitHub you may still have the tabs open, and if you reopen the web editor you should see by magic where you were working before you closed the tab. This is due to github.dev web editor making use of the browsers local storage.

However I would not plan to use this feature between editing sessions. A branch is a much safer working practice see the below FAQ I made changes to my files but want to leave it for another day what should I do?

You show committing into Main but is that a good idea?

We tried to keep it straight forward whilst you are learning all the options, terms and workflow. However generally, it's good practice to avoid committing directly to the main branch in collaborative projects. Instead, create feature branches for your work and merge them into the main branch once they're reviewed and approved. This helps keep the main branch stable and avoids introducing bugs or incomplete features.

However, if you're working alone on a project, you might commit to the main branch more frequently, but it’s still wise to use feature branches to keep things organized. This way, you can experiment without affecting the main branch until you're ready to merge your changes.

We have covered two ways to make branches and merging the changes back to the Main branch in lets make an edit and alternative branching pages in the Docs. We also highlighted its a good idea to have an issue raised to explain or track the branch outlook or goals.

I made changes to my files but want to leave it for another day what should I do?

We have all encountered this situation from time to time, and as we are currently working in github.dev we don't have access to the git stash command (We will cover this in the section that covers working locally with Git and GitHub).

So the best method we have found to do this is to create a new temporary branch and commit the changes to this branch which you will be able to return to when you want.

To accomplish this from within github.dev click on source control icon then click on the three dots menu ... and choose Branch and then Create Branch you will then see a pop up text box to name your branch, lets type temp (or name of your choice) and press return. You will now be offered to move to your new branch which you should choose to do. Now we can stage the changes enter a "Commit Message" and press Commit & Push

Our changes are now on GitHub in a branch with the name temp (or whatever you named it) within our repository.

When you are ready to resume working again on these changes head to your GitHub repository page click on the Branches menu option and choose temp (or whatever you named it) branch. Once it is displayed you can open github.dev in the usually way . or Shift ↑ + > which will open this branch where you can carry on working.

Once you are happy with your changes you can raise a Pull Request and merge the changes as covered in our Docs lets make an edit and alternative branching pages. Should you ever just want to delete a temp branch, you can just click the trash can icon on the GitHub Branches page and its gone.

I made some changes using github.dev but I changed my mind on them?

No problem just head to the source control section. Locate the file name of the file you made the changes to hover the mouse over the filename and icons appear click on the Discard Changes icon.

A pop up appears with a question "Are you sure you want to discard changes in jasminedesign.css?" choose Discard Changes. Now your file is back to how you started.

I've made a few changes to my files can I review them before I stage the changes?

Yes you can, right from within github.dev. Click on the source code icon you will see a list of files that have had changes applied to them in this editing session.

If you Click on a filename you will see a diff editor view of the file highlighting the changes made.

On the left hand side showing the starting point of the file and the righthand side showing how the file is now (These can be swapped around using the icons at the top of the righthand side diff view. You can also choose to view these changes in Inline view which is one view with both files changes highlighted).

• The lines where changes have taken place you will see have a red background
• Lines where text has been added/updated will have a green background
• Delete lines will show up red and if nothing has replaced the delete lines the file will show a hashed background to highlight the removed lines.

So I can hear you now thinking can I make changes in this diff view, yes sure the diff view has full editing capabilities.

Can I correct my last commit Message

Yes you can however not using the github.dev web editor, you need to open a GitHub Codespace on the branch as we need to use the terminal (don't worry its straight forward).

Lets head to the repository GitHub Page, we are going to click the green <> Code button and then we need to click on green Create codespace on master button.

(If you are not working on the main branch you will need to select the working branch first before clicking on the <> Code button. To do this click the Branches button then select the branch you want, then click the <> Code )

Now your codespace will launch you will see an open terminal panel ( if not, use the hamburger menu then View then Terminal ) to open a terminal.

If we want to change the commit message of the last commit we can do this using the Git command amend, lets see it in action. Within the terminal we need to type git commit --amend -m "Updated commit message"

The --amend option is used to modify the most recent commit, either to change its message or include additional changes you forgot to stage, and the -m flag stands for "message." Once we are happy with the command we need to press enter key.

Now we have updated the commit message we need to push this change back to GitHub, but if we have already committed this to GitHub (the remote) we need to use the terminal again, as we need to pass the --force flag to over write the last commit.

To do this we type git push --force then press enter key.

If you now head to the GitHub repository page and review the commit history, you will see the last one has been updated.

We now need to stop the current codespace session along with deleting the codespace storage to stop the billing session, Click here on Closing Codespaces to launch a popup covering the steps you will need to follow.

We have also covered Codespaces within the docs, if you would like to read more about GitHub Codespaces.

But I forgot to add or stage changes in another file also

You are in luck we can do this as well using --amend flag. So lets say I forgot to stage and commit the changes to the readme.md but did commit changes to the index.html

In your github.dev web editor we need to choose to continue working in a Codespace.

To do this, in the bottom left hand corner of the Status bar click on the blue GitHub remote indicator or use the keyboard shortcut Ctrl + Alt + o

An options box will appear, select Continue Working in a New Codespace

If you have any changed or added uncommitted files then you will be prompted with this option box

We want our changes in our editor to travel into our Codespace, so we choose the option "Yes, Continue with my Working Changes" and select "(User Account Name) GitHub" option.

Select an account to store your working changes in the cloud:
(User Account Name) GitHub
Sign In with Microsoft
Continue without my Working Changes

The next option box will ask to

Select the instance type for your Codespace:
2 core, 8GB Ram, 32GB Storage
4 core, 16GB Ram, 32GB Storage

Select the 2 core option which is fine for the task we are about to carry out.

It then opens a new tab with GitHub Codespaces which will look very much like the GitHub web-editor that we have been using, but if you look in the bottom left hand corner the green button now says Codespaces instead of GitHub.

Now in your codespace lets first stage the extra change we want to add to the last commit using the source control panel which we have already covered, or by using the terminal and typing the command git add filename replace the filename with the name of the file you want to stage, so ours will be git add README.md.

Next we need to type git commit --amend in the terminal this will open a file in the editor that looks like

Commit that Im editing

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Author:    Your name here
# Date:      Wed Mar 26 16:44:31 2025 +0000
#
# On branch main
# Your branch is up to date with 'origin/main'.
#
# Changes to be committed:
#	modified:   README.md
#	modified:   index.html
#

As we want to add the README.md to the current commit we need to remove the # from the start of the line

	modified:   README.md

We can leave the rest of the file the same, then close the file using the X in the top corner of the filename.

Now we have amended the commit we need to push this change back to GitHub. However if we use the green Sync Changes button in the Source control panel we will get an error as we have already pushed the commit back to GitHub. so we need to use the git push --force command again in the terminal as we did before, by typing git push --force and press Enter.

So now if you head to the GitHub repository page and review the commit history you will see the last one has been updated.

We now need to stop the current codespace session along with deleting the codespace storage to stop the billing session. Click here on Closing Codespaces to launch a popup covering the steps you will need.

We have also covered Codespaces within the docs, if you would like to read more about GitHub Codespaces.

When you return to or reopen github.dev web editor you might see the below error

This is because it doesn't know that we have already taken care of the working changes elsewhere.

You have 1 file with uncommitted changes from a previous edit session.

Your repository contents may be out of date until you sync.

You are 1 commit behind

Sync - Don't Show Again - Continue Without Syncing

So we want to Choose Continue Without Syncing

Now open the Source Control Panel Ctrl + Shift + G

Click the three dots menu ... and select Pull

(The Pull operation combines fetch and merge commands to retrieve the latest changes from the remote repository and automatically merges them into your current working branch. This means that your working branch is updated right away with the fetched changes.)

You will then see a popup saying

Pulling in changes may cause conflicts with your uncommitted changes as one of more of those files has changed since you started editing.

Do you want to continue pulling in changes.

Continue - Cancel

We want to Choose Continue

Now your github.dev web editor is using the updated version that we made the amendments to using codespaces.

If you did want to check the changes, Open the explorer panel Ctrl + Shift + E

Click on the index.html, readme.md or whichever files you amended the commit for.

You will see in the TIMELINE the last commit you made plus a compare/diff view of the changes made to the file you selected.

Not verified commit in the commit history on GitHub

In the commit history on GitHub when I commit using github.dev there is a flag saying verified but committing with codespaces does not.

The difference lies in how commits are signed. When you commit using GitHub.dev, GitHub automatically signs your commits with its own GPG key, marking them as "Verified." However, in GitHub Codespaces, GPG verification is disabled by default. This means commits made in Codespaces won't have the "Verified" flag unless you enable GPG verification for your Codespaces.

To enable GPG verification in Codespaces:

1. Go to your GitHub account settings (Not the setting on a repository page).

2. Navigate to the "Codespaces" section under "Code, planning, and automation."

3. Enable GPG verification and select trusted repositories. You can select all your repositories or just the one you are working on.

Once enabled, commits made in GitHub Codespaces will also be signed and marked as "Verified" on GitHub. If you want to find out more about Managing gpg verification in Codespace then I have linked in the relevant GitHub docs page.

Images

Images are not showing on my webpage?

This can be for a number of reasons though usually it's because the image source path is wrong. So firstly check that you have the correct folder name your image is stored in, followed by a / then the name of the image is also typed correctly.

Another reason could be that the image wasn't uploaded correctly.

Can I see my images when in my Web Editor?

Yes VS Code has now released SVG image preview support enabling you to see the actual image instead of its long string of code, and they couldn't have made it easier to do.

To view any SVG that is in your open workspace file list, simply click on its file_name.svg and a preview of the image will open up.

Can I edit SVG's in my Web Editor?

You can still open an image for editing if you need to, by right clicking on the file name and selecting from the pop-up menu Open With...

You will now see another pop-up menu at the top of the editor to Select editor for 'file_name.svg' select and click on the Text Editor option and your SVG will open ready for you to edit.

Is there a shortcut when adding an image src path?

A useful shortcut feature for adding an image to your webpage, or if you are not sure of the file path to add to the <img src="">. Right click on the file name and select from the pop-up menu Copy Relative Path you can now go to your img src and paste in the file path between the " " by clicking between first to select then paste by pressing the Ctrl + V keys <img src="/foldername/file_name.svg">.

CodeSwing

Install CodeSwing

Whilst using github.dev if you want to be able to see the changes you are making in real time alongside your code? Then we suggest installing the VS Code addin CodeSwing. You can find our how to guide here Installing CodeSwing in our docs.

I've closed my preview how do I reopen it?

If you have closed your preview accidently or otherwise you can reopen it again.

First go to the command palette by pressing Ctrl + Shift + P

Then the command we want to run is "CodeSwing: Re-Open Workspace swing"

To do this start typing codeswing re into the command palette when you see the command we want highlighted press Enter

Now you should have your code and the preview enabled again.

I've added another page I want to preview too

I added another page that I would like to preview can I do that?

sure again we need to use the command palette by pressing Ctrl + Shift + P to open it

But this time we are going to use the command "CodeSwing: Open Swing"

So start typing codeswing o into the command palette when you see the command we want highlighted press Enter

We are then prompted to complete the path to the file we want to open, for example lets say we have created an about page in the folder named "about"

We would select the "about" folder from the list provided and press Enter or click the OK button provided.

You should now be able to view the new page.

Can't find an answer?

If you don't find an answer to your issue here by all means use our Contact form, but before you do we often find taking a step back to reread and check the step/s you've just done, can often highlight what may have gone wrong.