GitHub from Beginner to Master: A Comprehensive Guide

If you want to make money with GitHub, the most direct path is not complicated: under the premise of license permission, find valuable open-source projects, turn deployment, Chinese documentation, and after-sales into a service, and sell the delivery on platforms like Xianyu.

However, what really earns money is information filtering and implementation capability. If you want to do AI, transition to FDE (Full-stack Development Engineer), or turn yourself into an OPC (One Person Company), code, documentation, versions, and collaboration will eventually land on GitHub.

Even if you are doing creation and self-media, there are a large number of topic selection tools, automation projects, and content production processes on GitHub. Once files increase and AI makes changes, without Git to manage versions, things will quickly spiral out of control. Therefore, programmers need to learn it, and so do project managers and content creators; it determines whether you can turn inspiration into a manageable, reusable, and deliverable project.

I have spent over half a month polishing this article, practicing Git, GitHub, Commits, branches, PRs, and common errors from 0 to 1. Future live broadcasts will also follow this same process. Before the official broadcast, I am open-sourcing this tutorial first. You can bookmark it or follow along completely.

1. Git and GitHub: Who Manages What?

Git is a version management tool installed on your computer. When offline, you can still commit, view history, create branches, and merge. GitHub is a remote repository and collaboration platform; it receives commits pushed by Git and provides Issues, Pull Requests, Actions, code reviews, and permission management.

The easiest thing to confuse in Git is that the same modification can exist in four different locations. The infographic below breaks down the workspace, staging area, local repository, and remote repository into four layers.

Pressing save only writes content to the hard drive. git add is responsible for picking, git commit leaves a version locally, and git push sends these commits to GitHub.

So before committing, check the diff, run it, or test it; after pushing successfully, go back to the web page to double-check. This way, if a problem occurs, you can immediately know which layer it stopped at.

2. Before You Start: Prepare Only Four Things

You need Git, a GitHub account, an editor, and a practice project. VS Code is enough for the editor, and the project can be a web page or a Markdown document.

First, confirm Git in the terminal:

1git --version

This exercise uses macOS and Git 2.49.0. Windows users can use Git Bash or the VS Code built-in terminal; the Git commands below are the same.

Next, configure the commit author:

1git config --global user.name "Your Name"
2git config --global user.email "Your Email"

This is the author information written into the commit record; it is not responsible for logging into GitHub. If you only want to configure it for the current practice project, replace --global with --local.

GitHub login is a separate matter. The command line commonly uses three methods:

• GitHub CLI, authorizing via browser with gh auth login;
• HTTPS, using a Personal Access Token or credential manager;
• SSH, adding a public key to GitHub and authenticating via key later.

Beginners can choose GitHub CLI or HTTPS. When using HTTPS, if the terminal asks for a Password, fill in the Token; ordinary account passwords are no longer applicable. Do not write the Token into commands, remote URLs, READMEs, chats, or screenshots.

3. Don't Rush to init: Confirm Where the Terminal Actually Is

This exercise starts with a simple web page. It can be opened in a browser but has no Git history yet.

There are three files in the project:

1index.html
2style.css
3.gitignore

In VS Code, select "Open Folder," don't just click on one HTML file. Then run in the built-in terminal:

1pwd
2ls

pwd shows the current directory, and ls lists files. Continue only after seeing index.html and style.css.

This check looks silly, but it prevents the most troublesome type of accident: someone executing git init on the Desktop, Documents, or even the user home directory, and then git add . putting thousands of irrelevant files into the staging area. Git isn't broken; the directory was wrong.

4. What Does git init Do?

Now initialize the repository:

1git init -b main
2git status --short

git init -b main creates a .git directory in the current folder and names the initial branch main. .git is a hidden directory where information like commits, branches, staging areas, and remote addresses are stored. Project files remain in place; Git starts observing them from this moment.

The ?? in the screenshot indicates untracked files. The files exist, but Git hasn't decided whether to record them yet.

To confirm the repository root directory, you can run:

1git rev-parse --show-toplevel

The output should be the current project folder. If it says fatal: not a git repository, check the directory first, then see if git init was executed.

5. The First Commit: Keep a Reliable Starting Point

The project hasn't been modified yet, so why commit first? Because all subsequent changes need a comparable starting point. First, open the web page in a browser to confirm the title, cards, and registration area are displayed; narrow the window to see if there is horizontal scrolling at mobile width.

Then look at .gitignore. The content used this time is:

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

