2. Install Git and create your first repository

Description

By the end of this lesson you will have Git installed and configured on your machine, you will know exactly what a repository is —and why it's just a folder with a hidden folder inside— you'll be able to name the three zones where your work lives once Git is keeping its history (the working tree, the staging area, and the history), and you will have turned the cumbre-automations folder, with your order-triage.json workflow inside, into your first Git repository. All with one command per step and an explanation of what the terminal answered each time.

This matters because it's the foundation for everything that follows. You can't make a commit without a repository, or read a diff, or work in branches: everything rests on the folder you're going to initialize today. And since this is the first time you're really talking to Git, this lesson goes slowly: every command comes with the exact signal confirming it worked, and with the typical stumble a beginner makes, so you can recognize it before falling into it.

Connection to the module: lesson 1 was the map; this is the first step on the ground. We're not going to save anything yet —your first commit is lesson 3— we're going to prepare the machine and the repository so you can do that. Once cumbre-automations is a repository, lesson 3 takes the first photo, 4 compares photos, 5 opens branches, and so on to the end. If anything from today isn't solid, the rest wobbles, so it's worth taking it slowly.

Installing Git on your machine

Let's start with the basics. Git is a program you have to have installed, just like you installed n8n or your browser. You might already have it —a lot of systems come with it, or other tools installed it— so before installing anything, let's ask the machine if it's already there.

Open a terminal. If you've never opened one before:

• On Windows, look in the start menu for the Git Bash app (if you already have Git) or PowerShell. For this guide I'm going to recommend Git Bash once you install Git, because it behaves the same as Mac and Linux terminals, so the commands are identical for everyone.
• On macOS, open the Terminal app (search for it with Spotlight, the magnifying glass at the top right, typing "Terminal").
• On Linux, you already know where your terminal is; open it.

With the terminal open, type this and press Enter:

git --version

What to expect. If Git is already installed, the terminal answers with something like:

git version 2.45.2

The exact number is almost certainly going to be different on your machine, and it doesn't matter: any recent 2.x version is more than enough for the whole module. As of this guide's writing —July 2026— the 2.x line is current, and new versions come out every few months. If you see a number, micro-victory: you already have Git, skip straight to the configuration section.

If instead it answers with something like command not found —or, on Windows without Git, a window offering to install it— then you need to install it. Each system has its own path.

Windows

The most direct way is to download the official installer from git-scm.com/download/win. You get an .exe file, run it, and it's going to ask you quite a few questions during installation. It's normal for there to be many and for them to sound technical; for what we're doing here, you can leave almost all of them at their default value and click "Next." The Git for Windows installer ships with sensible defaults.

There's one screen worth actually looking at: the one asking for the default text editor. It comes with an editor called Vim preselected, which is powerful but very uncomfortable if you don't know it —it's notorious for people not even knowing how to exit it. If an editor you already know shows up in the list, like Visual Studio Code or Notepad, choose it. If you don't recognize any of them, don't worry: in this guide we're almost never going to need that editor, and when we do, I'll tell you how to exit it.

When it's done, close the terminal, open Git Bash (which the installer just added to your start menu), and type git --version again. Now it should answer with a number.

macOS

On Mac, the cleanest way is through Homebrew, a command-line package manager you might already have from other guides in the ecosystem (we use it in the Python installation guide). If you have Homebrew, type:

brew install git

You're going to see several installation lines scroll by on screen. That's fine, it's expected; let it finish.

If you don't have Homebrew, there's a shortcut: type git --version again, and on many versions of macOS a window shows up offering to install the "Command Line Tools," which include Git. Accept, wait for it to finish —it can take several minutes and download quite a bit— and you're done. Either path leaves you with Git working.

Linux

Use your distribution's package manager. On Debian- or Ubuntu-based ones:

sudo apt update && sudo apt install git

On Fedora:

sudo dnf install git

It's going to ask for your password (the sudo is for installing at the system level; it's normal for nothing to show up while you type it) and it's going to confirm the installation. When it's done, git --version answers with the number.

Every computer is its own world. If your installation behaves differently from what I'm describing —a weird message, a screen I don't mention, an error that isn't here— it's not that you did something wrong: it's that there are hundreds of combinations of operating system and version. Copy the error message, paste it into whatever AI chat you use or into your search engine, and generally the answer shows up in the first result. Learning to solve these bumps on your own is part of becoming self-sufficient, and you're going to do it more than once in your career.

