企业官网建设流程全解析

GitHub从入门到会用，对于计算机专业的学生来说就是一道绕不开的坎。Git版本管理、代码托管、协作开发，这些词听着高大上，实际装起来用起来也就那么几步的事。这篇文章就是给你一条最快的路径，从零开始把Git装好、把本地环境和GitHub连通、再把第一个项目推上去——全程只讲必需的东西，不扯没用的理论。适合刚接触编程、还没正经用过版本控制的同学，也适合那些装了Git但从来没配明白的“半新手”。跟着走一遍，半小时内你就能拥有一个能正常工作的Git环境。

1. 装Git之前的几个必要认知

1.1 先搞清楚Git和GitHub是两码事

很多人上来就把Git和GitHub混为一谈，这个坑必须先填上。Git是一个分布式的版本控制系统，它跑在你自己的电脑上，负责跟踪代码文件的每一次改动，让你可以随时回退到任意历史版本。GitHub则是基于Git的在线代码托管平台，你可以把本地的仓库推到上面去，实现备份、分享和多人协作。打个比方：Git是你电脑里的草稿本文具，GitHub是把你写好的文章贴到公告栏供人阅读和协作的墙壁。你完全可以在不用GitHub的情况下使用Git，但只要你想跟别人协作、或者想让自己的代码有个云端备份，GitHub就是必须的那堵墙。

1.2 为什么计算机专业的学生必须掌握它

这个“必须”不是学校吓唬人的口号，是实打实的工作需求。现在的软件公司，不管大小，代码全是跑在Git上的。你在学校里写作业可能觉得“我手动备份一份就够了”，但到了真实项目里，几十个人同时对同一份代码做修改，没有版本控制瞬间就是灾难现场。更现实的一点是，面试的时候考察Git已经成了标配——很多公司会直接让你当场演示clone、commit、push、pull这些操作。所以这件事早晚都得学，早学早受益。

1.3 关于“2020版本”这个事

标题里的“2020版本”其实指的是我写这篇文章时的流行版本环境。Git这个工具本身更新迭代非常快，但你完全不用纠结具体版本号——因为核心的安装步骤和基本命令，这几年来基本没变过。你装到的肯定比我写的版本新，没关系，该有的功能只多不少，界面的变化也微乎其微，照着操作就行。

2. 各平台下的Git安装实操

2.1 Windows平台：下一步下一步的学问

Windows是大多数计算机专业学生的起步平台，也是出问题最多的平台。安装Git其实不难，难点在于安装过程中的一堆选项看着让人心慌。我当年第一次装的时候就卡在这些选项上，每一步都在想“选错了会不会出问题”。

Git官方下载地址是 git-scm.com，进去之后点Downloads，它会自动识别你的系统，Windows用户直接下载64-bit版本。下载下来的文件是个exe，双击运行。前面的协议啊、路径啊，全部默认即可。到了Select Components这一步，默认选项就已经够用，唯一建议确认的是“Git Bash Here”和“Git GUI Here”这两个勾选——它们能让你在文件夹右键时直接打开Git Bash，非常方便。

真正容易选错的是后面几步：

• Default branch name: 这里默认是master，新版Git让你改成main。如果你只是自己用，选哪个都行，跟着新版默认的main走就行，或者保持master也不影响。不过现在新建的GitHub仓库默认分支都叫main，建议从一开始就用main，省得后面还要改。
• Adjusting your PATH environment: 这里请务必选择“Git from the command line and also from 3rd-party software”这个中间选项。选错了后果很严重——选第一个只能用Git Bash，cmd里敲git会报“无法识别”；选第三个又可能跟其他软件的环境变量冲突。
• Line Ending Conversions: 这是Windows用户最容易踩的坑。默认选项是“Checkout Windows-style, commit Unix-style”，意思是检出代码的时候把换行符转成Windows风格，提交的时候转成Unix风格。如果你是自己一个人用、只跟Windows打交道，选第二个“Checkout as-is, commit Unix-style”更省心。但如果你会跟别人协作、或者项目里有跨平台需求，老老实实保持默认最稳妥。
• Git Credential Manager: 这一项保持默认，它会帮你在push到GitHub的时候记忆凭证，省得每次输密码。

一路Next到Finish，安装完成。这时候在任意文件夹右键，应该能看到“Git Bash Here”的选项，点开就是一个类Unix的命令行窗口。验证方式很简单，打开Git Bash敲git --version，能输出版本号就说明装好了。

2.2 macOS平台：比Windows省心得多

