A remote is just a folder you can reach.

Two kinds of repository, one connection between them, and nothing else running.

Git has no concept of a server. What people call “the remote” is a saved shortcut: a name like origin pointing at a location Git can read and write. On a hosted setup that location is a URL. In a local setup it is a path — D:\repos\project.git or \\FS01\Engineering\repos\project.git. Push and pull then become file copies between two .git directories.

Working repository vs bare repository

Where the bare repo can live

• Another folder on the same PC — D:\repos\project.git. A real backup only if it is a different physical disk.
• A mapped network drive — S:\repos\project.git. The usual choice for a small team on a file server.
• A UNC path, no drive letter needed — \\FS01\Engineering\repos\project.git.
• Removable media — E:\project.git on a USB drive, for moving work between disconnected machines.

Access control is whatever NTFS says. Anyone who needs to push needs Modify rights on that folder; read-only users can still clone and fetch.

Three shells ship in the box, and four settings decide how much trouble you have later.

Which shell to use

Git accepts C:\Dev\project, C:/Dev/project and /c/Dev/project in most places. This sandbox accepts all three too, so you can practise whichever you use.

First-run configuration

# who you are — stamped into every commit you make
git config --global user.name "Your Name"
git config --global user.email "you@company.com"

# call the first branch main instead of master
git config --global init.defaultBranch main

# line endings: check out CRLF, store LF (the Windows installer default)
git config --global core.autocrlf true

# allow paths longer than 260 characters
git config --global core.longpaths true

# check what you ended up with
git config --global --list

Edit, stage, commit. Everything else in Git is built on this loop.

A file lives in one of three places at any moment: the working tree (what is on disk), the index (what you have staged for the next commit), and history (what is committed). git add moves a change from the first to the second, git commit from the second to the third.

# make a folder and turn it into a repository
cd C:\Dev
mkdir project
cd project
git init

# see where you stand — run this constantly
git status

# stage and record
git add analysis.m
git commit -m "Add signal analysis entry point"

# stage everything that changed
git add .
git commit -m "Add filter helper and notes"

git log --oneline

One command on the shared drive, and you have the equivalent of a hosting service.

# from anywhere — the folder is created for you
git init --bare S:\repos\project.git

# or start it from an existing repo, history and all
git clone --bare C:\Dev\project S:\repos\project.git

Look inside afterwards and you will see HEAD, config, objects\, refs\ — the contents of a .git folder, promoted to the top level. That is the entire difference.

Two ways to start

• Empty bare repo first (git init --bare) — when the project does not exist yet, or you want to push an existing local repo up to it.
• Bare clone (git clone --bare) — when a working repo already has history you want on the share immediately.

Name the path once, then forget it.

# give the path a name
git remote add origin S:\repos\project.git

# confirm — fetch and push URLs are listed separately
git remote -v

# first push: -u remembers the pairing so later you can just type "git push"
git push -u origin main

# from then on
git push

Writing the path

Understanding the rejection you will eventually hit

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'S:/repos/project.git'

This is not a failure of your setup. Someone pushed commits you do not have yet, and Git will not silently drop them. Run git pull, deal with any merge, then push again. Never reach for --force on a shared repository to make this go away — it deletes their work.

How the second machine — or the second person — gets a copy.

# clone into a folder named after the repo, minus the .git
cd C:\Dev
git clone S:\repos\project.git

# or name the folder yourself
git clone S:\repos\project.git project-clone

The clone arrives with origin already configured, full history, and the default branch checked out. Nothing else to set up.

Fetch looks, pull applies. Know which one you are asking for.

If your history has not moved since the last sync, a pull is a fast-forward — your branch pointer just slides along theirs. If you both committed, Git makes a merge commit joining the two lines.

When the same file changed on both sides

CONFLICT (content): Merge conflict in analysis.m
Automatic merge failed; fix conflicts and then commit the result.

Git writes both versions into the file between markers. Open it, decide what the file should say, delete the markers, then:

git add analysis.m
git commit          # Git supplies the merge message

The cheapest way for several people to use one bare repo without colliding.

# create and switch in one step
git switch -c feature/kalman-tuning
# older syntax, same thing
git checkout -b feature/kalman-tuning

# publish it to the share
git push -u origin feature/kalman-tuning

# what exists, locally and on the share
git branch -a

# fold it back into main
git switch main
git pull
git merge feature/kalman-tuning
git push

# clean up
git branch -d feature/kalman-tuning
git push origin --delete feature/kalman-tuning

Every one of these has cost a real team a real afternoon.

Line endings

Windows editors write CRLF; Git prefers to store LF. With core.autocrlf true the conversion happens on the way in and out, and you will see warning: LF will be replaced by CRLF — that is informational, not an error. The durable fix is a .gitattributes file committed to the repo, so the rules travel with the project instead of living in each person's global config:

# .gitattributes — commit this at the repo root
* text=auto

*.m      text eol=crlf
*.txt    text
*.md     text

# binaries: never touch these
*.mat    binary
*.fig    binary
*.slx    binary
*.mdl    binary
*.mlx    binary
*.p      binary
*.mexw64 binary
*.xlsx   binary
*.pdf    binary

Case-insensitive filesystem

Windows treats Analysis.m and analysis.m as the same file; Git does not. Renaming only the case appears to do nothing. Force it through Git so the change is recorded:

git mv -f Analysis.m analysis.m
git commit -m "Normalise filename case"

Path length

Filename too long on checkout means the 260-character limit. Set git config --global core.longpaths true, and keep working folders shallow — C:\Dev\ beats a path nested under your Documents folder.

Files that cannot be merged

Two people editing one .slx or .xlsx produces a conflict Git cannot resolve, because there are no lines to combine. The answer is social, not technical: agree who owns which binary model, or split the work so two people are never in the same file. If you need Git to stop even trying, add *.slx -merge to .gitattributes.

OneDrive, Dropbox and folder sync

Housekeeping on the bare repo

# run occasionally on the share — compacts objects
cd S:\repos\project.git
git gc

# verify integrity
git fsck

Including machines that will never see the same network.

Mirror the bare repo

# make a complete mirror — all branches, all tags
git clone --mirror S:\repos\project.git D:\backup\project.git

# refresh it later
cd D:\backup\project.git
git remote update

Bundles — one file, full history

A bundle is a repository squeezed into a single file you can email, burn, or carry on a USB stick. Clone from it exactly as you would from a folder.

# everything
git bundle create D:\transfer\project.bundle --all

# only what is new since a known commit — much smaller
git bundle create D:\transfer\update.bundle a1b2c3d..main

# on the far side
git clone D:\transfer\project.bundle project
# or into an existing repo
git bundle verify D:\transfer\update.bundle
git pull D:\transfer\update.bundle main

When the share moves

git remote set-url origin \\FS02\Engineering\repos\project.git
git remote -v

Nothing else changes — history is identical in every copy, so repointing the name is the whole migration.

The commands and the error messages, in the order you meet them.

Daily loop

Local-remote specific

Error messages, decoded