企业官网建设流程全解析

1. 从“手工作坊”到版本控制：为什么你的代码管理方式必须升级

我见过太多这样的场景：项目做到一半，电脑桌面上堆着项目最终版.zip、项目真最终版.zip、项目打死不改版(3).zip，偶尔还有一份从网盘同步下来的“最新”代码。给同事传代码靠微信，多人协作靠互相问“你改到哪了”，改崩了想回退就只能对着空气懊悔。如果你还在用这种方式管理代码，那这篇Gitee和Git的新手指南，就是给你准备的。

先搞清楚两个概念：Git是一个版本控制工具，装在你电脑上，负责记录代码每一次变化的“快照”；Gitee是一个基于Git的代码托管平台，相当于把你本地仓库的代码同步到云端服务器上，实现备份、远程协作和项目管理。你可以把Git理解成单机游戏里的存档功能，Gitee就是那个云存档服务器。两者配合，才能告别代码管理的“手工作坊”模式。

1.1 手工作坊式管理的真实痛点

我知道有人会说：“我一个人的小项目，不需要这么麻烦吧？”听起来很有道理，但踩过坑的人都知道，这套“手工作坊”流程在项目变大之后有多痛苦。

第一个痛点是版本回溯几乎不可能。手工备份的本质是复制粘贴，但每次复制出来的“最终版”，你根本无法准确记录这次改了哪些文件、改了哪些逻辑。三天之后发现新功能把原来的登录逻辑搞崩了，想回到昨天的版本，只能对着一堆压缩包挨个解压试，运气好能找到，运气不好昨天压根没备份。

第二个痛点是多人协作全靠默契。两个人同时改同一个文件，微信里传来传去，后保存的人把先保存的人覆盖了，这是最常见的悲剧。等代码量上来之后，谁改了什么、为什么这么改、能不能回退，完全是一笔糊涂账。出了问题只能靠开会“复盘”——说难听点就是互相甩锅。

第三个痛点是没有代码审查和风险隔离。手工作坊模式下，所有代码都在同一份文件里堆着，改崩了就是全局崩。而正规的版本控制会提供“分支”机制，你可以在一个独立的分支上肆无忌惮地试验新功能，成功了合并回去，失败了直接丢弃，主分支永远稳如泰山。

1.2 Git和Gitee到底解决了什么问题

Git解决的是本地版本管理的问题。它把你项目目录的所有文件纳入版本追踪，每次你手动触发提交（commit），Git就会拍一张全项目文件的“快照”，同时记录提交时间、提交人、提交说明。从此之后，你可以随时跳到任意一次提交的状态，也可以对比任意两次提交之间改了什么。这个能力是任何手工备份方案都给不了的。

Gitee解决的是远程协作与备份的问题。本地Git仓库始终只是你电脑上的一堆文件，硬盘坏了、电脑丢了，代码就没了。把仓库推送到Gitee之后，代码就到云端了，换台电脑可以拉下来继续写。多人协作时，大家各自往同一个远程仓库推代码，Git会自动合并，实在合不了的部分才会提醒你手动处理——这比微信传文件靠谱了不止一个量级。

对国内开发者来说，选Gitee还有一个很现实的原因：访问速度和中文体验。Gitee在国内有服务器，clone和push的速度非常稳定，不像海外平台动不动就超时断连。而且Gitee的界面是全中文的，新手看设置项、看提交记录、配密钥都不用查词典，这对刚入门的开发者极其友好。

1.3 三个核心概念，用生活类比一次讲透

仓库（Repository）：一个仓库对应一个项目，里面包含你所有的代码文件以及它们的全部历史记录。你可以把它理解成一个带“时光机”的文件夹——表面上看就是普通目录，但这个目录记住了自己每一次变化。

提交（Commit）：提交相当于给项目拍一张快照，并附上一句“这次做了什么”。好的提交习惯是：小步提交、写清楚说明。比如修复了登录页面按钮错位，就单独提交一次，而不是攒了三天五十个文件一次推上去，那样将来查历史记录会让人崩溃。

