Git and GitHub: A Practical Guide for Syncing Code Between Windows and Mac

Windows + Mac: A Working Manual for Syncing Code Across Devices with GitHub

1. What this is actually trying to achieve

The goal is not to make Windows and Mac hand files to each other directly. The goal is to let GitHub be the relay station:

Windows
   ↓ push
 GitHub
   ↑↓
Mac
   ↑ pull

For example:

Company Windows: edit the code
→ upload to GitHub
→ go home, Mac downloads the newest version
→ Mac keeps editing
→ upload to GitHub
→ next day, Windows downloads the newest version again

From here on, the only core flow you really need to remember day to day is:

Before starting work:
git pull

Edit files……

At the end of the day:
git add .
git commit -m "说明这次改了什么"
git push

2. What Git and GitHub each are

1. Git

Git is version control software installed on your computer.

It is responsible for recording:

Which files changed
What version was saved each time
Who committed that version
When it was committed

You can think of Git as “an archive system for code.”

For example:

Version 1: project just created
Version 2: home page done
Version 3: product page added
Version 4: mobile menu bug fixed

Later, even if you break something, you can still see what an earlier version looked like.

2. GitHub

GitHub is a code repository on the internet.

It stores code that Git manages online, so that another computer can get it too.

So the relationship is:

Project files
↓
Git manages versions
↓
GitHub stores them online
↓
Another computer downloads them

3. Installing Git on Windows for the first time

Open:

https://git-scm.com/

Download Git for Windows.

On a normal Intel / AMD Windows machine, pick:

x64 Setup

For most options during installation, keeping the defaults is fine.

The one setting that matters more is PATH. Keep it close to:

Git from the command line and also from 3rd-party software

That way PowerShell, CMD, VS Code, Codex and similar tools can all call git directly.

After the install finishes, close the terminal you had open and open a new one.

Type:

git --version

If you see:

git version 2.xx.x

the install worked.

4. Letting Git manage a project for the first time

Say the project lives at:

C:\Users\Administrator\Desktop\测试

Go into the project first:

cd "C:\Users\Administrator\Desktop\测试"

Then:

git init

If you see:

Initialized empty Git repository...

it worked.

What git init actually did

It created a hidden folder inside the project:

.git

The structure now looks roughly like:

测试
├── .git
├── ce.txt
├── src
└── other files

Inside .git it keeps:

Commit history
Version information
Branches
GitHub address
Git settings

So:

git init

is not uploading anything.

It only means this:

From now on, let Git manage this project.

5. Adding a file to Git for the first time

Check the status first:

git status

If you see:

Untracked files:
    ce.txt

it means:

Git can see this file but has not put it under version management yet.

Run:

git add ce.txt

If you want to add every change in the project at once, use:

git add .

Here the:

.

stands for all changes in the current project.

Then check again:

git status

If you see:

Changes to be committed:
    new file: ce.txt

the file is now sitting in the “staged” area, waiting to be committed.

6. Making your first commit

Run:

git commit -m "第一次提交"

Here:

commit

can be read as formally creating a save point.

And:

-m "第一次提交"

is the note you attach to that save point.

For example, later you might write:

git commit -m "完成首页"

or:

git commit -m "修复手机菜单"

7. If Git says it doesn’t know who you are

On the first commit you may see:

Please tell me who you are.

That means Git doesn’t know who the author is.

Set your name:

git config --global user.name "你的名字"

For example:

git config --global user.name "Yepsoso"

Set your email:

git config --global user.email "你的GitHub邮箱"

For example:

git config --global user.email "example@gmail.com"

• --global means:

Every Git project on this computer uses this identity by default.

Verify:

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

Then commit again:

git commit -m "第一次提交"

8. Renaming master to main

Some Git versions create this by default:

master

GitHub now normally uses:

main

So make them match:

git branch -M main

Check:

git branch

If you see:

* main

it worked.

• The leading * marks the branch you are currently on.

9. Creating the repository on GitHub

Log in to GitHub.

Click:

Top-right +
→ New repository

Fill in a repository name, for example:

tongbu

If the project should not be public, choose:

Private

If you already ran git init and git commit locally, then when you create the GitHub repository:

Do not add a README.

Do not auto-create .gitignore.

Do not auto-add a license.

Leave the remote repository empty.

When it’s done you will get an address like:

https://github.com/Yepsoso/tongbu.git

10. Connecting the local project to GitHub

In the terminal, inside the local project, run:

git remote add origin https://github.com/Yepsoso/tongbu.git

It means:

