← All notesInstall tools

Start here before your first coding lab

Learn GitHub.
Submit with proof.

You will make one tiny project, send it from your computer to GitHub, watch the checks run, read REVISE, repair it, and earn PASS — NAILED IT. That same loop grades every KODE Ń VIBE lab.

S-A-C-PSTATUS · ADD · COMMIT · PUSHAUTOMATIC GRADE
Start Lab Zero

01

Know the six moving parts.

Git saves versions on your computer. GitHub stores a remote copy and runs the grader.

repository

The project and its history.

Your files, commits and branches live together. A folder is not a Git repository until Git is initialized or cloned.

clone

A working copy on your computer.

Cloning downloads the repository and connects it to its GitHub remote, normally named origin.

branch

A named line of work.

Use attempt/lab-zero so your submission is separate from the untouched starter branch.

commit

A meaningful saved checkpoint.

A commit records selected changes with a message. It is not the same as saving a file in your editor.

push

Send commits to GitHub.

Until you push, the remote grader cannot see work that exists only on your computer.

Actions

The automatic grader.

The supplied workflow installs what it needs, runs the tests, and writes PASS or REVISE for that commit.

02

Do Lab Zero once, slowly.

The template starts in REVISE on purpose. Follow every command and read what changes after it.

Explore it, then make your own copy.

Open the starter repository first. After trying the lab, you may Star the original if it genuinely helped you; stars are optional and never affect your grade. Select Use this template → Create a new repository, name it my-kode-n-vibe-lab, and choose visibility deliberately: public for a shareable portfolio, or private for practice within your GitHub Actions allowance.

  1. 1

    Clone your copy.

    Replace YOUR-USERNAME with your GitHub username.

    git clone https://github.com/YOUR-USERNAME/my-kode-n-vibe-lab.git
    cd my-kode-n-vibe-lab
    git remote -v

    Expected: origin points to your repository for fetch and push.

  2. 2

    Create the required branch.

    Every graded branch begins with attempt/.

    git switch -c attempt/lab-zero
    git branch --show-current

    Expected: the terminal prints attempt/lab-zero.

  3. 3

    Install and observe REVISE locally.

    The first failure is deliberate. Read the failed test names; they are your repair list.

    npm install
    npm test

    Expected: one check passes and three fail: learner content, three meaningful goals, and the unfinished CSS.

  4. 4

    Edit the page TODOs.

    Open index.html and styles.css. Type the requested learner details and CSS, keep the HTML semantic, and do not edit files inside test/ or .github/.

    npm test
    git status

    Expected: all four checks pass; Git lists only the files you intentionally changed.

  5. 5

    Stage and inspect.

    git add selects what the next commit will contain. Status verifies that selection.

    git add index.html styles.css
    git status
    git diff --staged

    Expected: the two files appear under “Changes to be committed”; the staged diff contains no secret or surprise file.

  6. 6

    Commit one idea and push it.

    The message says what the checkpoint accomplishes.

    git commit -m "Complete Lab Zero profile"
    git push -u origin attempt/lab-zero

    Expected: GitHub receives the branch and Git reports that it now tracks origin/attempt/lab-zero.

  7. 7

    Read the real grade.

    Open your repository → ActionsAutomated project grade → newest run. Open the summary and any failed check.

    git rev-parse HEAD

    Expected: the SHA printed locally begins with the same characters shown in the successful Actions run. Keep that SHA and the run URL as your submission proof.

  8. 8

    Record the passing evidence.

    Only after Actions passes, fill in SUBMISSION.md. It should point to the passing code commit from step 7, not to the later evidence commit.

    git add SUBMISSION.md
    git diff --staged
    git commit -m "Document Lab Zero submission evidence"
    git push

    Expected: the template, branch, passing code SHA, Actions run URL and your explain-back are recorded without any password or token.

03

Rehearse the submission record.

This practice checker does not contact GitHub or award a real grade. It teaches you what complete evidence looks like; the repository's GitHub Action is the real grader.

Before submitting

04

Use the same loop for every lab.

Each public starter carries its brief, local command and automatic grading workflow.

Build

Type, run, and explain.

Work on an attempt/... branch. Run the exact command in MASTERY.md and repair local failures before pushing.

Never delete or weaken a supplied check.
Result

PASS or REVISE.

PASS means every required automated check passed together. REVISE means at least one check failed; its log shows where to look.

No average, points or partial pass.
Retry

Fix, then push again.

Make the smallest justified correction, test locally, commit, and push. GitHub grades the new commit automatically.

Stop at PASS — NAILED IT.

Your final evidence

One result tied to one revision.

  • Your repository URL and attempt/... branch.
  • The exact commit SHA that earned PASS.
  • A link to that successful Actions run.
  • Your brief explain-back answers from SUBMISSION.md.
  • One honest limitation or next improvement.

05

Fast feedback, used honestly.

Automation catches repeatable requirements quickly. Browser testing, real users and your explanation cover what a test cannot see.

Official guidance used for this workflow
Choose a project track