Configuring Git: your name so commits have an author

Before creating the first repository, you need to tell Git who you are. Remember from lesson 1 that every saved version —every commit— records who made it. Git needs to know your name and email to be able to put them in that signature. This gets configured once per machine, not once per project.

Type these two commands, replacing the name and email with your own:

# Your name, exactly as you want it to appear signing every version.
git config --global user.name "Ana Torres"

# Your email. Use the same one you'll open GitHub with in lesson 6.
git config --global user.email "ana.torres@cumbre.example"

What to expect. Nothing. Neither command answers with text, and that's going to happen to you a lot with Git: a lot of commands that work fine say nothing. In the terminal world, silence usually means success. If a command finishes without complaining, it did its job. Git only speaks up when something goes wrong.

Let's break that command down piece by piece, because you're going to see this shape many times:

• git config is the "adjust a Git setting" command.
• --global means "this setting applies to all my folders on this machine, not just one project." Without --global, the setting would only apply inside the repository you're standing in. Since your name doesn't change between projects, you set it globally once and forget about it.
• user.name is the name of the setting you're fixing. There are dozens of settings; this one stores your author name.
• What goes between quotes is the value. Quotes matter when the value has spaces, like a first and last name.

There's a third setting worth doing now, because it saves you a confusion later. When Git creates a new repository, the first line of work —the main branch— needs a name. It used to be called master, and today the industry and GitHub standard is main. So your repository is born with the modern name, type:

# Make new repositories' main branch be called "main".
git config --global init.defaultBranch main

Branches are lesson 5's topic; for now just hold on to the fact that you just asked for the main branch to be called main, which is what GitHub expects when we get to lesson 6.

To confirm everything got saved, ask Git to show you its configuration:

git config --list

What to expect. A list of key=value lines. Among them, your three settings should appear:

user.name=Ana Torres
user.email=ana.torres@cumbre.example
init.defaultbranch=main

There might be more lines around them —default Git settings or ones the installer set— ignore them; what matters is seeing your name, your email, and the branch name. Perfect: Git now knows who you are. That name is going to sign every photo you take from here on.

What a repository actually is

Now the lesson's central question. You're going to hear "repository" hundreds of times; it's worth having a precise image and not a vague one.

A repository —or "repo," as everyone calls it— is an ordinary folder on your computer that Git is keeping the history for. That's it. It's not a special kind of folder, it doesn't live on a server, it doesn't require internet. It's your regular folder, with your regular files, plus a hidden folder inside called .git where Git stores the entire history.

Think of it this way: a normal folder is a room with your stuff in it. A repository is that same room with your same stuff, but with a security camera in the corner taking pictures of how the room looked at every important moment. The room doesn't change; what gets added is the memory of its states. That camera and its photo archive is the .git folder.

When you turn a folder into a repository —which you're about to do with git init— nothing happens to your files. order-triage.json stays right there, identical. The only thing that shows up is that hidden .git folder. And later, when you want to "stop versioning" a folder, all you have to do is delete the .git and it goes back to being a normal folder, with your files intact. History is a layer that gets put on and taken off on top of your files, without touching them.

The three zones where your work lives

Here comes the concept that confuses people the most at first and that, once it clicks, clicks for good. When Git is keeping a folder's history, your work exists in three different zones at the same time. They're not three folders; they're three states a change passes through.

Zone 1 — The working tree. It's what you see in your folder: your files exactly as they are right now. When you open order-triage.json and edit it, you're touching the working tree. It's your workbench: what you're holding in your hands right this second.

Zone 2 — The staging area. It's an in-between zone where you choose which changes are going into your next photo, before taking it. It's all of lesson 3, so for now just keep it on the map: it's the step between "I changed something" and "I saved that change in the history."

Zone 3 — The history (repository). It's the collection of photos already taken —the commits— living inside the .git folder. Once a photo is here, it's permanent and you can go back to it.

The analogy that works best is taking a group photo. The working tree is the whole room, with everyone moving around. The staging area is when you say "you three, stand here for the photo" —you choose who's in it. And the history is the photo already taken and saved in the album. People stay in the room after the photo (the working tree is still alive), but the photo captured exactly whoever you put in the frame at that moment.

This journey through three zones —work → staging → history— is Git's heartbeat. Everything you do from here on is moving changes through those three zones. Today we just built the stage; the movement starts in lesson 3.

