GitHub Beginner's Guide: From Repository, Commit, and Fork to One Commit a Day

Many people who open GitHub for the first time are discouraged by all the English buttons: Repository, Commit, Branch, Pull Request, Fork, Star, Watch, Issue, Actions… It all looks like tools meant only for programmers.

But GitHub can be understood with one simple sentence:

GitHub = a website for storing code, tracking changes, collaborating, and showcasing projects.

If you are learning AI tools, Claude Code, Codex, Cursor, Vercel, Next.js, or Python projects, GitHub is basically unavoidable. Many open-source projects are hosted on GitHub, and many site deployments connect to GitHub repositories.

This article does not try to teach all Git commands at once. Instead, it helps beginners understand the most common concepts and buttons on GitHub pages first. Once you understand the interface, learning commands will be much easier.

1. Are Git and GitHub the same thing?

No.

In one line:

Git is a tool; GitHub is a platform.

You can use Git on your own computer to manage code, and you can also push code to GitHub to store and showcase it. Git is more like a lower-level tool, while GitHub is a collaboration platform and website built around Git.

2. Repository: What is it?

Repository is often shortened to repo, and can be called repository in Chinese.

A repository is a project folder. For example:

my-website/
├── README.md
├── package.json
├── src/
└── public/

On GitHub, a repository typically contains:

• Project code
• Project documentation
• Change history
• Issue discussions
• Pull Request collaboration records
• Actions automation workflows

If you want to showcase your own website, Python utility, or AI Agent project, you can create a GitHub repository. For individual learners, a repository is not only a backup place for code, but also a long-term portfolio.

3. README: The project “manual”

README.md is one of the most important documentation files in a GitHub project.

When someone opens your repository, GitHub usually displays the README automatically. It should clearly explain:

1. What this project does. 2. How to install and run it. 3. What its main features are. 4. Which technologies are used. 5. Whether there are project screenshots or demo links. 6. Author, license, and other notes.

For personal projects, a clear README makes your skills easier for others to grasp than just piling up code. Especially for résumé projects, portfolio projects, and open-source learning projects, the README is the face of the project.

4. Commit: What does it mean?

A Commit can be understood as “saving a version.”

Each time you complete a small change, you can make a commit to record the current state. For example:

First commit: initialize the project
Second commit: add homepage layout
Third commit: fix search functionality
Fourth commit: update README documentation

A commit is not just “just clicking save.” It leaves a clear history of changes for the project. Later, if you want to know when a feature was added or how a bug appeared, you can check the commit record.

A good commit message should concisely state what you changed, for example:

Add homepage layout
Fix broken search filter
Update README installation guide
Refactor API request logic

Chinese projects can also use Chinese commit messages:

Add homepage layout
Fix broken search filter
Update README installation guide
Refactor API request logic

Beginners do not need to follow strict commit conventions at first, but at least avoid messages like aaa, test, or random tinkering, which carry no clear meaning.

5. What determines your Git commit identity?

Many beginners mistakenly think:

I logged into GitHub in VS Code, so the commit author is that GitHub account.

This is not entirely correct.

A Git commit’s author identity is mainly determined by local Git configuration, specifically:

git config user.name
git config user.email

If you want to check the Git identity for the current project, enter in the terminal:

git config user.name
git config user.email

If you want to set a global identity, run:

git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"

Keep in mind:

VS Code / GitHub login: mainly used for push, pull, and accessing remote repositories.
Git commit author: mainly determined by git config user.name and user.email.

So after switching GitHub accounts, it is best to check your local Git configuration to avoid commits still showing your old email or old name.

6. Main vs Branch: What are the main line and branches?

This is one of the biggest sticking points for beginners on GitHub.

Many people see main, branch, merge, and pull request and subconsciously think they are different folders, or think a branch means the entire project is fully copied.

A more accurate understanding is:

main = the mainline version of the project, usually the current most stable and official code.
branch = a separate line of modifications split off at some point, used for safe experimentation or feature development.

GitHub’s official docs note that a new repository includes a default branch. When others open a repository, browse the code, or clone the project, they usually see this default branch first. Many newer projects now use main as the default branch name, while some older projects may still use master.

1. Start with a simple analogy

You can imagine a project as an article in progress.

main is like the officially published draft:

Final Article.docx

You now want to rewrite a chapter, but you don’t want to risk damaging the final version, so you do not edit the published file directly. Instead, you create a working draft:

