Skip to content
gilltrish.dev

The terminal is just a text box that does what you say

Beginner7 min read

The 30-second version

The terminal is a text box that does what you type. Git is a save-points system for code. You need about 12 commands for a normal day, in this order: get the code, make a branch, save, share, switch back.

On this page

The first time I opened a terminal, it was because I had to use git. Nobody had told me what the terminal actually was. It was just a black box with a blinking cursor, and I was supposed to type things into it.

Everything about it scared me. There was no undo button. There were no menus to show me what was possible. Every command felt like a gamble: what if I typed one wrong word and deleted everything? It felt like typing into a void and waiting to see what came back at me.

It turns out most of that fear was a lack of explanation, not actual danger. Once someone tells you what the box is and which handful of commands you’ll really use, it stops being a void and becomes a tool. That’s what this post is: the explanation I wish I’d had.

What's the terminal, and what's git?

  • Terminal: instead of clicking folders, you type where to go and what to do.
  • Git: a save-points system (like checkpoints in a video game). Every commit is a checkpoint you can return to.
  • GitHub/Bitbucket/etc.: the shared shelf where everyone's checkpoints live. Your computer has a copy; the shelf has the team copy.

Where your code lives

  1. Your files
  2. git addstaged ("in the box, not sealed")
  3. git commitsaved on your computer
  4. git pushsends it to the remote (GitHub)
  5. git pull/git fetchgets it from the remote (GitHub)

Step 1:Getting around before you start

I’m on Windows, so I use Git Bash or the terminal built into VS Code. Both understand these commands exactly as written.

Finding your way around

None of these four commands delete or change anything, so you can’t hurt yourself with them. Run them as often as you like.

  • pwd: “where am I?” Prints the full path of the folder you’re currently in. The terminal is always “standing” in some folder, and this is how you check which one. If you ever feel lost, start here.
  • mkdir practice: makes a new folder called practice. I suggest doing this first, so you have a sandbox where nothing you try can touch your real files. (If you want spaces in the name, wrap it in quotes: mkdir "my project". Most people just use dashes.)
  • cd practice: moves you into that folder. A few variations you’ll use constantly:
    • cd .. goes up one level, to the folder that contains this one.
    • cd ~ jumps straight to your home folder, no matter where you are.
    • Press Tab while typing a folder name and the terminal fills in the rest. This saves typing and typos.
  • ls -la: lists everything in the current folder, including hidden files. -l shows details (size, date modified), -a shows all files. Hidden files start with a dot, like .git (where git keeps its save points) and .env (where projects often keep passwords and keys, so never share it). A plain ls won’t show them, which is why the flags matter.

A few words you'll see

  • Repository (repo): the project folder, plus every save point git has ever recorded for it.
  • The shelf: the shared copy of the project online (GitHub, GitLab, etc.). Git calls it the remote, and the default remote is named origin. When you see origin in a command, read it as “the shelf.”
  • Branch: your own parallel copy of the code. You can change it freely without touching anyone else’s work.

Step 2:The everyday git loop

  1. git clone <url>: copy the project from the shelf to your computer. You only do this once per project. It creates a new folder with the project inside, so cd into it afterwards. (You’ll find the URL on the repo’s page under a green Code button.)
  2. git checkout main (or staging), then git pull origin main: switch to the team’s main branch and download everyone’s latest changes. Always start here, so you’re building on the newest code instead of yesterday’s.
    • eli5, git fetch vs git pull: fetch = check the mail. Pull = check the mail and open it into your files. Fetch is the cautious option if you want to see what changed before it lands in your folder.
    • Heads up: many teams name a branch staging, but git also uses the phrase “staging area” for something unrelated (the box in step 5). If a tutorial elsewhere says “staging,” check which one it means.
  3. git checkout -b feature-branch: make your own branch and switch to it in one step (-b means “create a new branch”). Now nothing you do touches the team copy until you choose to share it.
    • You may also see git switch -c feature-branch. It does the same thing; switch is the newer command.
  4. Make your changes, then run git status: the “what did I just do?” command. It lists which files you changed, which are new, and which are already in the box. Like pwd and ls, it changes nothing, so run it any time you’re unsure. You’ll use it more than any other command.
  5. git add .: put every changed file in the box. The . means “everything in this folder and below.”
    • gotcha: . also grabs files you didn’t mean to include, like debug logs or your .env with passwords in it. Check git status first. To add just one file, use git add path/to/file.
  6. git commit -m "fix: correct cart total rounding": seal the box and put a label on it. This creates a save point you can always come back to. -m means “here’s the message.”
    • Prefixes: fix: for a bug fix, feat: for a new feature, chore: for maintenance (updates, config, cleanup). This style is called Conventional Commits.
    • tip: use whatever your company’s conventions are. We use ticket numbers and descriptions most of the time.
    • Good vs bad messages. Write for the person reading the history six months from now, which is often you. Good: fix: stop double-charging on refresh. Bad: fix stuff
  7. git push -u origin feature-branch: send your branch to the shelf for the first time. -u tells git to remember where this branch goes, so after that you can just type git push. Until you push, your work exists only on your computer.
  8. Open a pull request (PR). A PR asks your team to review your branch and merge it into the main one. That’s a whole topic of its own; GitHub’s guide covers it: Creating a pull request.
  9. git checkout main (or staging), then git pull: go back to the team copy and get the latest, including your merged work once it’s approved. You’re back at step 2, ready for the next task.

