Skip to content
Go back

Git for Non-Developers: You Don't Need to Learn the Commands

I’ll be honest — I didn’t know what git add . did until about a week ago. I’m a founder building a Laravel app, not a developer, and git has always felt like one of those things I should understand but never got round to learning.

It turns out I didn’t need to. I learned the entire git workflow by asking questions in plain English to Claude Code, and within an hour I went from “how do I connect git?” to pushing code linked to GitHub issues. The bigger realisation: you don’t actually need to learn the commands at all.

Table of contents

Open Table of contents

You don’t need to memorise git commands

This is the main thing I want you to take away from this article. If you’re using an AI coding assistant like Claude Code, you can just describe what you want in plain language:

The AI translates that into the right git commands and runs them for you. It will even proactively suggest committing after you’ve made changes — you don’t always have to ask.

After I made some UI changes to my app, I said:

“I’d like to commit these changes and push live, how should I do that?”

Claude immediately broke it down — don’t commit the .env changes (local dev settings), do commit the three code files — and asked if I wanted it to go ahead. I said yes. Done.

By the end of the session, I’d dropped the “how should I do that?” part entirely. My messages looked like this:

“thanks, commit and push these changes, and link and close issue 293”

“commit and push, this closes issue 226”

“looks good thanks, commit and push”

No git commands. No remembering flags or branch names. Just plain English.

But the concepts are still worth understanding

Even if the AI handles the commands, it helps to understand what’s actually happening under the hood. Here’s the mental model that clicked for me.

Git has a two-step process

I asked:

“what does ‘git add .’ do?”

The response was clear:

git add . stages all changed and new files in the current directory for the next commit. It tells git ‘I want to include these changes in my next commit.’ Git has a two-step process before pushing: 1) Stage (git add) — select which changes to include. 2) Commit (git commit) — save those changes with a message.”

So the full flow is: stage → commit → push. Three steps, not one. But when you ask Claude Code to “commit and push,” it handles all three.

You don’t need to specify the branch every time

This confused me early on:

“do I always have to run ‘git push -u origin develop’, or can I just type something like ‘commit and push’? do I need to specify the branch?”

The answer: the -u flag sets up tracking between your local branch and the remote. You run it once, and after that git push on its own knows where to send your code.

This was the most useful thing I learned. After pushing some changes, I asked:

“just to help me learn, how did you assign the commit to the issue?”

The trick is simple: include the issue number with a # prefix in the commit message. #329 creates a link. Closes #329 in the commit body auto-closes the issue when the code lands on the default branch. Other keywords like Fixes and Resolves work the same way.

Once I knew this, I just told Claude Code which issue to close and it formatted the commit message correctly.

What the workflow actually looks like

Here’s the before and after of my git workflow in a single session:

BeforeAfter
”how do I go about getting git connected so that I can make changes here locally and then push them my github repo?""commit and push, this closes issue 226”
Didn’t know what git add . doesUnderstood staging, committing, and pushing
Didn’t know how to link commits to issuesJust tells Claude Code which issue to close
Asked “how should I do that?” every timeJust says “commit and push”

The shift wasn’t about memorising commands. It was about understanding the concepts well enough to describe what I wanted.

The AI handles the tricky parts

The moments where git gets dangerous for non-developers — accidentally committing secrets, pushing to the wrong branch, overwriting someone else’s work — are exactly where an AI assistant adds the most value.

When I asked to commit and push, Claude Code proactively excluded my .env file (which had local database credentials and API keys) and only staged the three code files that actually needed to go live. It also knew to push to develop rather than main because that’s the branch I was working on.

This is the kind of judgement that takes developers years to build as instinct. With an AI assistant, you get it from day one.

The minimum git concepts you need

If you’re a founder or marketer working on a Laravel app, here’s everything you need to know about git:

Stage — selecting which changed files to include in your next save point. Think of it like selecting files to attach to an email.

Commit — saving those selected changes with a description of what you did and why. This creates a point in history you can always go back to.

Push — sending your committed changes from your laptop to GitHub (or wherever your code lives remotely). This is what makes your changes available to others and to your deployment pipeline.

Pull — the reverse of push. Downloading the latest changes from the remote repository to your laptop. Always pull before you start working to make sure you have the latest code.

Branch — a separate line of work. The develop branch is where you make changes. The main branch is what’s live. When you push to develop and it gets merged to main, your changes go live.

That’s it. Five concepts. You don’t need to know the commands for any of them if you’re working with an AI assistant.

How this ties to Laravel

Laravel’s deployment tools are designed around git. Laravel Forge — the most popular way to deploy Laravel apps — watches your git repository and deploys automatically when you push. It runs composer install and php artisan migrate as part of the deploy script, so pushing code with a new migration means the database updates automatically.

This means “commit and push” isn’t just saving your work — it’s deploying it. Which is exactly why it’s worth understanding the concepts, even if the AI handles the commands.

Key takeaway

You don’t need to learn git commands to ship code. If you understand the five concepts above — stage, commit, push, pull, branch — you can describe what you want in plain English and let an AI assistant handle the rest. Start by asking questions. Within an hour, you’ll be pushing code linked to GitHub issues without ever typing git yourself.


Back to top ↑