Final Article.docx
Chapter 2 Draft.docx

You edit the draft freely. If it works, you merge it back into the final article; if not, you discard the draft and the final version stays unchanged.

In Git, this “draft path” is called a branch.

But note: branch is not a heavy copy of the entire folder. Git’s official docs explain git branch as creating a new branch head pointing to the current HEAD or a specified start point. Beginners can understand it as:

A branch is not a full copy of the project; it is a new line of changes starting from an existing commit.

2. Why are branches needed?

Because real projects often involve multiple things happening at the same time:

Mainline code must stay stable;
you want to develop a new feature;
someone is fixing a bug;
someone else is rewriting the README;
an urgent issue appears in production and needs a hotfix.

If everyone edits main directly, the project can get messy quickly. If one person breaks it, everyone is affected.

So a safer approach is:

main stays stable
new feature work goes on a feature branch
bug fixes go on a fix branch
doc changes go on a docs branch
merge back to main after verification

For example:

main
├── feature/search-page
├── fix/mobile-layout
└── docs/update-readme

It is like a main road with temporary construction lanes. On those lanes, you can modify, test, and rework; once done, merge back onto the main road.

3. What is main?

main is usually the repository’s default branch, i.e., the primary branch of the project.

You can think of main as:

The primary version of the project currently shown to the public.

Common situations include:

• When others open your GitHub repository, they usually see main by default.
• When others clone your repository, the local default is usually main.
• Deployment platforms like Vercel often monitor updates from the main branch.
• In team projects, main is often expected to stay runnable, deployable, and relatively stable.

So beginners should build this habit:

Avoid making large changes directly on main.

Small projects and personal learning projects can edit main directly without major issues; for formal projects, it is better to create a new branch.

4. What is a branch?

branch in Chinese means “branch.”

You can understand it as:

Split off from a certain version of main and make a set of modifications separately.

For example, if your site on main is stable:

main: homepage OK, article pages OK, search OK

You want to add a comment feature but are not sure if it will break the page. So you create a new branch:

feature/comment-system

Then you develop the comment system on that branch. At this point:

main remains unchanged;
feature/comment-system can be changed freely.

After testing confirms everything is good, merge the branch back into main.

5. Branch is not fork

Beginners also often confuse branch and fork.

For example:

Creating feature/search-page in your own repository is a branch.
Copying someone else’s project to your own account is a fork.

So:

branch is an internal branch of a repository;
fork is a copy across repositories.

6. The simplest branch workflow

For beginners, memorizing this flow is enough:

1. main is the stable version
2. create a new branch from main
3. modify files on the branch
4. commit the changes
5. push to GitHub
6. create a Pull Request
7. after verification, merge back into main
8. delete the completed branch

Mapped to a real scenario:

main
→ create feature/update-homepage
→ edit homepage
→ commit: Update homepage layout
→ push
→ Pull Request
→ merge into main

After merging, main includes this new feature.

7. Common branch naming

A branch name should ideally indicate what you are working on.

Common patterns:

feature/login-page
feature/search-function
fix/mobile-navbar
docs/update-readme
refactor/api-client

General convention:

Beginners do not need to overthink naming rules, but avoid names like test1, newnew, final-version that do not convey meaning.

8. Summarize main and branch in one sentence

You can remember it like this:

main is the trunk; branch is a side branch.
main is for stable presentation; branch is for safe changes.
Once branch is ready, merge into main through Pull Request.

If this is your personal project, you can commit directly on main at first. But once your project becomes more complex, or you want to avoid breaking the site, you should start using branches.

7. Pull Request: What is PR?

Pull Request is abbreviated as PR, and can be understood as:

I finished a set of changes. Please review it. If everything is fine, merge it into the main project.

PRs are common in team collaboration and open-source projects.

For example, if you fork someone’s project, fix a bug, and then submit a PR to the original author. The original author can review your changes, discuss them, request adjustments, and finally decide whether to merge.

A PR is not simply “uploading code.” It is a collaborative workflow for review, discussion, and merging code. GitHub’s official docs also describe Pull Request as a mechanism for proposing changes, receiving feedback, handling conflicts, and advancing merges.

8. Fork: What does it mean to fork/derive?

Fork can be understood as:

Copying someone else’s GitHub repository into your own account.