分支（Branch）：分支是Git最强大的功能，没有之一。主线叫master或main，你可以从主线上分出一条支线去开发新功能，支线上的改动不影响主线。开发完、测试完，再把支线合并回主线。用现实类比就是：主线是已经开通运营的地铁，分支是正在试运行的延长线，试运行期间出了问题，最多停掉延长线，已经运营的主线不受影响。

2. 半小时搭好本地环境：Git安装与全局配置

聊完了概念，现在开始动手。这一节目标很明确：在你的电脑上装好Git，并把基础配置一次配对。很多新手在这一步草草了事，结果后面提交代码时每次都要填邮箱、填用户名，或者换行符问题搞得diff乱七八糟，很影响体验。

2.1 各平台安装Git的正确姿势

Windows：去Git官网下载Windows版本的exe安装包（一路默认即可）。但有几个安装选项值得注意，别急着狂点“Next”。安装过程中会问“Adjusting your PATH environment”，一定要选“Git from the command line and also from 3rd-party software”（默认选项），这样才能在CMD和PowerShell里直接使用git命令。还有一个选项是“Checkout Windows-style, commit Unix-style line endings”，这个推荐保持默认，也就是core.autocrlf=true，它能解决Windows和Linux换行符不一致导致的diff错乱问题。

装完之后，在开始菜单里会多出一个Git Bash，这就是Git自带的命令行终端。我强烈建议新手用Git Bash而不是系统自带的CMD，因为Git Bash支持Linux风格的命令（比如ls、pwd、cat），操作习惯和后面在服务器上部署代码时保持一致，可以少踩很多坑。

macOS：系统自带Git，但版本可能比较老。建议用Homebrew安装最新版：brew install git，装完重启终端，git --version确认即可。

Linux（Ubuntu/Debian系）：sudo apt update && sudo apt install git -y。装完之后建议把Git的自动补全脚本配一下，这个后面打字能省不少事。

无论哪个平台，装完后先验证一下：

git --version

能输出版本号，比如git version 2.39.1，就算装成功了。如果提示找不到命令，多半是环境变量没配好，Windows用户检查一下安装时是否选了解除PATH限制。

2.2 第一次用Git前必做的三件套配置

Git装好后不是让你直接用的，第一次使用前必须设置两样东西：用户名和邮箱。Git的每次提交都会记录这两个信息，相当于代码的“署名”。不配置的话，之后的提交会报错，或者用一串奇怪的不完整ID代替你的身份。

git config --global user.name "你的名字" git config --global user.email "你的邮箱@example.com"

这里有个细节值得解释：用户名和邮箱并不需要和Gitee账号完全一致，它们只是提交记录上的标识。但强烈建议你填成Gitee账号对应的昵称和邮箱，这样Gitee能把你推送上去的提交正确关联到你的账号，头像和提交记录才能对上。不然你在Gitee上的活跃度图表就永远是空的。

第三件套是换行符设置。Windows上执行：

git config --global core.autocrlf true

macOS/Linux上执行：

git config --global core.autocrlf input

为什么要配这个？因为Windows的文本文件默认用回车换行（CRLF），而Linux/macOS用换行（LF）。如果不做转换，你在Windows上写的一行代码，同事在Mac上打开可能全部变成“多出一行”，diff时整个文件全是红色，根本没法看。core.autocrlf会在提交时自动把CRLF转成LF存储，checkout时再转回CRLF，省去无数麻烦。

配完之后可以用git config --list查看所有配置，确认无误再继续。

2.3 验证安装与初始化第一个仓库

配置完成后，随便建一个测试目录，初始化一个仓库感受一下流程：

mkdir git-test cd git-test git init

执行完git init后，目录下会出现一个隐藏的.git文件夹。注意，这个文件夹绝对不能删，也不能手动改里面的文件，它就是Git的大脑，记录着你项目的一切历史。如果哪天你的项目代码还在但Git历史全没了，多半就是有人把.git删了或者加了“忽略文件”（.gitignore），这属于灾难级事故。

