← Learning pathLesson 01 / 07
LESSON 01 · THE FOUNDATION

Give your work
a home.

Building an app or website? Give it a home with a history you can review. For everyday chat and document tasks, you can come back to Git later.

When an idea becomes something real

At first, AI often feels like a better search box. Ask a question. Get an answer. Move on. But eventually you will want to make something useful: a small tool, a classroom resource, an automated report, a website, or a workflow that gives you an hour back every week.

Start with an approved folder or document system for ordinary writing. Git is especially useful for code and plain-text project files; it records changes you can compare and revisit. GitHub is where I choose to keep a remote copy of those projects.

Git and GitHub, without the mystery

Source control keeps a history of changes to a project. Git records that history on your computer. GitHub stores a remote copy online, where you can share it or pick up the work from another computer. A repository, often shortened to repo, is the project and its recorded history.

YOUR COMPUTER
Working filesThe things you are changing now
stage ↓
Selected changesYour proposed next save
commit ↓
Local historyNamed snapshots of your work
push →← fetchpull = fetch + bring changes into your project
GITHUB
Remote historyCommits that have been pushed

Stage

Choose the specific changes that belong in your next saved version.

Commit

Save a named snapshot in the project's local history.

Push

Send your saved snapshots to GitHub.

Fetch & pull

Fetch downloads remote history without changing your working files. Pull fetches and then integrates those changes into your current branch; conflicting edits may need your help.

A SMALL EXAMPLE

Improve a small project’s welcome note.

You ask the assistant to clarify a plain-text welcome note. Review the changed file, stage that edit, and commit it as “Clarify welcome instructions.” Push when you want that version on GitHub. Simply saving the file on your computer does not upload it.

A branch gives you a separate line of work to try an idea. You can review it before merging it into the main version. A private repository still needs care: keep passwords, API keys, and student or customer records out of it.

Where the LLM comes in

An LLM is a large language model: the AI behind many chat and coding tools. A coding assistant with permission to use your terminal can handle much of this setup. It can initialize a project, create a private repository, add ignore rules, stage files, create a commit, and push it to GitHub through GitHub CLI.

A GOOD FIRST REQUEST

“First check the project folder and explain whether Git and GitHub CLI are available. Propose a private repository, ignore rules, and the exact files for an initial commit. Stop and wait for my approval. After I approve that plan and sign in myself, help me create the repository, commit the approved files, and push. Never print credentials or include secrets.”

You still own the important decisions

  1. Is this project public or private?
  2. Which files are safe to include?
  3. Does the summary actually match what changed?
  4. Is it ready to share or deploy?
  5. Did the final result work?

The AI can be the detailed knowledge worker. You remain the person responsible for the purpose, the boundaries, and the final call.

Read GitHub’s guide to fetch, pull, and remote changes →
TRY IT · FICTIONAL PRACTICE DATA

Know where the saved version lives

Use a made-up text file, not personal or school records. You can also do this as a paper exercise before installing Git.

Your starting information

File: welcome.txt
First version: Welcome to our project.
Revised version: Welcome. Start with one small task.
SAMPLE + PROMPT, READY TO PASTE

Walk me through a local Git practice using only welcome.txt and the two versions supplied above. Show the change, explain staging, and stop before making a commit. After I approve the selected change, save a local commit. Do not create a GitHub repository or push anything. At the end, explain exactly where my working file and saved history live.

Check the expected result

Illustrative answer · check your own result first

  1. The changed working file is on your computer. Staging selects its change for a commit; it does not save a snapshot by itself.
  2. A commit adds the selected change to local history. There is still no GitHub copy from this activity.
  3. If you later choose to push, review the files and repository visibility first. A private repository is not a place for passwords or personal records.

You are ready to move on when…

  • I can explain the difference between saving a file, committing, and pushing.
  • I know whether a copy of this project exists on GitHub.
NEXT UP

Put your project home to use.

Continue the builder route with a small local app. If you prefer everyday AI tasks, begin with choosing a useful job.

Builder route: make a small app →Everyday route: choose a task →Return to the learning path ↗