Add this GitHub repository as a remote, and give it the name origin.

Verify:

git remote -v

Normally you will see:

origin  https://github.com/Yepsoso/tongbu.git (fetch)
origin  https://github.com/Yepsoso/tongbu.git (push)

Where:

fetch

means downloading, and:

push

means uploading.

11. If origin already exists and you want to change the GitHub address

If you see:

error: remote origin already exists.

do not run remote add again.

To point at a different GitHub repository:

git remote set-url origin https://github.com/Yepsoso/tongbu.git

Then check:

git remote -v

12. First upload to GitHub

Run:

git push -u origin main

The pieces mean:

git push
= upload

origin
= upload to the matching GitHub repository

main
= upload the main branch

-u
= remember the link between local main and GitHub main

Once the first push succeeds, later on you only need:

git push

You don’t have to retype the full command every time.

After a successful upload, open the GitHub repository and refresh.

If your files show up there, it means this link:

Local computer
↓
GitHub

is working.

13. Never hand your GitHub Token to anyone else

A GitHub Personal Access Token (PAT) usually looks like:

github_pat_xxxxxxxxxxxxx

It is not an account ID.

It is not a verification code.

Essentially it works like a password for GitHub.

So:

Do not paste it into a chat.

Do not send it to anyone.

Do not commit it to a Git repository.

Do not write it into code.

If a token has already leaked:

GitHub
→ Settings
→ Developer settings
→ Personal access tokens

Find the token in question and immediately:

Delete / Revoke

Then generate a new one.

14. Do not run git init on the second computer

Say Windows has already uploaded the project to:

https://github.com/Yepsoso/tongbu.git

Now you want to use it on the Mac.

Do not run:

git init

because the remote repository already exists.

The correct move is:

git clone https://github.com/Yepsoso/tongbu.git

clone does all of this in one step:

download the code
+
download the Git history
+
set up the remote
+
connect the main branch

15. Connecting a private GitHub repository from the Mac for the first time

If the repository is Private, the first attempt on the Mac may produce:

Repository not found

Often the repository is not actually missing. What it means is:

The Mac has not logged in to GitHub yet, so it has no permission to read this private repository.

You can log in with GitHub CLI.

Check first:

gh --version

If it is already installed, run:

gh auth login

Then choose:

GitHub.com

Protocol:

HTTPS

Allow Git to use your GitHub login.

A GitHub authorization page will open in the browser.

Make sure the account you log in with is the right one:

Yepsoso

If the page asks for a device code, go back to the Mac terminal and find a code like:

ABCD-EFGH

This kind of code.

Then enter that terminal code on the GitHub page.

Note:

This code:

• It is not an email verification code
• It is not a GitHub token
• It is a temporary device authorization code for GitHub CLI

After authorization, verify:

gh auth status

If you see that you are logged in:

Logged in to github.com account Yepsoso

it worked.

Then:

git clone https://github.com/Yepsoso/tongbu.git

16. Where git clone actually puts the files

Say the Mac terminal currently shows:

yep@yepdeMacBook-Air ~ %

The:

~

here stands for your home directory:

/Users/yep

If you run:

git clone https://github.com/Yepsoso/tongbu.git

Git will automatically create:

/Users/yep/tongbu

You can use:

pwd

to see the current directory.

Use:

ls

to see the files in it.

If you want to open the project in Finder:

open ~/tongbu

To go into the project:

cd ~/tongbu

17. Pushing from the Mac after you edit files

Say you are already in:

cd ~/tongbu

Edit your files first.

Then check:

git status

For example, if you see:

modified: ce.txt

Git detected the change.

Then:

git add .

Then:

git commit -m "Mac修改"

And finally:

git push

The whole flow:

Edit files
↓
git add .
↓
git commit
↓
git push
↓
GitHub

18. Commit and push in one command

If you already know there are no files in this project that need excluding, you can just run:

git add . && git commit -m "update" && git push

It is the same as running these in sequence:

git add .

stages every change for the commit.

git commit -m "update"

creates a version.

git push

uploads it to GitHub.

So once you are done editing, you can go straight to:

git add . && git commit -m "update" && git push

It is better to replace update with something specific, for example:

git add . && git commit -m "update product detail page" && git push

Then later, when you read the history, you will know what each change did.

19. Getting the Mac’s changes onto Windows

Say the Mac has already run:

git push

On Windows, go into the matching project:

cd "C:\Users\Administrator\Desktop\测试"

Then:

git pull

pull can be read as:

Pull the newest version from GitHub down onto this computer.

