委托公证怎么办理？2026线上流程、所需材料、去哪办、费用多少？（全攻略）
2026/8/27 3:30:43
GitHub 使用新手从注册到第一个仓库
GitHub 是全世界最大的代码托管平台，程序员的名片、开源项目的家、团队协作的基地。新手面对它最常见的困惑不是「看不懂」，而是「从哪下手」——注册、建仓、提交代码、提 PR，每一步都似懂非懂。这篇文章按新手的行动顺序写：注册 → 建第一个仓库 → 推拉代码全流程 → 走一遍 PR → 布置个人主页，末尾给一份新手最容易踩的坑清单。
全文用 Windows + Git Bash 终端演示，macOS/Linux 的命令完全一致。GitHub 界面和命令是稳定的，但个别按钮位置可能随改版移动，以你打开的页面为准。截图用占位符，每个命令都写了预期输出。
注册与基本设置
去 github.com 点 Sign up，用邮箱注册。用户名会出现在你的所有公开链接里（如github.com/你的用户名），起名时考虑一下长期用，之后改名的成本和代价都不小。密码设置完成后，GitHub 会发一封验证邮件，点一下验证链接激活账号。
注册时顺手把两步安全配置做了：头像和简介（Settings → Profile）、两步验证（Settings → Password and authentication，开启 2FA）。GitHub 账号一旦绑定重要仓库或组织，两步验证是保护它的最低成本手段，手机验证器 App 就够用。
注册完先做两件事，不做后面会一直别扭。
第一件：配置 git 全局信息。GitHub 的提交记录是按邮箱关联到你的账号的，没配好，提交会变成「无名氏」。在终端执行：
gitconfig--globaluser.name"你的用户名"gitconfig--globaluser.email"你注册用的邮箱"# 验证gitconfig--global--list# 预期输出：包含上面两项的配置清单第二件：配置 SSH 密钥。这一步决定了你以后 push/pull 要不要每次输密码。生成密钥：
# 生成密钥（一路回车即可）ssh-keygen-ted25519-C"你的邮箱"# 查看公钥内容cat~/.ssh/id_ed25519.pub# 预期输出：一行以 ssh-ed25519 AAAA... 开头的长文本把输出的整行复制到 GitHub：头像 → Settings → SSH and GPG keys → New SSH key，粘贴保存。然后验证：
ssh-Tgit@github.com# 预期输出：Hi 你的用户名! You've successfully authenticated...看到这句，SSH 就通了。
创建第一个仓库
两种建法：网页上建好再克隆，或本地建好再推送。新手走第一种，直观。
网页建仓：
建好后 GitHub 会给你一个仓库地址，两种格式：
HTTPS: https://github.com/你的用户名/hello-world.git SSH: git@github.com:你的用户名/hello-world.git下面统一用 SSH 地址。把仓库拉到本地：
gitclone git@github.com:你的用户名/hello-world.gitcdhello-world# 预期输出：Cloning into 'hello-world'... 然后当前目录进入仓库clone / push / pull：三个最常用的操作
这三个命令构成日常循环：拉到本地（clone/pull）→ 改代码 → 推上去（push）。
clone：把远程仓库完整复制到本地，上面刚用过。
push：把本地提交推送到远程。
# 先做一次修改，比如编辑 README.md 加一行说明# 查看改动gitstatus# 预期输出：modified: README.md# 加入暂存区gitaddREADME.md# 提交，-m 后写说明gitcommit-m"更新说明文档"# 推送到远程gitpush origin main# 预期输出：Enumerating objects... / To github.com:... 说明推送成功pull：把远程的更新拉到本地，团队协作时每天开工前先执行。
gitpull# 预期输出：Already up to date（没有新改动时）# 或：Updating ... 加上更新的文件列表一个小提醒：分支名是main还是master，取决于你建仓时的默认分支。现在的 GitHub 新仓库默认是main。不确定就git branch看一下当前分支。
PR 流程：fork → 分支 → PR → review
Pull Request（PR）是 GitHub 协作的灵魂。它解决的场景是：你想给别人的项目贡献代码，但不能直接改别人仓库。整个流程四步走：
第 1 步 fork。打开目标项目页面，点右上角「Fork」，等于把对方仓库复制一份到你名下。之后你在自己的副本上随便折腾。
第 2 步 克隆 + 新建分支。把 fork 来的仓库克隆到本地，然后建一个分支干活：
gitclone git@github.com:你的用户名/被fork的项目.gitcd被fork的项目gitcheckout-bmy-fix# 预期输出：Switched to a new branch 'my-fix'分支的规矩：不要在 main 上直接改，永远为每件事开独立分支。
第 3 步 提交并推送到你的副本：
# 改完代码后gitadd.gitcommit-m"修复xxx问题"gitpush origin my-fix# 预期输出：To github.com:你的用户名/被fork的项目.git第 4 步 发起 PR。回到 GitHub，页面会提示「Compare & pull request」。点击进入，填两个东西：
| 字段 | 怎么写 |
|---|---|
| Title | 一句话概括改动，如 “修复登录页在移动端的布局问题” |
| Description | 说清楚改了什么、为什么改、怎么测的 |
点「Create pull request」，PR 就提交给原作者了。对方仓库维护者会 review 你的代码，可能直接合并（Merge），也可能给你评论让你改。如果让你改，改完重新 push 到同一个分支，PR 会自动更新，不需要重新开 PR。
PR 流程梳理成表：
| 步骤 | 动作 | 在哪做 |
|---|---|---|
| 1 | Fork 项目 | GitHub 网页 |
| 2 | 克隆 + 建分支 | 本地终端 |
| 3 | 修改 + 提交 + 推送 | 本地终端 |
| 4 | 发起 PR 并描述改动 | GitHub 网页 |
| 5 | 按 review 意见修改 | 本地终端 + 重新 push |
| 6 | 被合并 | GitHub 网页 |
PR 的 review 环节是最容易被新手忽视的。对方给了评论，别只改代码——在 PR 页面回复评论，说明你改了什么、为什么这么改，reviewer 才能跟上你的思路。改完之后点「Resolve conversation」标记讨论已解决，比闷头改代码体验好得多。还有一点：PR 里的 CI 检查（如果项目配了）红灯时，代码一般不会被合并，先把检查跑绿再说。
分支与合并：PR 之前的必修课
PR 的本质是「把分支合并回主分支」，所以分支和合并的基础要过关。核心就三条命令：
# 新建并切换分支gitcheckout-bfeature/add-login# 看当前在哪个分支gitbranch# 预期输出：* 和当前分支名（* 标记当前所在分支）# 把分支合并回 maingitcheckout maingitpullgitmerge feature/add-login# 预期输出：Updating ... 或 Already up to date合并有两种情况。快进合并：main 在你建分支后没动过，直接移动指针，干净利落。三方合并：两边都改了，git 自动合并大部分，但两边改到同一行时会冲突。冲突时文件里会出现<<<<<<<和>>>>>>>标记，手工选一边（或合并两边的意图），再git add加git commit完成合并。
新手见到冲突就慌，其实流程固定：看标记 → 改文件 → add → commit。真正要练的是怎么少冲突——每次干活前先git pull，把 main 的更新拉下来，冲突就少很多。
个人主页与 README：把 GitHub 当名片
README。仓库根目录的README.md是这个项目的门面，任何人点进仓库先看它。新手别急着写花哨的，按这个结构来：项目是干嘛的、怎么安装、怎么用、一个例子、许可证。用 Markdown 写，#是一级标题，-是列表，基本够用。
一个能用的 README 模板，直接复制改：
# 项目名 一句话说明这个项目做什么。 ## 功能 - 功能一 - 功能二 ## 安装 pip install xxx ## 使用 xxx 命令示例 ## License MIT结构比文采重要，别人能看懂就行。
个人主页 README。有个小技巧：新建一个和用户名同名的仓库（比如用户名是 zhangsan，就建zhangsan/zhangsan），勾选初始化 README，往里写内容，这段内容会直接显示在 GitHub 个人主页顶部。我见过的写法：一行简介、常用技术栈图标、联系方式和「正在做什么」。这是新手最容易忽略的、性价比最高的门面工程。
新手常犯错误清单
带过几个新人的经验，集中在这几处：
| 错误 | 后果 | 正确做法 |
|---|---|---|
| 直接 clone 别人的项目然后乱 push | 推不上去（无权限），或污染 fork | 先 fork，再在分支上改，走 PR |
| 在 main 分支上直接开发 | 历史混乱，回滚困难 | 每次任务开新分支，git checkout -b 分支名 |
push 前不看git status | 把不想提交的文件也推上去了 | 先 status 确认范围，再 add/commit/push |
| commit message 写 “fix” | 三个月后自己也看不懂 | 写清楚改了什么，如 “fix: 修复中文用户名乱码问题” |
| 把密钥、密码写进代码推上去 | 公钥泄露，账号风险 | 用环境变量或 gitignore 排除配置文件 |
| 忘配 user.name / user.email | 提交显示为陌生邮箱 | 注册后立刻配置全局 |
git add .无脑全加 | 把 node_modules 等大目录推上去 | 配好.gitignore再 add |
| 一个分支同时改多个不相关的功能 | 提交历史难 review | 一个分支只做一件事 |
| 从不看 GitHub 的通知 | 错过 review 请求和 CI 失败提醒 | 每天扫一眼邮箱和页面右上角通知图标 |
| 复制粘贴别人的代码不写来源 | 许可证风险 | 用开源代码注意它的 License 协议 |
其中.gitignore单独说一句：它用来排除不用提交的文件。Python 项目至少忽略__pycache__/和venv/，Node 项目至少忽略node_modules/。GitHub 创建仓库时如果选了对应语言的模板会自动生成，也可以自己补。
学到这里，你已经走完了日常协作的主干流程。想继续深入，按这个顺序补课：Git 进阶操作（rebase、stash、tag）、GitHub Actions（自动构建测试）、Issues 与项目管理（用 issue 记录任务、用标签分类）、开源项目贡献（从修文档 typo 开始）。每补一块，你使用 GitHub 的半径就大一圈。
结论
GitHub 的学习曲线其实不陡：注册、配 SSH、建仓、push/pull 这四个动作半小时就能走通，之后碰到 PR 和分支再逐个补课。多数新手卡住的不是命令，而是「不知道流程该长什么样」——所以这篇把每一步的预期输出都写了，你照走一遍，感觉自然就对了。把 README 写好、把分支习惯养好、把账号配置好，你就已经超过大多数同龄的新手了。
这份教程里的每一步，第一次做的时候慢一点没关系，重点是走通。clone 一次、push 一次、pull 一次、提一个 PR——四个动作亲手各做一遍，后面再遇到，就只是重复而已。Git 和 GitHub 的技能是「用熟」出来的，不是「看懂」出来的。