macOS用户就幸福多了，基本两条路：装Homebrew的可以直接brew install git搞定，没装Homebrew的可以去git-scm.com下载dmg安装包双击安装。macOS的Git安装不像Windows那么啰嗦，装完打开终端敲git --version就能验证。需要注意的是macOS首次运行Git可能会触发“无法打开，因为来自身份不明的开发者”的提示，这是Gatekeeper在拦路，去系统设置-隐私与安全性里点一下“仍要打开”就行。

另外Xcode Command Line Tools也会带一个Git，但那个版本偏老。建议还是装独立的新版Git，功能和性能都要好一些。

2.3 Linux平台：一句话的事

Linux用户没什么好纠结的，直接走包管理器：

sudo apt update && sudo apt install git -y

Fedora系的用sudo dnf install git，Arch系的用sudo pacman -S git。安装完之后用git --version验证。Linux上唯一要注意的是，如果你的发行版仓库里的Git版本比较旧，可以加个PPA或者直接源码编译，不过对绝大多数人来说完全没必要。

3. 装完之后的必做配置

3.1 设置你的身份标识

Git装好之后别急着用，第一件事永远是配置用户名和邮箱。这是Git提交记录里用来标识“谁改的”的唯一凭证。如果不配，你每次commit都会看到一句讨厌的“Please tell me who you are”提示。

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

这两个值会写进你的全局配置文件里，之后这台电脑上所有仓库的提交都会带上这个身份。如果你在不同平台有不同的Git身份（比如公司电脑一个、自己电脑一个），不用global配置，把--global去掉，只对当前仓库生效就行。但我的建议是：先配好全局的，后面真有需要再针对单独仓库覆盖。

验证是否配好，用这个命令：

git config --global --list

能看到user.name和user.email就说明配好了。

3.2 为什么这一步至关重要

很多人觉得这只是走个过场，随手填个昵称就过去了。但你要是真这么做，等到提交记录多了之后回头看，满屏都是“unknown”或者你随手打的一串乱码，自己都分不清哪条提交是谁做的。尤其以后真要进公司做项目，提交记录上的名字就是你的代码署名，填一个正式、可辨认的名字是基本的职业素养。

另外一个很多人不知道的细节：如果你打算用GitHub账号做代码托管，这里的邮箱最好填你GitHub的注册邮箱，这样你的提交才能和GitHub账号关联起来，贡献记录才会被统计到你的GitHub主页上。

3.3 给终端换个更顺手的默认编辑器

Git在某些场景下需要打开一个文本编辑器让你输入信息（比如commit的时候不指定-m参数）。默认会跳到Vim，而很多人第一次接触Vim根本不知道怎么退出，屏幕上一顿操作猛如虎，退出的时候抓瞎。为了避免这个尴尬，可以直接把默认编辑器改成VS Code（如果你装了的话）：

git config --global core.editor "code --wait"

这样以后git需要你写东西的时候，自动打开VS Code，写完了关掉窗口就行。没装VS Code的话也可以改成Notepad++或别的你顺手的编辑器。这个设置会大幅提升你用Git的舒适度，属于那种“没人提醒就永远不知道”的坑。

4. SSH密钥配置：让本地和GitHub互相信任

4.1 为什么要配SSH而不是用HTTPS

连接GitHub有两种主流方式：HTTPS和SSH。HTTPS的优点是配置简单，首次push的时候输一次用户名密码（或者用Token），之后Git会记住；缺点是每次换新电脑都要重新验证，而且频繁输入凭证也很烦。SSH则是一对密钥：私钥留在本地，公钥放到GitHub上，之后所有操作都不用再输密码了，安全性和便利性都更好。

对于要长期跟GitHub打交道的同学，我的建议是直接上SSH，一劳永逸。唯一的门槛在于生成密钥和配置的过程，但也就是几分钟的事。

4.2 生成你的SSH密钥对

在Git Bash里执行这行命令：

ssh-keygen -t ed25519 -C "你的邮箱"

我推荐用ed25519算法，它是目前GitHub推荐的，安全性和性能都比老旧的RSA更好。如果你的系统或者某些老旧服务器不支持ed25519，再退而求其次用ssh-keygen -t rsa -b 4096。

执行之后会问你保存路径，直接回车用默认路径就行（一般是~/.ssh/id_ed25519）。接下来会让你设置一个passphrase（口令），这个可以理解为私钥的额外密码。建议设一个，即使别人拿到了你的私钥文件，没有口令也解不开。不想设也可以直接回车跳过。