The whole process:

Mac edits
↓
git push
↓
GitHub
↓
Windows git pull
↓
Windows has the newest version

It works exactly the same in reverse.

After editing on Windows:

git add .
git commit -m "Windows修改"
git push

Then on the Mac:

git pull

20. The standard workflow for two computers from here on

This is the most important flow from here.

1. Before you start working

Go into the project first.

Then:

git pull

Why?

Because the other computer may already have edited and uploaded a newer version.

If you don’t pull first, you keep editing on stale code and conflicts show up later.

2. Edit the project normally

Use your normal tools:

VS Code
Codex
Cursor
other editors

and edit.

Git does not require you to use any particular program to modify files.

3. After you finish editing

Check first:

git status

Confirm which files changed.

Then:

git add .

Commit:

git commit -m "说明这次做了什么"

Upload:

git push

Or in one line:

git add . && git commit -m "update" && git push

21. Can you move the project folder?

Yes.

Say the project is currently at:

/Users/yep/tongbu

and you move it to:

/Users/yep/Desktop/tongbu

No problem.

Because Git’s information lives inside the project:

tongbu
├── .git
├── ce.txt
├── src
└── ...

As long as you move the whole:

tongbu

folder, the:

.git

moves with it.

The Git history, the GitHub address, the branches and everything else stay intact.

22. Can you rename the project folder?

Yes.

For example:

tongbu

renamed to:

公司网站

Git does not care what the outer folder is called.

As long as this is still inside:

.git

you are fine.

After moving or renaming, go to the new path:

cd "新的项目路径"

Then:

git status

If you see:

On branch main

Git is still working normally.

Check again:

git remote -v

If it still shows:

origin https://github.com/Yepsoso/tongbu.git

then the GitHub connection is fine too.

23. When moving loses Git

Do not copy only the ordinary files from inside the project and leave behind the hidden:

.git

For example, the original was:

tongbu
├── .git
├── ce.txt
└── src

If you copy only:

ce.txt
src

into a new folder:

新项目
├── ce.txt
└── src

then that new folder is no longer the original Git repository.

Run:

git status

and you may get:

fatal: not a git repository

So:

To move a Git project, move the whole project folder.

24. What .gitignore is

.gitignore tells Git:

Which files should not be uploaded and should not enter version management.

A Node.js project would normally ignore:

node_modules/
.env
.env.local

dist/
build/
.next/

.DS_Store
Thumbs.db

Pay special attention to:

.env

because it often holds:

API Key
database password
secret keys
Token

Do not upload that to GitHub.

For example:

OPENAI_API_KEY=xxxx
DATABASE_PASSWORD=xxxx

Once that lands in a public repository, it can leak.

25. What the commands you will actually use mean

git status

shows which files changed right now.

git add .

prepares every current change for commit.

git commit -m "说明"

creates a local Git version.

git push

uploads the local version to GitHub.

git pull

downloads the newest version from GitHub.

git clone 仓库地址

downloads a whole GitHub project to a new computer for the first time.

git remote -v

shows which GitHub repository this project is connected to.

git log --oneline

shows the versions you committed before.

For example:

a832abc 修复首页
b982def 增加产品页面
c371abc 第一次提交

26. The three actions people mix up

Keep these three straight.

git add

It means:

I am getting ready to save these changes.

No real version has been saved yet.

git commit

It means:

Save this as a real Git version.

But that version still only exists on this computer.

git push

It means:

Upload the version I committed to GitHub.

So:

Edit files
↓
add
↓
commit
↓
push

Every step is required.

27. The way I recommend using it from now on

Every time you open the computer and get ready:

cd "你的项目路径"
git pull

Edit the project as normal.

When you are done:

git status

confirm the changes look right.

Then:

git add . && git commit -m "这次修改的内容" && git push

Switch to the other computer:

cd "项目路径"
git pull

and keep working.

The whole multi-device sync logic is:

Computer A

git pull
↓
edit
↓
git add .
↓
git commit
↓
git push

        ↓

      GitHub

        ↓

Computer B

git pull
↓
edit
↓
git add .
↓
git commit
↓
git push

If you remember one line, make it this:

Pull before you start, push when you finish.

28. Where this setup actually stands right now

GitHub account:

Yepsoso

Test remote repository:

https://github.com/Yepsoso/tongbu.git

Windows can already:

commit
push

The Mac has completed GitHub authorization and can do:

clone
pull
push

So the basic Windows ↔ GitHub ↔ Mac sync chain is in place today.

Real projects can follow the same method.

Untitled