How to Start Using Git Before You Understand It

By Don

There is a moment, early on, where the AI tells you to run four commands in a row and you run all four. Three of them do nothing you need to think about. One of them makes a decision you will be living with for as long as the project exists.

Nothing in the output tells you which one.

That is the honest reason to start using git before you understand it. You are going to start anyway, because the assistant will hand you the commands and they will work. The question is not whether you understand git. The question is whether you can tell the difference between a step and a decision.

The part nobody tells you is a decision

Setting up git looks like following instructions. It reads like a form that somebody already filled in for you, and all you are being asked to do is sign it.

Four of those boxes were filled in by the assistant, on your behalf, without a word about it. None of them are hard. All four are worth thirty seconds of your attention, and three of them are annoying to change later.

I do not type git commands. The AI does. That is the whole premise of this series, and it means the useful skill is not memorizing syntax I will never use. It is knowing which of the four boxes I should be looking at.

Decision one: what git can see

When you run git init, git creates a hidden folder called .git inside your project. The official documentation is refreshingly blunt about what that gets you: a repository skeleton, and "nothing in your project is tracked yet."

Tracked is the word that matters. Git splits every file in your folder into two piles. Tracked files are the ones git knows about. Untracked files are, in the documentation's words, "everything else." Nothing moves from the second pile to the first until something says so, and the thing that says so is going to be your assistant, running git add on your behalf.

The tool for deciding what stays untracked is a file called .gitignore. It is a plain list of patterns, one per line, and git reads it before deciding what to include. A line reading build/ keeps every build folder out. A line reading *.key keeps every file ending in .key out.

Here is why the timing matters rather than the syntax. The AI will happily write an API key into a config file, because you asked for something that needed a key and it did what you asked. If that file is untracked, nothing happens. If it was tracked before you thought about it, the key is now in your history, and history is the one part of git that does not tidy up after itself.

Guardrail #10: decide what git can see before the first commit, not after.

Before you let anything be committed, ask the assistant to list every file in the project that contains a key, a token, a password, or anything you would not read out loud, and to put them in .gitignore. Do this first. Deleting the file afterward does not remove it.

Decision two: who else can see it

A repository on GitHub is either public or private, and the platform's own wording is worth reading slowly. Public repositories are "accessible to everyone on the internet." Not searchable by developers. Not visible to people you share a link with. Everyone.

Private repositories are free. As of August 2026 a personal GitHub account can create unlimited private repositories, with a smaller feature set than the paid plans. For one person backing up their own work, that smaller feature set is almost entirely things you will never open.

So the default worth having is private, and you widen it later if you decide you want the thing seen. That is a door that opens easily in one direction and not at all in the other. Once a public repository has been cloned by someone, it has been cloned, and flipping the setting afterward does not reach into their copy.

None of this is an argument against working in the open. It is an argument against working in the open by accident, on a project where the assistant wrote your config files.

Decision three: how it knows you are you

At some point a command is going to ask who you are, and this is the step most likely to produce advice that is simply out of date.

GitHub's documentation states it plainly: "Password-based authentication for Git has been removed in favor of more secure authentication methods." Typing your account password into a git prompt does not work and has not worked for years.

What works is either a personal access token used in place of a password over HTTPS, or an SSH key pair, where you generate two halves of a key and hand GitHub the public half. GitHub currently recommends fine-grained personal access tokens over the older classic ones.

The reason this section exists is not that authentication is hard. It is that authentication is the single most likely place for an assistant to describe a version of GitHub that no longer exists, confidently, in complete sentences. If you are told to enter your password, you have just caught one.

Decision four: what your first branch is called

This one is small, and it is the clearest example in the whole setup of why naming the version matters.

Run git init on your own machine and the first branch is called master. Create a repository through GitHub's website and it is called main. Both are correct. They are simply different defaults set by two different pieces of software, and if you set up one way and follow instructions written for the other, commands quietly refer to a branch you do not have.

Git's own manual page says the local default is "currently master, but this will change to main when Git 3.0 is released." The documentation is telling you, in advance, that the answer has a shelf life. Almost nothing else in software is that courteous.

Guardrail #11: tell it what you are looking at.