.gitignore is used to block keys, logs, dependencies, and build artifacts. It mainly works on files that are not yet tracked. If a key has already been committed and you later add it to .gitignore, that history still exists; true handling also includes revoking or rotating the key.

Start picking files for the first commit:

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

The A in the status stands for Added, indicating the file has entered the staging area. git diff --cached --stat will tell you how many files you are preparing to commit and roughly how many lines were changed. To see specific content, run:

1git diff --cached

Commit after confirmation:

1git commit -m "chore: Initialize campus AI recruitment page"
2git log --oneline
3git status

A Commit can be understood as a project snapshot with author, time, description, and parent commit. ffdf4ff is the short version of this commit hash; using it in the current repository can accurately locate the version.

feat, fix, docs, style, chore are common commit types, not mandatory Git syntax. More important than the prefix is the Chinese (or English) description following it: what was done, which object was modified, and why.

6. The Second Commit: Treat AI Modifications as Drafts for Review

Next, add a "View Registration Method" button to the page. When using AI programming tools, I write boundaries into the prompt:

1Only modify index.html, add a "View Registration Method" link below the introduction text,
2linking to #apply within the page. Do not modify style.css, do not execute Git commits.
3Tell me which file was modified when finished.

Manual modification is also simple:

1<a class="cta" href="#apply">View Registration Method</a>

AI says it's done, but don't commit yet. Run:

1git status --short
2git diff -- index.html
3git diff --check

git diff shows changes in the workspace that have not yet been staged. Green + is an added line, red - is a deleted line. git diff --check has no output, indicating no obvious formatting issues like trailing spaces were found; it won't check if the button is clickable for you.

Go back to the browser and refresh, click the button, then narrow the window. The page should scroll to the registration area, and the button and cards should still be normal on narrow screens.

Commit only after the test passes:

1git add index.html
2git diff --cached
3git commit -m "feat: Add registration entry for quick viewing of application methods"
4git log --oneline -2

At this point, there are two clear versions in the repository: the starting page and the registration button. If the button has problems later, you can directly find which commit added it.

By the way, distinguish the two diffs:

1git diff             # Difference between workspace and staging area
2git diff --cached    # Difference between staging area and the most recent commit

If git diff has no output, the file might not be saved, or it might have already been staged or committed. Checking git status, git diff --cached, and git log in sequence is more reliable than repeatedly typing git add ..

7. Branches: Leave a Testing Spot for Uncertain Changes

The button only adds one line, so the risk is small. Changing the entire theme from purple to orange might look good or might look tacky; this kind of modification is suitable for a branch.

1git switch -c experiment/warm-theme
2git branch --show-current

A branch is conceptually a name pointing to a certain commit. When a new branch is first created, it points to the same commit as main, so the files are exactly the same. Only when the experimental branch generates new commits do the two lines diverge.

In the diagram, the blue main still points to the second commit, while the orange experiment already points to the third commit. The project did not duplicate two sets of files; only the pointers for the two branch names changed.

Modify the color variables in style.css, refresh the page to confirm, and then commit:

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: Try warm theme in experimental branch"
5git log --oneline --graph --decorate --all

HEAD indicates where you are currently standing. In the screenshot, HEAD points to experiment/warm-theme, while main remains at the button commit.

Decide to keep the warm theme, switch back to main and merge:

1git switch main
2git merge experiment/warm-theme

A Fast-forward occurs here because main had no new commits during the experiment. Git directly moves the main pointer forward to the warm theme commit; the changes have been successfully merged.

Merged branches can be safely deleted:

1git branch -d experiment/warm-theme

Lowercase -d checks if the branch has been merged. Uppercase -D will force delete, and commits in the branch that haven't been merged might lose their references; don't use it as a daily cleanup command.

8. Conflicts Are Not Mysterious; Git Just Dares Not Choose for You

To verify conflicts, I duplicated the repository. main changed the main title to "Let campus creativity be seen by more people," and the feature branch changed the same line to "Turn an idea into a truly usable work." Git stopped during the merge:

Conflict markers are divided into three parts:

1<<<<<<< HEAD
2Content of the current branch
3=======
4Content of the branch to be merged in
5>>>>>>> feature/rewrite-heading

The handling method is to edit the file, leave the final desired text, delete the three sets of markers, test it, and then run:

1git add index.html
2git commit

If you don't want to handle it at that time, you can abort the merge:

1git merge --abort

A conflict means two people or two Agents gave different answers for the same location, and Git cannot choose on its own.

9. Sending the Local Repository to GitHub