After a fork, you can freely modify your own copy without affecting the original project.

A typical flow is:

Find an open-source project
→ click Fork
→ modify in your own fork repository
→ commit
→ open a Pull Request
→ request the original project to merge your changes

For beginners, fork is commonly used in two ways:

1. Learning the structure of someone else’s project. 2. Doing secondary development based on someone else’s open-source project.

But note that forking does not mean you own the copyright. Before using someone else’s project, check its license to confirm whether you are allowed to copy, modify, commercially use, or redistribute.

9. Star: What does it mean to Star/favorite/like?

Star can be understood as a favorite or like on GitHub.

If you find a valuable project, you can click Star to save it for later.

Star counts are often used as a rough indicator of popularity, but it is not the only standard. A project with many stars is not necessarily right for you, and a project with few stars may still be valuable.

For people learning AI, Agents, frontend, or Python, treat Star as your own open-source project bookmarks.

10. Watch: Following project activity

Watch means subscribing to notifications for a repository.

If you watch a project, GitHub may notify you about Issues, PRs, Releases, and other updates.

Beginners usually should not watch too many projects at once, or notifications will become overwhelming.

A simple way to understand:

11. Issue: Bugs, proposals, and discussions

Issue can be understood as a project “ticket” or discussion post.

Common uses include:

• Reporting bugs
• Suggesting new features
• Keeping a to-do list
• Project discussion
• Asking usage questions

For example:

Bug: Search does not work on mobile
Feature request: Add dark mode
Question: How to configure API key?

For your own project, you can also use Issue to manage tasks. For example, in your personal website you can open issues such as: fix mobile styling, add SEO description, add article search, clean up README. This makes the project feel like a real engineering effort rather than a pile of scattered files.

12. Actions: Automation workflows

GitHub Actions is GitHub’s built-in automation tool.

It can automatically run tasks after you push code, such as:

• Automatic testing
• Automated builds
• Automated deployment
• Code formatting checks
• Releasing versions

For example, many Vercel, Next.js, and Python projects combine GitHub Actions with deployment platforms for automation workflows.

Beginners do not need to rush into Actions, but it is enough to know that it is related to automation. After you understand basic commit, push, branch, and PR, learning Actions will feel much more natural.

13. Code button: Download and copy repository URL

On a GitHub repository page, the green Code button is important.

Clicking it usually reveals:

• HTTPS URL
• SSH URL
• GitHub CLI URL
• Download ZIP

Common command:

git clone https://github.com/username/project-name.git

This means downloading the remote GitHub repository to your local computer.

If you only want to view the code and do not want to use Git, you can also click:

Download ZIP

to download the entire project as a zip archive.

14. What do Push, Pull, and Clone mean?

These terms are very common.

A simple workflow is:

clone project to local
→ modify files
→ commit record changes
→ push upload to GitHub

If someone else also changed the remote repository, you need to:

pull latest content
→ continue editing
→ commit
→ push

15. What does “one commit a day” mean?

What many people mean by “one commit a day” is usually making one meaningful contribution on GitHub every day to keep your contribution graph continuous.

GitHub profiles have a green contribution chart that shows your activity by date. Contributions can include commits, pull requests, issues, discussions, and other activities. But GitHub has specific rules for what counts; not every action is included.

Beginners should note:

One commit a day is not about making green squares; it is about building a habit of continuous iteration.

A healthy approach is to make one small but real change every day, such as:

• Modify a paragraph in README
• Fix a small bug
• Add a small feature
• Organize project directories
• Add a learning note
• Improve a page style
• Add a test case

Do not commit meaningless changes just for the sake of committing, such as changing only one space every day. That provides little value for learning and portfolio building.

16. A one-commit-a-day practice routine for beginners

If you do not know what to commit every day, follow this rhythm.

1. Day 1: Create a repository

Create a new repository, for example:

github-learning-notes

Add a README and clearly explain that this repository is used to record GitHub learning notes.

2. Day 2: Add common GitHub terms

Add to the README:

Repository = 仓库
Commit = 提交
Branch = 分支
Pull Request = 合并请求
Fork = 复刻 / 派生

3. Day 3: Add command-line notes

Add a new file:

command-line-basics.md

Record commands like ls, cd, mkdir, pwd.

4. Day 4: Add Git command notes

Add:

git-basics.md

Record:

git status
git add .
git commit -m "Update notes"
git push