初始化成功后会提示Initialized empty Git repository。这时候执行git status，会显示On branch master，并且提示当前分支还没有任何提交。看到这个提示，说明环境已经就绪，可以进入下一环节了。

3. 先解决“连不上”，再谈推送：SSH密钥配置与认证失败排查

本地Git装好只是第一步，真正要跟Gitee打交道，你需要先解决身份认证问题。Gitee支持两种连接方式：HTTPS和SSH。很多新手上来就选HTTPS，然后每次push都要输账号密码，输错几次还被锁定，体验极差。我建议直接上SSH，一次配置，长期免密，且更安全。

3.1 为什么Gitee推荐用SSH而不是HTTPS

HTTPS方式，clone和push的地址是https://gitee.com/用户名/仓库名.git，每次推送都要输入Gitee的用户名和密码（或者私人令牌）。虽然可以配置Git缓存密码一段时间，但总归是额外的操作步骤，而且在一些需要脚本化、自动化的场景下没法用。

SSH方式，地址长这样：git@gitee.com:用户名/仓库名.git，它靠一对密钥来验证身份：一个私钥留在你电脑上（绝对不能泄露），一个公钥配在Gitee账号上。连接时，服务器用公钥验证你的私钥。只要配好了，之后的clone、push、pull全部免密，这也是Gitee官方推荐的方式。

还有一点你得有心理准备：用SSH密钥登录Gitee，首次验证时如果服务器返回的指纹你确认过，之后它一般不会反复询问。如果真的弹了Are you sure you want to continue connecting (yes/no)？，输入yes回车就行，这是正常的指纹确认，不是病毒。

3.2 生成SSH密钥并配置到Gitee

打开Git Bash，执行下面的命令生成密钥对：

ssh-keygen -t rsa -b 2048 -C "你的邮箱@example.com"

回车后会问你保存路径，直接回车保持默认（C:\Users\你的用户名\.ssh\id_rsa）。接着会问要不要设置passphrase（输入密码保护私钥），新手建议直接回车跳过，不然以后每次操作都要额外输密码，容易烦。

生成完毕后，查看公钥内容：

cat ~/.ssh/id_rsa.pub

输出的一大段ssh-rsa AAAA...开头的内容就是你的公钥。复制整段内容，然后登录Gitee，进入 头像菜单 →设置→安全设置→SSH公钥，标题随便填一个（比如“我的电脑”），把公钥粘贴进大文本框里，点确定保存。

配好后在Git Bash里测试：

ssh -T git@gitee.com

第一次连接会提示确认指纹，输入yes。如果配置成功，Gitee会返回一段欢迎语，类似Hi 你的用户名! You've successfully authenticated, but Gitee does not provide shell access.。看到这句话，说明密钥已经生效，后面的推送就畅通无阻了。

3.3 ssh认证失败：新手最常遇到的报错与解决

SSH连不上是新手最高频的问题，没有之一。最常见的报错是Permission denied (publickey)，或者中文提示“认证失败”。遇到这个先别慌，按顺序排查：

第一步，确认公钥真的配置上了。很多人把私钥内容（id_rsa）当成公钥贴到Gitee上，这是经典的错误。记住：贴的是.pub后缀文件里的内容，私钥永远不出你的电脑。检查Gitee上的公钥和本地公钥是否完全一致，注意不要多复制或少复制空格。

第二步，确认SSH agent里有没有加载密钥。Windows下如果生成密钥时用了非默认文件名，或者电脑上有多套密钥，Git可能找不到正确的私钥。执行：

eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_rsa

重新加载一下密钥再测试。

第三步，检查是否有多个密钥导致选错。如果你电脑上之前配过其他代码托管平台的密钥（比如公司的GitLab），Git连接Gitee时可能默认拿第一个密钥去试，不匹配就直接拒绝。这时候需要建一个~/.ssh/config文件，显式指定Gitee用哪把密钥：

Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_rsa

保存后重新ssh -T git@gitee.com。