Three commands so you don't get lost in the terminal

To create the repository you need to be standing inside the right folder, and for that you need three navigation commands that aren't part of Git but that you're going to use every session. Worth having them clear now so the terminal stops being a maze.

• pwd ("print working directory") tells you which folder you're standing in right now. It's your "where am I?" It returns a path like /Users/ana.
• ls ("list") shows you what's in the current folder: files and subfolders. It's your "what's here?"
• cd ("change directory") moves you to another folder. cd cumbre-automations goes into that subfolder; cd .. goes up one level (the two dots mean "the folder above"); cd alone takes you back to your home folder.

Think of it like moving around a file explorer, but by typing instead of double-clicking. cd is the double-click to enter a folder; cd .. is the "back" button; ls is looking at the contents; pwd is reading the address bar to know where you are. Exactly the same thing you already do with the mouse, in different words.

The reflex I want you to adopt: before any Git command, run pwd to confirm where you are. Running git init in the wrong folder is this lesson's most common practical mistake, and pwd prevents it in two seconds.

Creating the repository: git init on cumbre-automations

The moment has arrived. We're going to turn Cumbre's folder into a repository.

Worked example: from ordinary folder to repository

Step 1 — Have the folder with your workflow ready. You need a folder called cumbre-automations with your order-triage.json file inside it (the one you exported in Module 1). If you don't have it yet, create it. You can do it with your system's file explorer, right-clicking "New folder" and dragging the JSON inside —it's exactly the same as doing this in the terminal:

# Create the project folder. mkdir = "make directory".
mkdir cumbre-automations

Put your order-triage.json inside that folder. If you haven't exported it yet, open order-triage in n8n, use the download or export-to-JSON option, and save the file there with that name.

Step 2 — Go into the folder. Git initializes the repository in the folder you're standing in, so first you have to go into it:

# cd = "change directory", go into a folder.
cd cumbre-automations

What to expect. Silence again, the sound of success: the terminal says nothing, but notice the text that shows up before where you type —the so-called prompt— it should now include cumbre-automations, confirming you're inside. That visual signal is your confirmation of where you're standing, and it's worth checking it always before running git init, for a reason you'll see in the common mistakes.

Step 3 — Initialize the repository. The lesson's star command:

git init

What to expect. Now Git does answer, with a line like this:

Initialized empty Git repository in /Users/ana/cumbre-automations/.git/

Read it carefully, because it's telling you three valuable things. "Initialized": the repository was created. "empty": there's no photo saved yet —the history is blank, and that's correct, your first commit is lesson 3. And the path ending in /.git/: it tells you exactly where the hidden history folder was created, inside your cumbre-automations. That path is going to be different on your machine; what matters is that it ends in your folder's name followed by /.git/.

If instead you see a line starting with a warning suggesting you configure the default branch name, no problem: it's a harmless reminder that shows up if you skipped the init.defaultBranch main setting from earlier. The repository was created just the same.

Step 4 — Ask Git how the project is doing. The command you're going to use most in your life with Git:

git status

What to expect. With your order-triage.json in the folder, Git answers something like:

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	order-triage.json

nothing added to commit but untracked files present (use "git add" to track)

This block is a small status report, and learning to read it is half of working with Git. Let's go line by line:

• On branch main: you're standing on the main branch, the one you asked to be the primary one. (Branches: lesson 5. For now, it's where you are.)
• No commits yet: confirms the history is empty. You haven't taken a single photo yet.
• Untracked files:: here's the key one. Git sees your order-triage.json, but isn't keeping its history yet. An "untracked" file is one that exists in your folder but that Git hasn't incorporated into its memory yet. It's like a guest who showed up to the party but hasn't been added to the list yet.
• The line in parentheses and the last one are Git's suggestions: it's literally telling you the next command —git add— to start tracking that file. Git guides you along; you just have to read it.

And with this, you did it: cumbre-automations is now a Git repository. Still empty of history, but ready to receive its first photo. Not bad for your first real contact with the tool.

A look (without touching) at the .git folder

You might be curious to see that hidden folder that got created. It's healthy to peek at it once, to demystify it, with one golden rule: look, don't touch.

Since it starts with a dot, the .git folder is hidden by default. To see it from the terminal:

# ls lists files; -a includes hidden ones (the ones starting with a dot).
ls -a

