GuidesOnly show guides for your app
GuidesGuidesWhat a repository actually is, and how to clone, commit and push it — with VS Code's buttons and with the command line — so you're ready to point it at a Falix server.
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.
| At a glance | |
|---|---|
| You need | A computer, and a free account on GitHub (or GitLab / Bitbucket) |
| Plan | Any — this is your machine, not a server |
| Time | Twenty minutes |
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
.gitmental model: The.gitfolder is the repository's history. Copy your project without it and you get the current files with no memory. Delete.gitand your files are untouched, but every past version is gone. You almost never open.gitby hand — Git manages it for you — but knowing it's one folder demystifies the whole thing.
Nearly all day-to-day Git is four actions:
| Verb | What it does |
|---|---|
| clone | Copy a repo from a host (like GitHub) down to your machine, history and all |
| commit | Save a snapshot of your current changes, with a message |
| push | Send your new commits up to the host so they're stored and shareable |
| pull | Bring down commits others (or another machine) pushed |
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.
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:
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.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.
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.
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.
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.
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.
git config --global commands above, then commit again..gitignore..env ended up on GitHub — add it to .gitignore, remove it from the repo, and rotate any secret that was in it.