第四步，检查网络环境是否封了22端口。有些办公网络会禁掉SSH的22端口，症状是连接一直卡住或者直接超时。此时可以尝试用443端口做SSH：

ssh -T -p 443 git@gitee.com

这个能不能成取决于Gitee是否开放，但值得一试，尤其是你在公司内网环境下。如果443通了，把~/.ssh/config里的配置改成：

Host gitee.com HostName gitee.com User git Port 443

之后照常使用git@gitee.com:xxx形式的地址，Git会自动走443端口。

4. 第一次完整跑通本地到远端：建仓库、提交、推送

环境配好了，密钥也通了，接下来就是最激动人心的部分：把本地代码推到Gitee上，完成人生第一次完整的“本地→远端”流程。

4.1 在Gitee上创建仓库：字段怎么填

在Gitee首页右上角点“+”→新建仓库，会看到一个表单，里面有几个字段足够新手研究半天。

仓库名称：必填，会直接体现在仓库URL里，尽量用英文小写字母、数字和连字符（-），比如my-blog、student-management。不要用中文和空格。

路径：这个是仓库在Gitee上的唯一路径，默认和仓库名相同，一般不用改。

仓库介绍：选填，建议填一句“这个项目是干什么的”，这样别人看到你的仓库时不用猜。

是否公开：新手练习建议选私有，推上去的代码只有你自己能看到，后面想开放了再改公开。做开源项目的才选公开。

初始化仓库：这里有几个勾选项——README、.gitignore、开源许可证。新手建议都不要勾，保持空仓库。原因很简单：如果你勾了README和许可证，仓库里就会多出几个由Gitee自动生成的文件，到时候本地代码和远端代码的初始历史就不是同一个起点，第一次push会提示“远端有本地不存在的提交”，你得先去pull合并再push，平白多出一堆麻烦。

点创建之后，Gitee会跳转到仓库主页，并提供一个基础操作指引页面，上面有HTTPS和SSH两种地址。这里复制SSH地址，就是我们下一步要用的。

4.2 本地代码提交全流程：add、commit、推送到远端

假设你本地有个项目目录，里面已经写了一些代码。打开终端，进入项目目录，依次执行：

git init git add . git commit -m "init: 项目初始化"

这里拆开解释一下流程：git init把当前目录变成Git仓库；git add .是把所有文件加入暂存区（可以理解成购物车，先选好要买的东西）；git commit才真正把暂存区的内容“拍快照”提交到本地仓库历史中，-m后面跟的是本次提交的说明文字。

很多人第一次接触时会困惑：为什么要分add和commit两步？直接存不行吗？设计成两步的好处是，你可以分批次提交——比如这次改了5个文件，其中3个是修复bug的，2个是新增功能的，你可以先add那3个文件提交一次，再add另外2个提交一次。将来查历史时，bug修复和功能新增是两条清晰的记录，而不是混在一起的一团乱麻。

提交完成后，把本地仓库和远程Gitee仓库关联起来：

git remote add origin git@gitee.com:你的用户名/你的仓库名.git

origin是远程仓库的默认别名，相当于给那一长串SSH地址起了个名字叫“origin”。之后所有操作都可以用这个名字代替完整地址。

关联好之后，推送：

git push -u origin master

-u的意思是“记住上游分支”，完整写法是--set-upstream。加了它之后，以后直接输入git push和git pull，Git就知道推送到哪里、从哪里拉，不用每次都带origin master。第一次推送可能要等一下，看到master -> master之类的进度提示，就说明代码已经上Gitee了。

回Gitee仓库页面刷新，你会看到代码已经在上面了，提交记录里也有刚刚那条init: 项目初始化。

4.3 .gitignore的使用：让垃圾文件不再进仓库

推完之后很多新手会发现一个问题：把一堆不该提交的“垃圾文件”也推上去了。比如Java的target/目录（编译产物动辄几百MB）、Node项目的node_modules/（上万个依赖包）、IDE的.idea/和.vscode/配置文件夹、还有__pycache__等Python缓存目录。这些文件每个人在自己的机器上重新生成就行，提交到仓库里纯属污染。