What to expect. Among what shows up you're going to see .git next to your order-triage.json:

.		..		.git		order-triage.json

If you go into .git (you can, with cd .git and then ls), you're going to find a structure of folders and files with names like HEAD, objects, refs, config. That's where Git stores every photo, every branch, and every setting of the repository. You're not going to edit any of that by hand —never, not even once you're an expert: it's always managed through Git commands. It's like a building's machine room: it's reassuring to know it exists and roughly what's in it, but you're not going to go pulling levers in there.

The reason I'm mentioning this isn't so you play around with .git, but so you understand something important: your project's entire history lives inside that folder. If you copy the entire cumbre-automations folder somewhere else —including its .git— you take the complete history with you. If you copy only the order-triage.json without the .git, you take the file but lose all its history. That's the difference between backing up a repository and backing up a loose file, and it's going to be relevant when we talk about remotes in lesson 6.

Get out of the .git folder if you went into it, to go back to the project root:

cd ..

Common mistakes

git: command not found after installing (practical). What happens: you install Git, type git --version in the same terminal you already had open, and it still says it can't find the command. Why it happens: a terminal learns what programs are available when it opens; if you install something new, a terminal that was already open doesn't find out. On Windows it also happens that you installed Git but you're still in PowerShell or the command prompt, when the terminal built for Git is Git Bash. How to spot it: if you just installed and it fails, suspect this before the installation. How to fix it: close the terminal completely and open a new one —on Windows, open Git Bash specifically— and try again. If it still fails on Windows, Git probably didn't get added to the PATH; reinstall, checking the option that mentions "PATH" or "command line," which is exactly the one that connects Git to the terminal.

Forgetting to configure user.name and user.email (practical). What happens: you skip the configuration, everything seems fine, and in lesson 3, when making your first commit, Git stops you with a message asking you to tell it who you are. Why it happens: Git can't sign a photo without an author, so instead of making up a name, it stops and demands one. How to spot it: if when trying a commit you see text mentioning user.name and user.email with instructions to configure them, this is it. How to fix it: run the two git config --global commands from this lesson and repeat the commit. That's why we did it now and not later: so this stumble doesn't catch you halfway through your first commit.

Running git init in the wrong folder —or in your home folder (practical and dangerous). What happens: you run git init without checking where you're standing, and instead of initializing cumbre-automations you initialize your entire home folder, or your desktop, or a folder that already contained another repository. Why it happens: git init acts on the current folder, and if you didn't check the prompt, you don't know what the current folder is. Initializing your home folder is especially annoying: Git starts "seeing" all your personal files as part of one giant repository. How to spot it: before git init, run pwd (it tells you the exact path you're at; it means "print working directory") and confirm it ends in cumbre-automations. After git init, the "Initialized ... in ..." line tells you where it got created; if it's not the path you expected, something went wrong. How to fix it: if you initialized the wrong folder, go into it and delete the .git folder that got created (rm -rf .git on Mac/Linux, or delete it from the file explorer showing hidden files). That undoes the git init without touching your files, because —remember— history is a layer you can remove without damaging what's underneath. Watch out with rm -rf: it's a command that deletes without asking, so double-check you're deleting the right .git.

Creating a repository inside another repository (conceptual). What happens: you already had cumbre-automations as a repository and, without meaning to, run git init again inside one of its subfolders, ending up with a repo nested inside another one. Why it happens: it's easy to lose track of which folders are already repositories. How to spot it: git status from different folders tells you which repository each one belongs to; if a subfolder reports a different repository from the one above it, there's nesting. How to fix it: for a workflow's lifecycle, one repository per project is correct —all of cumbre-automations is a single repo. If a nested one showed up by mistake, delete the subfolder's .git. Truly nested repositories (submodules) do exist, but they're exactly the kind of advanced Git this guide leaves out on purpose; you don't need them.

Exercises

Exercise 1 — Verify your installation end to end. In a freshly opened terminal, run in order: git --version, then git config --list. Note (a) what version number you have, (b) confirm your user.name and user.email show up with the correct values. If something is missing or misspelled (a typo in the email, for example), fix it by running the corresponding git config --global command again and check again.

See solution

The answers are specific to your machine, and that's the point: the exercise builds the habit of checking your own environment instead of assuming it went well. Any recent 2.x version in (a) is correct.