4.3 把公钥添加到GitHub账号

密钥生成之后，需要把公钥内容拿给GitHub看。列出你的公钥：

cat ~/.ssh/id_ed25519.pub

注意是.pub结尾的那个，这是公钥，可以给别人看；不带.pub的是私钥，绝对不能泄露。

复制输出的那一整串内容，去GitHub网站上：

1. 登录你的账号，点右上角头像进入Settings。
2. 左侧找到“SSH and GPG keys”。
3. 点绿色的“New SSH key”按钮。
4. Title随便填，比如“My Laptop”，Key那一栏粘上你复制的公钥。
5. 点“Add SSH key”保存。

4.4 测试连接是否成功

配置完之后测一下连接：

ssh -T git@github.com

第一次连接会提示确认对方指纹，输入yes回车。如果看到类似“Hi 你的用户名! You've successfully authenticated”的输出，说明SSH链路完全打通了。这时候你的本地Git环境才算真正跟GitHub建立起安全通道，后续所有操作都不会再拦着你问密码了。

5. 第一个项目的完整生命周期

5.1 从零开始把本地项目推到GitHub

配置好了环境，下面走一遍最标准的真实流程：本地建仓库、提交代码、推到GitHub。这一步走通之后，你对Git的信任感会一下子建立起来。

首先在本地准备一个项目文件夹，里面放几个文件，然后进入这个文件夹：

git init

这条命令会给当前文件夹建立一个隐藏的.git目录，标志着这个文件夹从此被Git接管。接着把想跟踪的文件加进去：

git add .

.表示添加当前目录下所有文件。如果你有些文件不想提交（比如临时文件、编译产物），提前用echo "文件名" > .gitignore把它们排除掉，这是新手容易忽略但非常重要的习惯。然后提交第一个版本：

git commit -m "first commit"

-m后面跟的是提交说明，确保自己看得懂这次改了什么。从此刻起，你的代码就有了第一个版本记录。

接着去GitHub网站上新建一个仓库（New repository），仓库名随便起，比如“my-first-project”。这里有个细节：如果你的本地文件夹已经存在，就不要再勾选“Add a README file”之类的初始化选项了，否则push的时候会产生冲突，还得处理合并问题。

创建完仓库之后，GitHub会给你一堆命令提示。因为我们上面已经配好了SSH，走到这一步只需要加一个远程地址：

git remote add origin git@github.com:你的用户名/my-first-project.git

最后推上去：

git push -u origin main

这里的-u意思是把本地main分支和远程的origin/main关联起来，以后直接敲git push就能推，不用再指定远程和分支。刷新一下GitHub页面，你的代码就已经躺在云端了。到这里，你已经完成了从零到一的完整闭环。

5.2 日常使用中最核心的三个动作

工作流真正跑起来之后，日常翻来覆去用的其实就三个命令：git add、git commit、git push。我建议你把这套组合动作养成肌肉记忆——改完代码先git add .，然后git commit -m "写了什么"，最后git push。就这么简单。但我见过太多新手在这里栽跟头：改了代码忘了commit就直接push，结果发现推上去的是旧代码；或者add完忘了commit，然后迷迷糊糊关掉终端，一晚上白干。

还有一个高频操作是git pull，它的作用是拉取远程仓库的更新到本地。当你和同学协作同一个项目的时候，别人推了代码，你本地就是旧的，必须先git pull再改代码，不然提交的时候大概率会冲突。关于冲突怎么解决，这篇文章先不展开，记住“先pull再改，频繁pull”这个原则就能避开一半以上的麻烦。

5.3 几个必须掌握的查看命令

光会提交还不够，你得学会“看”。Git给你配备了一堆用于观察的命令，其中最高频的是这五个：

git status git log git diff git branch git remote -v

git status告诉你当前仓库的工作区状态——哪些文件改了、哪些还没加入暂存区、当前在哪个分支。git log展示提交历史，你能看到每次提交的哈希值、作者、时间和说明。git diff用来查看工作区和暂存区之间的具体改动内容，在commit之前检查一下“我到底改了啥”是个非常好的习惯。git branch列出本地全部分支，当前所在分支前面会有个星号。git remote -v显示你关联的远程仓库地址，用来确认你的本地仓库到底连着哪个云端。

在我的使用习惯里，每次commit之前我必敲一次git diff确认改动，每次push之前必敲一次git status确认没有漏提交的文件。这套组合拳虽然看着不起眼，但能帮你避开大量低级的“翻车”场景。

6. 常见问题与排查速查表