解决办法是在仓库根目录创建一个.gitignore文件，里面写上要忽略的文件和目录模式：

target/ node_modules/ .idea/ .vscode/ __pycache__/ *.log .DS_Store

Git在git add时会自动跳过这些文件。Gitee也内置了常用语言的.gitignore模板，创建仓库时如果选择了初始化，会自动帮你生成一份。

这里有个常见的坑：.gitignore只能忽略“还没被跟踪”的文件。如果你之前已经把target/提交好在推上去了，再写.gitignore也没用，那些文件已经被Git“记住”了。这种情况需要先把它们从索引里移除：

git rm -r --cached target/

--cached的意思是只从Git索引中删除，不删除磁盘上的实际文件。清理完之后再提交一次，仓库就干净了。

4.4 提交信息的规范：让历史可读

新手最容易忽略的就是提交说明的质量。我见过大量仓库，提交记录清一色是“更新”“修改”“111”，回头查问题的时候根本分不清哪个是哪个。

好的提交说明可以遵循一个简单模板：动词开头 + 改了什么 + 为什么。

比如：

• fix: 修复登录页面在移动端布局错乱的问题
• feat: 新增用户批量导入功能
• docs: 更新README中的部署说明

甚至你可以在提交时用多行说明，git commit不加-m会打开编辑器，第一行是标题，空一行后写详细描述。养成这个习惯之后，半年后回看历史记录，你会感激当初认真的自己。

5. 让项目长在IDE里：IDEA和VS Code的Gitee实操

命令行用熟了之后，新手自然会在IDE里开始日常开发，毕竟大多数人不会一直开着终端敲命令。现在的主流IDE都内置了强大的Git集成，配合Gitee用起来非常顺手。这里分别讲一下IDEA和VS Code里最常见的操作场景。

5.1 从Gitee拉取项目到IDEA

在Gitee仓库主页，找到克隆/下载按钮，复制SSH地址。打开IDEA，在主界面点击Get from VCS（从版本控制系统获取），选择Git，把地址粘贴进去，再选择本地存放目录，然后等着IDEA把代码拉下来即可。

如果你的仓库是私有的，IDEA首次操作时会要求登录。这里建议使用SSH密钥方式，这样IDEA会在后台自动调用你的SSH密钥，不会反复弹窗要密码。如果你配置了多个SSH密钥，IDEA最终连接失败，多半还是~/.ssh/config的问题，处理方法跟前面3.3节一致。

项目拉下来之后的日常流程是：

• 改代码的时候，IDEA右侧的Commit面板会实时列出所有变更文件，每个文件旁边能看到增删行数的统计。
• 写完了，在Commit面板勾选要提交的文件，填写Commit Message，点Commit完成本地提交。
• 之后需要把提交推送到Gitee，快捷键Ctrl+Shift+K（macOS是Command+Shift+K），点Push，代码就上去了。

这里有个IDEA的经典问题：git pull报错，显示Rejected fetch或Non-fast-forward。原因是远端有更新的提交，而本地也有提交，Git不知道该怎么自动合并。解决办法是先用git pull合并远端，或者直接点IDEA里的Update Project，一般它会自动执行pull + merge，合并完再push就没问题了。

5.2 VS Code里的Gitee日常操作

VS Code的Git功能集中在左侧的源代码管理图标（一个倒三角加三个圆点），非常直观。第一次用时需要先克隆项目：Ctrl+Shift+P打开命令面板，输入Git: Clone，粘贴Gitee仓库地址，选择本地目录，VS Code会自动打开项目。

日常操作同样很顺：

• 改代码后，源代码管理面板会显示所有变更文件，文件名旁边有M（Modified，修改过）、U（Untracked，未跟踪）、D（Deleted，已删除）等标记。
• 在输入框里写好提交说明，点提交（Commit）。
• 提交之后点一下推送（Push），就同步到Gitee了。
• 远端有新代码时，源代码管理面板上方的同步更改或拉取（Pull）按钮可以直接拉取。

