If you need someone to lure prospective customers in with digital ads adorned with snazzy font pairings and cohesive colors, I’m your guy. If you need someone to write a LinkedIn post that resonates with your audience, with an appropriate amount of emojis, I’m your guy (🙋).

But if you need someone to jump into your command line? I am not your guy.

Hi, I’m James, and I’m the new Content and Community Manager at DoltHub — the first marketing hire here, actually. I need to understand a version-controlled database system well enough to help other people get excited about it.

So I turned to Claude and said, “I am a beginner at Git. I need to understand it conversationally. Help me learn.”

What followed was one of the most effective learning experiences I’ve had.

Learning Git First

Claude didn’t hit me with technical documentation that would have gone over my head; rather, we started in a formative conversation:

“Imagine you’re writing a novel. You might save versions like ‘draft1.doc’, ‘draft2.doc’, ‘final_FINAL_v3.doc’. Git does something similar, but way smarter.”

Then it explained that Git takes snapshots, not differences. Every commit is a photograph of your entire project at that moment.

But I got confused when Claude mentioned three “states” files live in: Working Directory, Staging Area, and Repository. I asked what felt obvious: “Why do I need a staging area? Why can’t I just save my changes?”

“Because you might change 10 files but only want to save 3 of them in this particular snapshot. Staging lets you choose exactly what goes into each photograph.”

That clicked. When Claude showed me git commit -m "Added new feature", I asked: “What does the -m mean?” No hesitation: “It stands for message. Without -m, Git opens Vim, which can be jarring for beginners.”

I understood the basics of Git.

Connecting to Dolt

I told Claude that I needed to understand how Dolt uses Git workflows for data. Claude reframed everything:

“You know how Git tracks changes to code files? Dolt does the same thing for database tables. If someone changes a customer’s address, the old address is just… gone. With Dolt, you get the full Git workflow but for your rows and columns.”

Then it gave me the translation:

Git	Dolt
Files of code	Tables of data
Edit a file	Update/insert/delete rows
git add	dolt add
git commit	dolt commit

Suddenly, I understood. Dolt applies Git’s concepts to database rows.

Installation and the PATH Problem

I ran the Dolt installation script. Then I typed dolt

command not found: dolt

Claude asked me to try: /usr/local/bin/dolt version. It worked! But why?

“Your PATH is a list of folders your computer checks when you type a command. Think of it like rooms in a house—if someone says ‘grab the milk,’ they need to know which rooms to check.”

The fix: add /usr/local/bin to my PATH in ~/.zshrc.

I’d used computers for years and never really understood what PATH meant. Turns out, this is one of those things that gets glossed over in every tutorial because “everyone knows this already”—except the people who don’t, who are stuck Googling “command not found” at 2 AM, wondering if they accidentally broke their entire system…

Building a Camera Gear Database

Claude suggested building something practical. I chose what I know, cameras, and started building a camera gear database.

mkdir camera-gear-db
cd camera-gear-db
dolt init
dolt config --global --add user.email "james@dolthub.com"
dolt config --global --add user.name "James Leng"

We created a table:

dolt sql -q "CREATE TABLE camera_bodies (
    id INT PRIMARY KEY,
    brand VARCHAR(50),
    model VARCHAR(100),
    mount_type VARCHAR(50)
)"

I ran dolt status and saw “Untracked tables.” I asked: “What does ‘untracked’ mean? Does that mean the table is lost?”

“No, the table exists. But Dolt isn’t watching it yet. You need to tell Dolt to start tracking it with dolt add.”

That distinction, exists vs. being tracked, was important.

dolt add camera_bodies
dolt commit -m "Created camera bodies table"

We added data:

dolt sql -q "INSERT INTO camera_bodies VALUES 
    (1, 'Canon', 'EOS R5', 'RF Mount'),
    (2, 'Sony', 'A7 IV', 'E Mount'),
    (3, 'Nikon', 'Z9', 'Z Mount')"

dolt add .
dolt commit -m "Added three camera bodies"

I wanted to see what had altered with this added data, so I ran dolt diff which showed me exactly what changed before I committed. Visual, clear, easy to understand.

The ID Gap Question

I accidentally added a duplicate and deleted it. Now my IDs were: 1, 2, 4, 5. The gap bothered me, like, aesthetically.

I asked: “Can I renumber them sequentially so there are no spaces in the row?”

“No. IDs are permanent identifiers—like Social Security numbers. Other tables might reference that ID. If you had a ‘user_favorites’ table that said ‘user likes camera_id 3,’ renumbering would break that relationship.”

The gaps tell the story. I learned this was a fundamental database principle.

Branching: Experimenting Without Fear

I wanted to add a couple of vintage film cameras, but wasn’t sure if I’d keep them.

dolt checkout -b vintage-cameras
dolt sql -q "INSERT INTO camera_bodies VALUES 
    (4, 'Canon', 'AE-1', 'FD Mount'),
    (5, 'Nikon', 'FM2', 'F Mount')"
dolt add .
dolt commit -m "Added vintage film cameras"

I could see exactly what was different:

dolt diff main vintage-cameras

The diff showed the two vintage cameras as additions. At this point, something clicked: I was actually having fun.

If I liked the vintage cameras, I’d merge. If not, delete the branch. My main database stayed safe.

Merge Conflicts

Claude had me make conflicting changes. On vintage-cameras, I updated the camera model name. On main, I updated the same camera’s year. Then:

dolt merge vintage-cameras -m "Merging vintage cameras"

Conflict! Dolt created dolt_conflicts_camera_bodies showing both versions. I could choose which to keep or manually combine them. This taught me how Dolt handles real-world collaboration scenarios.

Pushing to DoltHub

I was ready to push the camera database to Dolthub. Claude suggested the bash below, but it resulted in an error. I hadn’t yet set up my DoltHub database so my terminal had nothing to communicate with.

dolt login
dolt remote add origin j0lt/camera-gear-db
dolt push origin main

Error: “permission denied.”

The digital equivalent of showing up to a party you weren’t invited to. I tried not to take it personally. Claude patiently explained that I needed to create the database on DoltHub via the web interface first. After creating it:

dolt push origin main
dolt push origin vintage-cameras

Success! I refreshed dolthub.com/repositories/j0lt/camera-gear-db and there it was — my database, commit history, both branches, all visible online.

What Made This Work

Claude never made me feel dumb. Claude is ridiculously polite and gave me clear answers without judgment.

It used analogies I could visualize. This was a major help to me. Commits as photographs, PATH as rooms to check, staging as a waiting room.

It explained why, not just how. Claude’s contextualization and understanding of my skill level led to well-rounded answers showing reasoning for the changes, so I could understand the bigger picture at each step.

It let me make mistakes. I fumbled several times! But a quick screenshot of the code and a short message with your confusion, and Claude was there with an explanation, a solution, steps, and a positive push to keep the project going.

I’m still not a command-line guy. But now I’m a command-line guy who can at least navigate without breaking things.

Still confused? That’s totally normal. Check out the rest of the Dolt for Beginners series, or swing by our Discord and ask questions.

I’ll be there, probably learning something new myself.