6.1 高频错误对照

我在带新人入门的过程中，总结了几个出现频率最高的报错，每个都是真实踩坑现场：

6.2 环境变量出问题的处理办法

Windows用户装了Git之后在cmd里敲git没反应，十有八九是PATH没配好。我自己就遇到过这种情况，排查思路是这样的：先看看git装到哪了，默认一般是C:\Program Files\Git\cmd。然后在系统环境变量的Path里手动加一条这个路径。加完重开一个终端窗口，再敲git --version验证。这里注意是必须在“系统环境变量”的Path里操作，而不是随便加在当前用户的某个自定义变量里，顺序不重要，加进去就行。

6.3 关于换行符的两个实战场景

Windows下换行符问题特别容易踩。默认配置下如果跟别人协作的项目里有脚本文件（比如shell脚本），从Windows机器上签出的文件会被带上回车符（CRLF），推到仓库之后，Linux环境上跑脚本就会报错，什么“bad interpreter”之类的。这其实就是换行符在捣乱。如果不希望团队里每个人都互相踩这个坑，可以给仓库加一个.gitattributes文件，在文件里指定哪些文件用哪种换行符。这是个进阶配置，但你迟早会用到，提前知道有这回事就行。

还有一个操作细节：仓库里已经提交了被错误转换的文件怎么办？改完.gitattributes之后，需要让Git重新规范化所有文件：

git add --renormalize . git commit -m "normalize line endings"

这两条命令会按新规则把所有文件重新存一遍，干净利落。

7. 写给新手的几点真心建议

7.1 别怕命令行，它才是亲儿子

很多同学第一次打开Git Bash看到黑底白字的窗口就心里发怵。我不否认Git也有图形化工具（比如Sourcetree、GitHub Desktop），但我的建议是：前期用命令行，把它用顺了再去碰图形界面。原因很简单：命令行里的报错信息最完整，出了问题你能在搜索引擎找到最准确的答案；而且不管是本地Git操作还是远程命令，所有的教程和资料默认教你的都是命令行。图形化工具确实友好，但它会悄悄屏蔽掉很多底层细节，等你出了问题反而更难排查。命令行是Git的“亲儿子”，先跟它混熟，后面什么都好说。

7.2 提交信息怎么写才不算白写

我刚用Git的时候，提交信息喜欢写“1”“2”“3”这种编号，后来回头看完全不知道干了啥。这是一个典型的反面教材。好的提交信息应该是简短的：做了什么、为什么做。比如“修复登录页面用户名过长导致溢出”就比“fix”有价值得多。建议一开始就养成写中文或英文完整描述的习惯，两句话以内说清楚，别写成小作文。每次提交的粒度也值得注意——一次提交只做一件完整的事，别把“修bug”和“改样式”混在一次提交里，这样以后回滚和查错都轻松。

7.3 学Git的正确路径：少看视频，多动手

回头看我自己学Git的经历，真正管用的就两条：眼看、手做。Git的基本概念就那么几个——仓库、暂存区、提交、分支、远程。你看十遍教学视频都不如亲手建一个仓库，把代码提交上去再clone回来体会得深。我的建议是：今天看完这篇文章，立刻花半小时走一遍第5节那个完整流程，然后再乱试几个命令——改文件、提交、推送、回退。把这个流程玩顺了，你就能甩开相当一批“只会说不会做”的同学。Git这个工具的本质就是个“记录改动的系统”，你越是在真实场景里使用它，就越理解它为什么这么设计。

7.4 遇到问题时的正确姿势

最后说一个学Git最实用的能力：会看报错，会搜报错。每次遇到问题，把报错原文原封不动复制到搜索引擎，比你自己猜一百遍都管用。Git的报错信息在开源工具里算写得比较友好的，大部分时候它已经告诉了你下一步该干什么。还有一个弹尽粮绝时可以用的终极大招——git log --oneline配上git reset --soft HEAD~1，前者看历史，后者取消最近一次提交但保留文件改动。不过这个东西建议你在自己的仓库里用，push到远程的提交如果用了reset会造成历史冲突，新手建议不要动远程的历史。

这篇Git安装入门的实操路线图，到这里基本上就把该覆盖的地方都覆盖了。装好环境只是第一步，真正让它发挥价值的是你接下来每天的使用。第一次push成功的那一刻，是你和Git建立信任的起点。往后还有分支管理、合并策略、rebase、stash等等在等着你，但那些都是后话了——先把今天这一步走扎实，你的版本控制之旅就算正式开始了。