VS Code比较贴心的一点是，它会在左下角显示当前分支名称，点一下就能快速切换分支、创建新分支、查看提交历史，鼠标操作完全不需要记命令。

5.3 日常开发节奏：pull先于push，避免覆盖冲突

不管在哪个IDE里，我都建议你养成一个肌肉记忆：push之前先pull。

很多报错就是这么来的——早上同事往Gitee上推了新代码，你在本地改了同一个文件，下午直接点push，Git发现远端跟本地历史分叉了，报错拒绝推送（non-fast-forward）。正确处理方式是先pull，把远端合并到本地，解决掉可能的冲突（见6.2节），再push。

还有一个更安全的节奏是：开工之前先pull一次，保证你是在最新代码的基础上开始改；改完提交再push。这样绝大多数冲突都能在源头避免。

6. 分支合并不再慌：从单打独斗到团队协同

很多人自己写项目，一直都是master分支一根线走到底，这也是可以的。但只要你开始跟别人协作，或者项目规模变大，不学会分支管理，迟早要出大事。

6.1 分支的本质：平行宇宙

Git的分支，本质上是给提交历史“贴了一个浮动标签”。你可以简单理解为多个平行时空：某个时刻从主线上岔出去，开发新功能，这个时空里的改动不影响主线时空；开发完成后，再把两个时空“融合”到一起。

常用分支操作就四个：

• git branch：查看本地所有分支，当前分支前面带星号。
• git branch -a：查看包含远端在内的所有分支。
• git checkout -b feature/xxx：创建一个名为feature/xxx的新分支并切换过去。新版Git也可以用git switch -c feature/xxx。
• git branch -d feature/xxx：删除分支（前提是分支已经合并过，否则Git会拒绝删除，防止你误删未合并代码）。

创建并切换分支后，你在当前分支的提交不会出现在master上，两边互不干扰。这对新功能开发、试验性改动来说就是护身符——即使写砸了也不会影响主线的稳定性。

6.2 分支合并与冲突解决

功能开发完了，要把分支合并回主分支。先切回主分支，然后执行：

git checkout master git merge feature/xxx

如果主分支自分叉以来没有新的提交，Git会直接“快进”（fast-forward），把主分支指针移动到最新提交，非常简单。如果主分支也更新了，Git会把两个分支的改动合并成一个新的提交，这种叫“三方合并”。

冲突出现的场景很具体：你们两个人都改了同一个文件的同一个区域，Git不知道以谁为准，就会把冲突标记写进文件里。打开冲突文件，你会看到类似这样的内容：

<<<<<<< HEAD 这是你自己改的内容 ======= 这是对方（分支/远端）改的内容 >>>>>>> feature/xxx

解决办法不复杂：手动编辑这个文件，把<<<<<<<、=======、>>>>>>>这些标记行删掉，决定保留哪个版本，或者两个版本都保留，把文件改成你想要的样子。保存后执行：

git add 文件名 git commit -m "merge: 解决xxx冲突"

到这里，冲突就算处理完了。初学者第一次看到冲突标记会头皮发麻，但实际上多来几次就轻车熟路了。我的建议是：解决冲突时只保留一个来源的版本，然后再手动补上另一处需要的改动，这样比直接在冲突区里手忙脚乱地拼接两个版本要稳妥得多。

6.3 一个安全的分支工作流建议

给新手推荐一个经过验证的安全流程，单人也适用，多人更关键：

1. 永远不要在master分支上直接开发功能。master要保持随时可部署的状态。
2. 每次新功能或bug修复，都从master拉一条新分支，命名规则建议feature/功能名或fix/问题描述。
3. 在功能分支上尽情折腾，随便提交、随便推，不影响主线。
4. 功能稳定后，先pull master最新代码，再把master合并进功能分支（git merge master），解决所有冲突后，测试通过。
5. 最后切回master，合并功能分支（git merge feature/xxx），然后push到Gitee。

这套流程看上去多绕了几步，但回报巨大：master永远是干净的，出问题可以快速定位是哪条功能分支引入的，也能很方便地回滚。团队配合时，不同成员各拉各的功能分支，互踩概率大幅下降。