5. Day 5: Organize directory structure

Reorganize notes into:

github-learning-notes/
├── README.md
├── notes/
│   ├── command-line-basics.md
│   └── git-basics.md
└── resources.md

6. Day 6: Add references

Add resources.md and include links to GitHub Docs, official Git documentation, and excellent open-source projects.

7. Day 7: Write a weekly summary

Add to the README:

What did I learn this week?
What do I still not understand?
What do I want to do next?

This is more valuable than mechanically making commits, because you end up with a project that genuinely demonstrates your learning process.

17. Common Git commands for beginners

If you use VS Code, you can complete many operations through the GUI. But understanding these commands is still helpful.

View current status:

git status

Stage changes:

git add .

Commit changes:

git commit -m "Update README"

Push to GitHub:

git push

Pull latest content from GitHub:

git pull

View commit history:

git log --oneline

Beginners can first get comfortable with these commands; you do not need to memorize complex commands right away. As you do real projects, you will naturally encounter more scenarios like switching branches, resolving conflicts, and reverting versions.

18. Common misunderstandings for beginners

1. Logging into GitHub is not the same as commit identity

Logging into GitHub mainly solves remote repository access permissions. The name and email shown on a commit depend on Git configuration.

2. Fork is not the same as download

A fork copies it under your own GitHub account; clone downloads it to your computer.

3. Commit is not the same as Push

Commit is local version saving; Push uploads to GitHub.

4. Star is not the same as Fork

Star is bookmarking; Fork is creating a copied project version.

5. A Pull Request is not guaranteed to be accepted

A PR is a request for the original project to merge your changes, but maintainers can accept it, reject it, or ask for further modifications.

6. GitHub contribution graph is not true ability

A contribution graph can show consistency, but it does not fully represent engineering ability. What matters more are project quality, documentation clarity, runnability, and sustained iteration.

19. Suggested learning order

If you are a complete beginner, I suggest learning in this order:

1. First learn to read repository pages: README, Code, Issues, Pull Requests, Actions. 2. Then understand Repository, Commit, Branch, Fork, Star, Watch. 3. Then learn git clone, git status, git add, git commit, git push. 4. Then build your own learning notes repository and keep committing meaningfully for a week. 5. Finally learn Pull Requests, open-source contribution, and GitHub Actions.

Do not try to master complex collaboration at the beginning. Making your own project upload, edit, commit, and showcase end-to-end is more important than memorizing concepts.

20. Summary

For beginners, the most important thing about GitHub is not mastering every command at the start, but understanding a few core actions:

Create a repository
→ modify files
→ make a commit
→ push
→ showcase the project

If you want to participate in others’ projects, then also understand:

Fork
→ modify
→ Commit
→ Pull Request

GitHub is fundamentally a platform for recording work, showcasing ability, participating in open source, and managing projects. For people learning AI tools and web development, it is not only a code repository, but also your long-term portfolio.

Make small real changes every day, keep recording, keep submitting, keep summarizing, which is more important than piling up many complex concepts in a short time.

FAQ

What level of developers is this article suitable for?

See the “Target audience” note in the main text; articles in the Programming category here cover levels from beginner to AI programming workflows, with different assumed backgrounds in each article.

Do the tools or commands in this article differ across systems?

Yes. Terminal environments, path formats, and command syntax differ among macOS, Linux, and Windows. If a specific system is not stated, refer to the official documentation and adjust accordingly.

Which AI tools do you recommend for learning programming?

Claude Code and Codex are currently strong AI coding tools. You can use them to explain code, fill in logic, debug errors, and generate scripts. You can refer to the site’s CC Switch Tool article and Vibe Coding interview question set.

What is the most important habit in learning programming?

Hands-on practice is more important than watching tutorials. It is best to find a real project early (even a small one), and when you get stuck, check documentation and code rather than only finishing theory.

References

• GitHub Docs: Hello World
• GitHub Docs: Changing the default branch
• GitHub Docs: Managing the default branch name for your repositories
• Git Documentation: git-branch
• GitHub Docs: Pull requests documentation
• GitHub Docs: Fork a repository
• GitHub Docs: Profile contributions reference
• GitHub Docs: Understanding GitHub Actions

If you are already familiar with Git basics, you can learn more about integrating AI tools into workflows in the Vibe Coding / Agentic Flow interview question set.