When a step involves a screen, a menu, or a default, say which version you are on, or ask the assistant to check the current documentation before answering. A model describing last year's interface sounds exactly like a model describing this year's.

The one that does not come back

Three of those four decisions are reversible. You can add to .gitignore whenever you like. You can flip a repository private. You can change how you authenticate this afternoon.

The secret in your history is the exception, and GitHub is direct about why. Rewriting history and force pushing still leaves the old commits reachable "in any clones or forks of your repository" and through cached views. Their first instruction is not to clean the history at all. It is to revoke the credential, because the copy you cannot reach is the one that matters.

That is the asymmetry worth carrying out of this post. Most git mistakes cost you an afternoon. One of them — exactly one — cannot be undone by anything you type.

On the order of all this

I have put these four in the sequence you meet them, which is not the same as the order of their importance. What git can see is the one that can hurt you and it is listed first by luck, not by design. Branch naming is last and will confuse you within the hour. Read them in whatever order your project is currently annoying you.

If you have not read why any of this is worth doing when nobody else touches your code, that came first and it answers a different question. And the habit underneath this whole series is the one from the vocabulary you need before you type a prompt: you cannot ask a good question about a thing you cannot name. If the word rollback in that last section went past you, it has a section of its own.

The sentence to keep

You are not going to memorize any of this, and you do not need to. What you need is one question you can ask before you run whatever the assistant just handed you.

Here it is. Type it, exactly, before the first commit on any new project:

"Before we commit anything: list every file here that contains a key, token or password, tell me whether this repository is public or private, and tell me what the first branch is called."

Three answers. Thirty seconds. It will not make you understand git. It will tell you which of the boxes on the form somebody else already ticked, which is the part you actually needed.

Receipts

Comments

Post a Comment

Popular posts from this blog

The Machine Codes Better Than Us, and That Is Not the Problem

By Don
Image
After 30 years in IT support, networking, training, and a variety of other areas, I have come to realize that technology gets better over time. Wow! I know what a revelation. There is still an argument about who is better, and to borrow a great quote, “From a certain point of view…” honestly, both viewpoints are right. That is the focus of this blog. AI is better at coding. AI can generate code faster and with fewer typos than a human. But can it generate "better code"? Yes and no. Yes, if it's guided properly, and no if it is not. Vibe coding, according to Webster’s: is a semi-recently coined term for programming by prompting an AI, which then writes the code. In vibe coding, the coder does not need to understand how or why the code works, and often must accept that a certain number of bugs and glitches will be present.  Ok, first off, I disagree with parts of this definition.  The part about not needing to understand the code is totally wrong. I do not think you nee...
Read more

Seven Words That Change What the AI Gives You

By Don
Image
The whole pitch for vibe coding fits in one sentence: you describe what you want in plain English, and the machine writes the code. That sentence is true. It's also the most expensive true thing in this field, because it quietly implies that plain English is enough, and plain English is not the same as a clear description. I found this out the way I find out most things. The hard way. Trial, and then error Two methods have worked for me my whole life. The first is trial. The second is error, and it's the one that does the teaching. I can tell you how to make fire by rubbing two sticks together. You'll nod along, and you'll understand every word. Then you'll go outside and fail for two hours, because nobody mentioned how hard to press, or that the wood has to be bone dry, or that some wood won't light no matter how long you work at it. Maybe I said Look for a dark tan piece of wood, and dark tan to you is different than what it is to me. The error half ...
Read more

It Runs. That's Not the Same as It Works.

By Don
Image
The code came back, and it looked right.  That is the part nobody warns you about. It was indented properly. The names made sense. There were comments. It had the confident shape of something written by a person who knew exactly what they were doing. I read it, I nodded, I kept it. And somewhere between three minutes and three weeks later I found out it had been wrong the whole time. The suspicion usually shows up before the evidence does. You get a feeling that something is off, and no vocabulary for what.  Also, you may never look at the code. You just look at the results. The app launches, but something feels off. It seems slow in opening on your brand new iPhone. The inspector isn't smarter than you Buying a house is the closest thing I can compare it to. The house is finished. Somebody built it. The home has walls and a roof, and the doors that close. You walk through, and it looks like a house, because it is one. Then the inspector walks through the same...
Read more