7. 新手最容易忽视的三个“小事”：Pages、许可证与命令速查

前面几节把Git和Gitee的主干流程讲完了，但有几个东西虽然不起眼，实际用起来却非常频繁，而且踩坑概率极高。放在最后一次性说完。

7.1 Gitee Pages：免费托管静态站和项目演示

Gitee Pages是一个免费的静态网页托管服务，适合放个人博客、项目文档、纯前端demo。很多新手做完了个人主页项目，不知道往哪里展示，Gitee Pages就是最直接的选择。

使用步骤：在项目仓库页面找到服务菜单，点Gitee Pages进入配置页。选择要发布的分支（通常是master或main）和目录（默认根目录/），然后点击启动。部署完成后，Gitee会分配一个用户名.gitee.io/仓库名形式的网址，打开就能看到你的静态页面了。

这里有两个在坑里摔过才懂的细节：

一是Gitee Pages要求账号完成实名认证，否则点启动会提示“需要实名认证”。这个认证跟代码无关，但国内平台都这样要求，提前搞定，别等到部署时卡住。

二是每次更新代码后，Pages不会自动刷新。你在本地改了代码推上Gitee，线上页面还是旧的，需要回到Pages配置页手动点“更新”按钮。Gitee也提供了“自动更新”开关，勾上之后每次push都会自动触发布署，建议直接开启，省得每次都手动点。

7.2 开源许可证怎么选：不要随手勾选

在Gitee创建仓库时有一步是选择开源许可证，很多新手直接跳过不选，或者随手勾一个。这事其实挺重要，因为许可证决定了“别人能不能用你的代码、能用成什么样”。

如果你定位是“分享代码给大家学习交流，不在意别人拿去商用”，选MIT准没错。MIT只要求保留版权声明和许可证文本，几乎什么都不限制，是目前最宽松也最流行的许可证。

如果你在意代码归属，希望明确专利授权条款，选Apache License 2.0。它跟MIT类似允许商用、修改、分发，但额外包含对专利的明确授权。

如果你希望代码永远保持开源，任何衍生作品也必须开源，选GPL-3.0。它的核心规则是“传染性”——有人用了你的代码，他的项目也必须用GPL发布源码。Linux用的就是GPL家族，对开源精神最忠诚，但对想闭源使用你代码的人来说是个障碍。

给新手的实用建议：纯个人练手、希望传播最广，选MIT；想保护自己又被更多人合法使用，选Apache 2.0；明确不想被商用且要求对方也开源，选GPL-3.0。拿不准就先选MIT，反正Gitee仓库设置里后面随时能改许可证。

7.3 Git高频命令速查表

最后整理一张我在日常工作中使用频率最高的命令表，几乎每次提交代码都会用到，建议收藏：

还有一个命令值得补充说明：git reset --soft HEAD~1，作用是撤销最近一次本地提交，但保留所有文件改动（也就是还没提交的状态），适合“提交错了，想重新组合再提交”的场景。注意这个命令会改写本地历史，只能在本地操作，不能在push到线上之后对公共分支历史乱用，否则会让同事的仓库乱成一锅粥。

从手工管理到版本控制，这一趟流程走完，你的代码管理方式就已经彻底升级了。我带了这么多年新人，总结下来最有效的提升方式不是一口气学完所有高级命令，而是把日常高频操作练成肌肉记忆——add、commit、pull、push、开分支、合并，这几个动作溜了，再碰rebase、cherry-pick、git hook这些进阶玩法时，你已经有足够的历史意识和安全边界了。

最后多说一句私房经验：宁可多提交，不要不敢提交。很多新手怕提交多了历史乱，其实提交多没关系，只要提交信息写清楚，随时能回退，乱不了；真正会乱的是那种半年不commit、一commit就推上50个文件的做法，那才叫灾难。放开了用，Git和金庸小说里的“留得青山在”是一个道理——每一次提交都是你的后悔药，也是你的底气。