Git from zero

Git is the tool that remembers every version of your code, and it's what makes "push to deploy" possible on Falix. Before you connect anything to a server, it helps to understand Git on your own machine: what a repository is, and the handful of actions you'll repeat forever. This guide teaches exactly that — both with VS Code's buttons and on the command line — and hands you off to the Falix side at the end.

What a repository actually is

A repository (repo) is just a normal project folder with a memory. Inside it, Git keeps a hidden .git folder that stores every snapshot you've ever saved. Your files look and behave like any other files; the .git folder is the difference between "a folder" and "a folder that remembers".

Each saved snapshot is a commit — a labelled point in time you can always return to. A commit isn't a backup of one file; it's the state of the whole project at that moment, with a short message explaining what changed.

🎯 The .git mental model: The .git folder is the repository's history. Copy your project without it and you get the current files with no memory. Delete .git and your files are untouched, but every past version is gone. You almost never open .git by hand — Git manages it for you — but knowing it's one folder demystifies the whole thing.

The four verbs you'll use forever

Nearly all day-to-day Git is four actions:

There's one extra idea between editing and committing: staging. You edit files, choose which changes to include (stage them), then commit. Most of the time you stage everything and commit — but the two-step exists so you can commit part of your work when you want to.

Do it in VS Code (the buttons)

VS Code has Git built into its Source Control panel — the branch-shaped icon in the left sidebar. Once Git is installed on your computer (see the download link at the end), the loop is:

1. Open your project folder in VS Code (File → Open Folder). If it isn't a repo yet, the Source Control panel shows an Initialize Repository button — click it to create the .git folder.
2. Edit some files. Changed files appear in the Source Control panel.
3. Stage a change with the + next to it (or stage all with the + on the "Changes" header).
4. Type a commit message in the box at the top and press the Commit check-mark.
5. Publish / Push with the Sync Changes button (or Publish Branch the first time) to send it to GitHub.

That's the entire cycle: edit, stage, commit, push. You'll do it hundreds of times.

Do it on the command line (the same thing, typed)

The buttons run these commands under the hood. Knowing them means you're never stuck, and the CLI is often faster:

# Start a brand-new repo in the current folder
git init

# ...or copy an existing one from GitHub
git clone https://github.com/you/my-project.git

# One-time identity setup (so commits are labelled with your name)
git config --global user.name "Your Name"
git config --global user.email "[email protected]"

# The everyday loop
git add .                       # stage all your changes
git commit -m "Add health route"   # save a snapshot with a message
git push                        # send it up to GitHub

To grab changes from the host later, git pull. To see what's staged or changed, git status — run it any time you're unsure where things stand.

💡 Tip: Write commit messages that finish the sentence "This commit will…" — "Add health route", "Fix crash on empty input". Future-you reading the history will thank present-you.

Connect to GitHub

Git works entirely offline, but to push you need a home for the code online. Create a free repository on GitHub (or GitLab / Bitbucket), then either clone it down first, or add it to an existing local repo:

git remote add origin https://github.com/you/my-project.git
git branch -M main
git push -u origin main

After the first push -u, plain git push and git pull know where to go.

Keep secrets and junk out of the repo

Some files should never be committed: your .env with tokens, and generated folders like node_modules or a Python venv. List them in a .gitignore file (one path per line) and Git will pretend they aren't there. This matters double on Falix, where secrets live on the server, not in Git — see Keep secrets out of Git.

Verify it works

Push a commit, then open your repository page on GitHub in a browser. Your files and your commit message should be listed there. Change a line, commit, push again, refresh — the new commit appears at the top of the history. That round trip is Git working.

Troubleshooting

• "Author identity unknown" — set your name and email with the two git config --global commands above, then commit again.
• "nothing to commit, working tree clean" — you haven't changed anything since the last commit, or your changes are all ignored by .gitignore.
• Push asks for a password and rejects it — GitHub no longer accepts your account password over HTTPS. Use a personal access token as the password, or sign in through VS Code's built-in GitHub login, which handles this for you.
• .env ended up on GitHub — add it to .gitignore, remove it from the repo, and rotate any secret that was in it.

Next steps

• Branches without fear — work on features without breaking what's live
• Deploy from Git — now point a repo at a Falix server
• Going deeper into Git itself: the official book and reference at git-scm.com, and VS Code's source-control guide at code.visualstudio.com