Git & GitLab A Complete Beginner’s Guide For Financial Services Professionals
Prepared by Derek Barnes
Scarborough Road LLC
February 2026
This guide assumes zero prior experience with Git or version control. Every step is spelled out completely, including what to type and what you’ll see on screen.
Part 1: Understanding the Basics
What Is Git?
Git is a version control system. Think of it like “Track Changes” in Word, but for any type of file, and it saves every version forever. Instead of having files named things like “SPX_pricing_v3_FINAL_really_final.xlsx,” Git keeps one file and remembers every change you’ve ever made to it.
Git runs on your local computer. It’s a program you install, and it watches a folder (called a “repository”) for changes.
What Is GitLab?
GitLab is a website that stores a backup copy of your Git repositories in the cloud. Think of it like OneDrive or Dropbox, but purpose-built for code and versioned files. Your GitLab account at gitlab.com/dashboard/home is where your repositories will live online.
The relationship is simple: Git is the engine on your computer. GitLab is the cloud storage where you send copies for safekeeping.
Key Vocabulary
There are only a handful of terms you need to know:
Think of it this way:
A commit is like a photograph of all your files at one moment. Each photograph gets a caption (your commit message). GitLab is the photo album in the cloud where all your photographs are stored safely.
Part 2: One-Time Setup
You only need to do these steps once. After this, you’re set up permanently.
Step 2.1: Install Git on Your Computer
For Windows:
For Mac:
git --version
Step 2.2: Open Your Terminal
From now on, you’ll type Git commands in a “terminal” window. Here’s how to open one:
Windows: Press the Windows key, type “cmd”, and click “Command Prompt.” Alternatively, you can right-click in any folder and select “Open Git Bash here” (this was installed with Git).
Mac: Press Cmd + Space, type “Terminal”, and press Enter.
Pro tip:
Git Bash (Windows) is slightly nicer than Command Prompt for Git work. It comes free with your Git installation and uses the same commands shown in this guide.
Step 2.3: Tell Git Who You Are
Git stamps every save with your name and email. Run these two commands (type each one and press Enter):
git config --global user.name "Derek"
git config --global user.email "your-email@example.com"
Use the same email address you used to sign up for GitLab. You only need to do this once.
Step 2.4: Create an SSH Key (So You Don’t Need a Password Every Time)
This creates a secure connection between your computer and GitLab so you don’t have to type your password every time you push.
Step 1: Generate the key
ssh-keygen -t ed25519 -C "your-email@example.com"
When it asks “Enter file in which to save the key,” just press Enter to accept the default.
When it asks for a passphrase, just press Enter twice (no passphrase is fine for personal use).
Step 2: Copy the key to your clipboard
Windows:
type %USERPROFILE%\.ssh\id_ed25519.pub | clip
Mac:
cat ~/.ssh/id_ed25519.pub | pbcopy
Step 3: Add the key to GitLab
Don’t skip this step!
Without the SSH key, you’ll be asked for your username and password every single time you push. The SSH key is a one-time setup that eliminates that friction permanently.
Part 3: Creating Your First Repository
Let’s create a repository for some SQL scripts. You’ll do this on GitLab’s website first, then connect it to a folder on your computer.
Step 3.1: Create the Repository on GitLab
You now have an empty repository on GitLab. The URL will look like gitlab.com/your-username/sql-scripts.
Step 3.2: Clone the Repository to Your Computer
Now you need a local copy. This is called “cloning.”
cd ~
mkdir projects
cd projects
git clone git@gitlab.com:your-username/sql-scripts.git
(Paste the URL you copied from GitLab instead of the example above.)
Recommended by LinkedIn
cd sql-scripts
You now have a folder on your computer called “sql-scripts” that’s connected to GitLab. Anything you put in this folder can be tracked and backed up.
Part 4: Your Daily Workflow
This is the part you’ll repeat every day. It’s only three commands.
The Three-Command Rhythm
Every time you’ve made changes you want to save, you’ll do this:
A Real Example
Let’s say you just wrote a new SQL query for your options pricing database. Here’s exactly what you’d do:
Step 1: Save your SQL file into the repository folder
Save (or copy) your file into the sql-scripts folder on your computer. Let’s say it’s called spx_greeks_query.sql.
Step 2: Open your terminal and navigate to the folder
cd ~/projects/sql-scripts
Step 3: Check what Git sees (optional but helpful)
git status
Git will show you spx_greeks_query.sql in red, meaning it’s a new/changed file that hasn’t been staged yet.
Step 4: Stage, commit, and push
git add .
git commit -m "Added SPX Greeks calculation query"
git push
That’s it. Your file is now version-controlled locally AND backed up to GitLab. If you go to gitlab.com and navigate to your repository, you’ll see the file there.
Write good commit messages:
Your future self will thank you. Instead of “updated stuff,” write something like “Fixed BSM dividend yield handling for quarterly expiries” or “Added cap rate dual-approach grid for audit compliance.” Think of it as a one-line changelog entry.
Part 5: Useful Extras
Seeing Your History
To see a list of all your past commits (saves):
git log --oneline
This shows a compact list like:
a3f2b1c Added cap rate analysis grid
9e1d4a7 Fixed BSM Greeks calculation
2c8f3e0 Initial SQL scripts
Each line is one commit. The letters/numbers on the left are a unique ID for that snapshot.
Going Back to See an Old Version
To see what a file looked like at an older commit, the easiest way is to use GitLab’s web interface:
Checking What’s Changed Since Your Last Commit
If you want to see what you’ve changed before committing:
git diff
This shows a line-by-line comparison. Lines with a “+” were added, lines with a “−” were removed.
Undoing Changes Before Committing
If you’ve made changes to a file but want to throw them away and go back to the last committed version:
git checkout -- filename.sql
Be careful:
This permanently discards your uncommitted changes to that file. There’s no undo for this. If you’re unsure, commit what you have first — you can always go back.
Part 6: Suggested Repository Organization
Based on my work, I’m creating three repositories to start:
Organizing Files Within a Repository
Inside each repository, use subfolders to keep things tidy. For example, your sql-scripts repo might look like this:
sql-scripts/
├── pricing/
│ ├── bsm_european.sql
│ ├── forward_start_pricing.sql
│ └── greeks_calculation.sql
├── reporting/
│ ├── monthly_returns.sql
│ └── portfolio_benchmark.sql
├── schema/
│ ├── security_master_ddl.sql
│ └── time_series_tables.sql
└── README.md
What’s a README.md?
It’s a plain text file that describes the project. GitLab displays it automatically on the project’s home page. Write a few sentences about what’s in the repo, and it becomes a helpful landing page when you (or anyone you share it with) visits the project.
Part 7: A Note About Excel Files
Git works brilliantly for text files like .sql, .md, .txt, .py, and .csv. For these, it can show you exactly which lines changed between versions.
Excel files (.xlsx, .xlsm) are a different story. Git CAN track them and WILL save every version, so you get full version history and backup. However, Git can’t show you a line-by-line comparison between two versions of an Excel file because Excel files are binary (not plain text).
This is still far better than your current situation. Instead of “model_v3_final_FINAL.xlsx” scattered across a network drive, you’ll have one file with a clean history of every version.
Best practice for Excel version control:
When you commit an Excel file, write an extra-detailed commit message describing what changed. For example: “Updated BSM model to handle quarterly dividend adjustments, added new Greeks output tab, fixed vol surface interpolation for deep OTM strikes.” This compensates for Git not being able to show you the diff.
Part 8: Quick Reference Card
Print this page and keep it near your desk until the commands become second nature.
Your Daily Routine (Tape This to Your Monitor)
That’s the whole guide. You now know everything I know to stop losing files and start keeping a clean version history. The key is just to build the habit: every time you finish a meaningful chunk of work, do the three-command routine. Within a week it’ll be muscle memory.
If you run into trouble, paste the error message into your LLM chat and you’ll figure it out together.