If in (b) your email has a typo, fixing it is just running git config --global user.email "the-correct-one@..." again: the command overwrites the previous value, it doesn't duplicate it. That detail —that setting a value again replaces it— is useful to know: you don't have to "delete" the old one first.

Why it works: a misspelled email in the configuration doesn't cause an error today, but in lesson 6, when you connect with GitHub, your commits might not get associated with your account. Catching it now, when it takes ten seconds to fix, saves you a future headache.

Exercise 2 — Name the three zones on a concrete case. Without looking back at the section, describe what the working tree, the staging area, and the history are, and place each one in this situation: you open order-triage.json, change the CRM's URL, and haven't done anything else yet. Which of the three zones is your change in right now?

See solution

Working tree: your files as they currently are in the folder. Staging area: the zone where you choose which changes go into the next photo. History: the photos already taken, inside .git.

Your URL change is only in the working tree. You edited the file, but you didn't put it in the staging area (that would be git add, lesson 3) or save it in the history (that would be git commit). It's "loose" on your workbench: if you close without saving it in Git, that change isn't recorded in any photo.

Why it works: this is exactly the mental model that makes Git stop feeling magical. A change is always born in the working tree and travels toward the history by way of staging. Being clear on which zone your change is in at any moment is what's going to let you, in lesson 3, understand why a commit needs two steps and not one.

Exercise 3 — Create and undo a practice repository. In any practice folder (not in cumbre-automations), create a new subfolder called git-practice, go into it, run git init, and confirm with git status that it became a repository. Then, undo the repository by deleting its .git folder and confirm with git status that it's no longer a repository. Observe what happened to the folder's contents.

See solution

After git init, git status reports you're in a repository (with "On branch main," "No commits yet," etc.). After deleting the .git —with rm -rf .git or from the file explorer showing hidden files— git status changes completely: now it answers something like fatal: not a git repository. That's the sign the folder went back to being ordinary.

What I want you to see is what happened to the contents: nothing. If you had put a test file in git-practice, it's still there, intact, after deleting the .git. That proves in practice what we said in theory: history is a layer that goes on and comes off without damaging your files. Knowing this removes the fear of experimenting with Git, because git init never puts your real work at risk.

Why it works: creating and undoing a practice repository, on a folder you don't care about, is the fastest way to lose your reverential fear of Git. Commands become things you can try without fear once you prove with your own hands that they're reversible and don't touch your files.

Summary and next step

In this lesson you installed Git —first checking with git --version whether you already had it— and configured it with your user.name, your user.email, and the default branch name main, settings you make once per machine and that make your commits have an author and your repositories be born with the modern branch name. You understood what a repository is: an ordinary folder with a hidden .git folder inside that stores the history, a layer that goes on and comes off without touching your files. You learned the three zones every change travels through —working tree, staging area, and history— with the group-photo image. And you turned cumbre-automations into your first repository with git init, reading its status report with git status and discovering your order-triage.json shows up as an "untracked" file: Git sees it, but isn't keeping its history yet.

Before moving on to lesson 3 you should be able to: open a terminal and confirm git --version answers you; explain what a repository is and what the .git folder contains; name the three zones and say which one a change is born in; and run git init and git status on a folder, understanding what "Untracked files" means.

That untracked file is exactly the loose thread lesson 3 ties up. There you're going to take your first photo: you're going to move order-triage.json from the working tree to the staging area with git add, and from there to the history with git commit, seeing why they're two steps and not one. You're going to learn exactly what a commit is —an immutable photo with a note, an author, and a unique ID— and how to write good commit notes for a workflow, the kind that on Cumbre's bad Tuesday make the difference between knowing what happened and guessing. Your repository is empty of history; in lesson 3 it starts filling up.

Resources

• Installing Git — Git Docs — the official installation guide for Windows, macOS, and Linux, with the three paths we covered and a few more. The reference to go back to if your system behaves differently.
• Downloads — Git — the official downloads page, with the Windows installer and instructions per operating system. The safest starting point for downloading Git.
• First-Time Git Setup — Git Docs — Git's initial setup, including user.name, user.email, and the default editor. Useful if you want to change the editor the installer picked.
• git init — Git Docs — the reference page for the command that creates the repository, with all its options. Dense; for now you only need the bare command, but it's good to know where the full reference lives.
• git status — Git Docs — the reference for the command you're going to use most, with an explanation of every state a file can appear in.