The project already has a local history; now go to GitHub to create a repository. Click the + in the upper right corner, select "New repository," and fill in the repository name, for example:

1campus-ai-demo

For the first practice, it is recommended to set it to Private. Since the local already has a README, .gitignore, and commit history, keep the new GitHub repository blank; do not initialize README, license, or .gitignore on the web side. Otherwise, the local and remote will each have a piece of initial history, and the first push will require handling the relationship between the two sides first. GitHub's official "Adding locally hosted code" also explicitly reminds of this.

Copy the HTTPS address:

1https://github.com/YourUsername/campus-ai-demo.git

Return to the project terminal:

1git remote add origin https://github.com/YourUsername/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin is an alias for the remote address; it can work with other names, but the community habitually calls the main remote origin. -u will establish a tracking relationship between local main and origin/main; subsequent operations usually just run git push.

The terminal diagram below used a local bare repository to run through push and clone, so it didn't change the existing GitHub account. When switching to GitHub, just replace the origin URL; the logic for Git to pass commits and establish tracking relationships is the same.

After the real push is completed, go back to the GitHub web page and refresh to confirm that files, README, default branch, and commit history are all visible. The success message in the terminal is one layer of evidence, and the web check is another.

10. Reading a GitHub Repository for the First Time: How to Read These Things on the Page

Below is the real page of the official GitHub documentation repository, screenshotted on August 15, 2026.

When opening a repository, look at these locations first:

• Code: Files, directories, branches, and commits;
• Issues: Bugs, requirements, tasks, and discussions;
• Pull requests: Changes waiting for review or merging;
• Actions: Automated testing, building, and deployment;
• Security: Security policies and vulnerability-related functions;
• Insights: Contributions, traffic, and repository activity;
• README: Project introduction and usage entry;
• LICENSE: How it is allowed to be used, modified, and distributed.

When reading an unfamiliar project, don't stare at Stars first. Answer five questions first: What problem does it solve, how does it run, what does it depend on, is it recently maintained, and what does the license allow me to do. Stars reflect attention; they don't check security, compatibility, or authorization for you.

11. clone, fetch, pull, push: Don't Confuse the Four Directions

Taking a remote repository to your computer for the first time:

1git clone https://github.com/OWNER/REPO.git

Clone brings back files, commit history, and remote configurations, usually automatically naming the remote origin. Downloading a ZIP only gives a snapshot of the files at that time, without full history, and won't establish a remote relationship.

The three commonly used actions afterward are:

1git fetch origin   # Download remote information, doesn't change current working files
2git pull           # fetch and then integrate into the current branch
3git push           # Send local commits to the remote

To see what happened remotely first, you can:

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

When confirming there is no divergence locally and you want to only accept fast-forward updates:

1git pull --ff-only

pull will fetch first, and then perform merge or rebase based on configuration. Teams should agree on the integration method before the first collaboration, and don't rely on force push to smooth over problems when divergence occurs.

12. From Personal Repository to GitHub Collaboration

A Pull Request is a merge proposal and where collaboration happens. Discussions, code reviews, and automated checks all revolve around the same set of changes, and it is merged into main only after confirmation.

Assuming the Issue is "Add event time description," local operations can be done like this:

1git switch -c feat/event-time
2# Modify and test the page
3git add index.html
4git commit -m "feat: Add event time description"
5git push -u origin feat/event-time

After pushing, GitHub usually prompts to create a Pull Request. A PR is a merge proposal that displays descriptions, commits, file differences, comments, reviews, and automated checks. It won't automatically enter main just because it was created.

A PR that people are willing to review should explain at least three things: what was changed, why it was changed, and how to verify it. The more focused the changes, the easier it is for reviewers to spot issues.

In the same team, if you have write access to the repository, you can send a PR directly from a branch. When contributing to an unfamiliar open-source project, the common practice is to Fork it to your own account first, and then clone your own Fork:

1git clone https://github.com/YourUsername/ProjectName.git
2cd ProjectName
3git remote add upstream https://github.com/OriginalAuthor/ProjectName.git
4git remote -v

There are usually two remotes here:

1origin    Your own Fork
2upstream  The original author's repository

Synchronize the original project:

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

Then complete the modifications in a new branch, push to your own Fork, and then send a PR to upstream. Fork, clone, and branch solve three different things: Fork is a set of repository space on GitHub, clone brings the repository to local, and branch is a development line within a repository.

13. README and LICENSE Determine Whether Others Dare to Use It

A README should answer at least these questions:

1. What is the project;
2. What problem does it solve;
3. How to install or run it;
4. To what extent is it currently completed;
5. Where are the main files located;
6. Who are the authors, materials, and citation sources.

If the code can run but the README is vague, you might not be able to pick it up yourself three months later. A minimal README doesn't have to be pretty; just write the project, running method, and status clearly.

Public repositories also do not automatically equal obtaining an open-source license. GitHub's official license explanation states clearly: when there is no license, default copyright rules still apply, and the author retains the rights to copy, distribute, and create derivative works. Public means others can see it and Fork it according to GitHub's terms of service; to take the code into your own public or commercial project, you also need to look at the LICENSE in the repository.

MIT, Apache-2.0, GPL, etc., have different obligations. When encountering commercial use, redistribution, or mixed licenses, read the full file and consult a professional if necessary; don't just ask an AI "Can I use it for commercial purposes?"

14. After Making a Mistake: Determine Which Layer the Change Is In

Regret medicine should be chosen by state.

Staged the wrong file but want to keep the file content:

1git restore --staged filename

The most recent commit message was written incorrectly and hasn't been pushed yet:

1git commit --amend -m "New commit message"

A commit on a shared branch needs to be revoked:

1git revert commit_hash

revert will produce a new reverse commit, and the old history remains visible, which is suitable for branches that have already been pushed and are used by multiple people.

git restore filename will discard modifications that haven't been committed; git reset --hard will make the commits, staging area, and workspace all return to a specified position; git push --force may overwrite remote commits. These three types of operations require confirmation of the target and backup before execution; don't treat them as general repair buttons in the zero-base stage.

15. Eight Most Common Errors: Check in This Order

1. fatal: not a git repository

1pwd
2ls
3git status

Usually, the directory is wrong, or the current project hasn't been git init yet.

2. Author identity unknown

1git config --local user.name "Your Name"
2git config --local user.email "Your Email"

3. nothing to commit

Check if the file is saved, if you modified another copy, and if the changes have already been committed:

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin CorrectGitHubAddress

5. src refspec main does not match any

The repository might not have a commit yet, or the current branch is not named main:

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

Check the remote URL, repository ownership, account permissions, and authentication method. Do not send the Token to others for troubleshooting.

7. rejected non-fast-forward

There are commits remotely that are not local. Fetch and view differences first; don't just force push:

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

Run git status to find UU files, manually determine the final content, test, then add and commit; if not handling it for now, git merge --abort.

When a student or colleague just says "Git is broken," have them provide these five outputs:

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

Then add the operating system, the full command just executed, and the full error message. Most problems will quickly fall into one of the layers: directory, status, identity, remote address, or permission.

16. In the AI Era, Git Is More Like an Acceptance System

AI can type commands for you, but it cannot automatically know which modifications meet business intentions. If a prompt changes 20 files and you don't look at the diff, don't run the project, and don't check for keys, Git will only faithfully record this mess.

A more stable way is to narrow the task and put the human in the acceptance position. After the scope, differences, tests, and key checks all pass, the human decides whether these modifications can become a commit.

When letting AI operate Git, also give boundaries:

1Please check git status and git diff first, and only summarize the current changes.
2Do not discard any uncommitted content, do not execute reset --hard, clean, or force push.
3Provide verification results after completing modifications, do not automatically commit or push.

Whether you can memorize commands is no longer that important. You need to be able to read the status, know what the AI moved, judge whether the verification is sufficient, and call a halt when dangerous operations appear.

17. Run Through the Whole Process Again

1# 1. Confirm location
2pwd
3ls
4
5# 2. Initialize
6git init -b main
7git status
8
9# 3. First commit
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: Initialize project"
13
14# 4. Modify, check, test, commit again
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: Add registration entry"
20
21# 5. Branch experiment
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: Experiment with warm theme"
25git switch main
26git merge experiment/warm-theme
27
28# 6. Connect to GitHub
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. Final check
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

When you can explain which layer each command changed, and can independently handle a wrong directory, a staging error, and a merge conflict, GitHub is no longer just a website for storing code. You are already able to turn personal projects into repositories that can be reviewed, audited, and collaborated on.

The next step doesn't require continuing to collect commands. Find a real small project and do it for 7 consecutive days: complete only one small modification every day, look at the diff, test, commit, and then push to GitHub. The commit history will slowly turn this set of things into your working habit.

I am Miles, an AI algorithm expert who transitioned from a big company to FDE. I have done algorithm R&D, optimization deployment, and corporate training. Follow me @miles_mazy Grow together, make money together.