Remember the “no undo button” fear? This is the undo button.

Step 6 from above:
Every commit is a save point, and git keeps all of them. If you break something later, you can always get back to the last one that worked. Run git log --oneline to see your save points as a list, newest first, each with its label.

The catch: git can only rescue what you’ve committed. Changes you haven’t committed yet aren’t saved anywhere, so commit early and often. Small commits are cheap, and every one is another safety net.

Here’s a Full Day example

Git Bash

    
        
        
        Every morning: start from the newest team copy
      
        
        
        cd ~/projects/shop-site
      
        
        
        git checkout staging
      
        
        
        Switched to branch 'staging'
Your branch is up to date with 'origin/staging'.
      
        
        
        git pull origin staging
      
        
        
        From https://github.com/your-team/shop-site
 * branch            staging    -> FETCH_HEAD
Updating 3f2a91c..8d4e7b2
Fast-forward
 src/checkout/discount.ts | 12 ++++++++++++
 1 file changed, 12 insertions(+)
      
        
        
        Make your own branch
      
        
        
        git checkout -b fix/cart-rounding
      
        
        
        Switched to a new branch 'fix/cart-rounding'
      
        
        
        ...edit files in your editor, then check what changed
      
        
        
        git status
      
        
        
        On branch fix/cart-rounding
Changes not staged for commit:
	modified:   src/cart/total.ts

Untracked files:
	debug.log
      
        
        
        debug.log snuck in. Add only the file you meant to change
      
        
        
        git add src/cart/total.ts
      
        
        
        git status
      
        
        
        On branch fix/cart-rounding
Changes to be committed:
	modified:   src/cart/total.ts

Untracked files:
	debug.log
      
        
        
        git commit -m "fix: correct cart total rounding"
      
        
        
        [fix/cart-rounding 1a2b3c4] fix: correct cart total rounding
 1 file changed, 3 insertions(+), 1 deletion(-)
      
        
        
        Your save points, newest first
      
        
        
        git log --oneline
      
        
        
        1a2b3c4 (HEAD -> fix/cart-rounding) fix: correct cart total rounding
8d4e7b2 (origin/staging, staging) feat: add discount code field to checkout
3f2a91c chore: upgrade payment library to v4
      
        
        
        git push -u origin fix/cart-rounding
      
        
        
        remote: Create a pull request for 'fix/cart-rounding' on GitHub by visiting:
remote:      https://github.com/your-team/shop-site/pull/new/fix/cart-rounding
To https://github.com/your-team/shop-site.git
 * [new branch]      fix/cart-rounding -> fix/cart-rounding
branch 'fix/cart-rounding' set up to track 'origin/fix/cart-rounding'.
      
        
        
        Open the pull request, get it reviewed and merged. Then head home:
      
        
        
        git checkout staging
      
        
        
        Switched to branch 'staging'
Your branch is up to date with 'origin/staging'.
      
        
        
        git pull
      
        
        
        Updating 8d4e7b2..5e6f7a8
Fast-forward
 src/cart/total.ts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
      
        
        
        Back where you started, ready for the next task