Git on a New Windows PC: init vs clone, origin, -M, -u, and Your First Push

I recently set up Git again on a new Windows laptop.

Installing Git itself wasn't difficult.

What was more interesting was seeing commands I had used many times before as if I were looking at them for the first time again.

git config
git init
git remote
git branch -M main
git push -u origin main

I knew how to use them.

But while setting up a new machine, I caught myself asking:

Why am I setting user.name and user.email again?

What's the actual difference between git init and git clone?

What exactly is origin?

And what do -M and -u actually mean?

So instead of just copying the commands and moving on, I went through the flow again.

This is the version I wish I had when I first started using Git.

---

1. First, make sure Git is actually installed

After installing Git on Windows, I start with:

git --version

If Git is available from the terminal, you should see the installed version.

Simple, but I like checking the command itself instead of assuming the installer finished everything correctly.

---

2. Configure your Git identity

On a new machine, Git does not automatically know who should be recorded as the author of your commits.

Set your name:

git config --global user.name "Your Name"

And your email:

git config --global user.email "[e-mail]"

You can check them again with:

git config --global user.name
git config --global user.email

Or inspect the configuration:

git config --list

One thing that confused me when I first learned Git was thinking this was basically my GitHub login.

It isn't.

These values are used as author information for commits.

If Git does not know your identity when it needs to create a commit, you may run into messages like:

Please tell me who you are.

or:

fatal: unable to auto-detect email address

So on a new development machine, this is one of the first Git settings I check.

---

3. git init vs git clone

These two commands are easy to mix together at first because both can be part of "starting a Git project."

But they start from different situations.

You already have a project on your computer

If you have a local folder and want Git to start tracking it:

git init

This initializes a Git repository inside the current directory.

I think of it as:

I already have this folder.
Now I want Git to manage it.

The repository already exists remotely

If the project is already on GitHub or another Git server:

git clone <repository-url>

For example:

git clone https://github.com/example/project.git

This downloads the existing repository and its Git history.

So the simple version is:

Existing local project
→ git init

Existing remote repository
→ git clone

You normally do not need to run git init before cloning an existing repository.

---

4. Add your files and create the first commit

After initializing a local repository, I usually check its current state first.

git status

Then stage the files:

git add .

And create a commit:

git commit -m "Initial commit"

At this point, the commit exists in the local Git repository.

It is not on GitHub yet.

That distinction is important.

git commit
→ records the change locally

git push
→ sends commits to a remote repository

---

5. What does origin actually mean?

After creating a repository on GitHub, you can connect the local repository to it.

git remote add origin <repository-url>

For example:

git remote add origin https://github.com/example/project.git

When I first used Git, origin felt like some special Git keyword.

It isn't.

origin is simply the conventional name Git uses for a remote repository.

You could technically give the remote another name.

But origin is the standard name you will see almost everywhere.

You can check the configured remotes with:

git remote -v

So when you later run:

git push origin main

you can roughly read it as:

push
my main branch
to the remote repository named origin

That mental model made the command much easier to remember.

---

6. What does git branch -M main mean?

GitHub often shows this command when connecting a new local repository:

git branch -M main

The important parts are:

main
→ the branch name

-M
→ rename the branch, forcing the rename if necessary

So this command renames the current branch to main.

The uppercase -M is effectively the force version of the branch rename option.

For most new repositories, the practical thing to remember is simply:

git branch -M main

means:

Make the current branch name main.

---

7. What does -u mean in git push -u origin main?

Now comes the command I had typed many times without really thinking about every part of it:

git push -u origin main

We already know:

origin
→ the remote repository

main
→ the branch being pushed

So what does -u do?

-u is shorthand for:

--set-upstream

It connects your local branch with the corresponding remote branch as its upstream tracking branch.

After that first push, you can usually use:

git push

instead of:

git push origin main

And similarly:

git pull

can use the configured upstream relationship.

So I now think of:

git push -u origin main

as:

Push main to origin,
and remember that relationship for later.

That is much easier to remember than treating -u as a mysterious flag.

---

8. The full flow from a local project to GitHub

For a new local project, the basic flow looks like this:

git init

git config --global user.name "Your Name"
git config --global user.email "[e-mail]"

git add .
git commit -m "Initial commit"

git remote add origin <repository-url>

git branch -M main

git push -u origin main

After the upstream relationship is configured, the normal daily flow becomes much shorter.

git status
git add .
git commit -m "Describe the change"
git push

That is the part I actually use all the time.

---

What changed for me after setting Git up again

None of these commands were new to me.

I had used Git for years.

But a development machine that has been configured for a long time hides a lot of setup.

On my old machine, Git already knew my identity.

The repositories already had remotes.

The branches already tracked their upstream branches.

I could just open a project and start working.

A new laptop removes all of those assumptions.

And once I had to configure them again, commands like:

git config
git init
origin
-M
-u

stopped looking like one long setup recipe.

I could see what each step was actually doing.

I still don't think every Git option needs to be memorized.

But knowing whether a command is:

creating a local repository
recording a commit
connecting a remote
renaming a branch
or pushing code

makes Git much less confusing when something goes wrong.

---

One thing I would not do

When a Git command fails, I try not to immediately paste a force command from the first search result.

Commands such as:

git push --force

or destructive reset options can change history or discard work.

Before using them, I want to understand why Git is refusing the operation.

That is especially true once other people are working on the same repository.

---

After the first push

Getting the repository onto GitHub is only the beginning.

The next confusing Git questions tend to be things like:

• What is the difference between git fetch and git pull?
• Why was my push rejected as non-fast-forward?
• What does detached HEAD actually mean?
• When should I use revert, reset, or restore?

Those deserve their own explanations rather than being squeezed into a first-push guide.

---

Shipping the project after Git is ready

Getting your code into Git is one step.

Shipping a Spring Boot project is another.

I put the basic version of my release workflow here:

Ship Your Spring Boot MVP — Free Edition

Get the free Spring Boot MVP checklist on GitHub

If you want the complete checklist and release workflow:

Ship Your Spring Boot MVP — Full Edition

Get the Full Edition

---

If I had to keep only one mental model from this setup, it would be this:

init starts local Git.

commit records locally.

remote connects somewhere else.

push sends commits there.

The flags are much easier to remember once the flow itself makes sense.