企业官网建设流程全解析

1. 先把这件事的链路想清楚：CLion 不是"上传工具"

很多人第一次在 Mac 上想把手头的 C/C++ 工程放进远程仓库，脑子里浮现的画面是：点一个按钮，代码就飞上去了。真到了操作界面才发现，CLion 里既没有"上传"这个词，也没法像文本编辑器那样拖一个文件夹就完事。这不是工具做得不好，而是它遵循的逻辑完全不同——CLion 处理的是版本控制工作流，不是文件传输。你得先有一个本地仓库，再有提交记录，最后才是把提交推送到远端。这三步任何一步缺了，界面上那些按钮就是灰的。

我记得自己第一次用 CLion 做这件事时，在设置里翻了半天"Deploy"和"Upload"相关的选项，最后发现真正该找的是 Version Control 里的 Git 配置。这个小小的认知偏差其实很典型：把 IDE 当成文件管理器用。CLion 真正做的是把 Git 命令包装成可视化操作，底下的git init、git add、git commit、git push一条都没少，只是把命令行藏起来了。理解这一点，后面所有操作都会顺很多。

这篇文章面向的是这样一类人：手上有个 C 或 C++ 项目，在 Mac 上用 CLion 写代码，希望代码能同步到一个远程托管服务上，方便备份、多机协作或者只是图个安心。你会写一点代码，但 Git 可能只在别人电脑上见过，或者用过一两次但没搞明白背后的机制。我会把从零开始的完整路径走一遍，包括那些文档里不会写、但实际一定会卡住的细节——比如网络认证怎么配、提交时不小心把编译产物也带进去了怎么办、分支推错了怎么退回来。

需要提前说明的是，下面的配置组合是我实测下来在 Mac 上最省心的一套：CLion 内置的 Git 集成 + 系统自带的凭据管理 + 远程仓库的 SSH 或 HTTPS 两种协议。这个组合的好处是不依赖任何第三方图形客户端，装完 CLion 就能干活，配置一次之后长期有效。

提示：下文所有涉及账号名、仓库地址的地方都用占位形式表示，你在操作时替换成自己的实际信息即可。远程仓库的注册过程本文不涉及，默认你手上已经有一个可用的账号和一个新建的空仓库。

2. 开工前的三件准备：CLion、Git、远程仓库

2.1 先确认 Mac 上到底有没有装 Git

Mac 有个历史遗留问题：系统自带的 Git 往往是 Apple 为了 Command Line Tools 附带的版本，路径藏在/usr/bin/git，版本可能偏老。而你后续如果想用一些新特性，或者在 CLion 里遇到奇怪的兼容问题，第一步都该先查清楚当前的状态。

打开终端，敲：

git --version

正常会返回类似git version 2.39.3 (Apple Git-145)这样的输出。有输出就说明能用，没输出或者弹出一个要求安装开发者工具的对话框，那就得先处理掉。我建议不要用系统自带的那个，而是通过包管理器重新装一份独立的，路径通常在/opt/homebrew/bin/git（Apple Silicon）或/usr/local/bin/git（Intel 芯片）。原因很实际：系统自带的 Git 会跟着系统更新走，有时候版本忽高忽低，出问题时排查起来特别绕。

装完之后再跑一次which -a git，如果列出来两个路径，需要确认 CLion 用的是哪一个。这一步看着多余，但我确实遇到过 CLion 调用的是老版本 Git、导致某些操作报出莫名其妙错误的情况。

2.2 CLion 里的 Git 路径要显式指定

CLion 默认会自动探测 Git 可执行文件的位置，多数情况下探测是对的。但我建议手动确认一遍，位置在Settings → Version Control → Git，里面的 "Path to Git executable" 一栏。

点一下旁边的 "Test" 按钮，如果弹出绿色的版本号提示，说明通了。如果报红，把上面which git拿到的完整路径手动填进去。这里有个细节：填目录是没用的，必须填到可执行文件本身，比如/opt/homebrew/bin/git，而不是/opt/homebrew/bin。我第一次就是填了目录，结果一直提示找不到。

同时在这个页面把 "SSH executable" 也看一眼，默认是 Built-in，可以保持不动，但如果你后面打算用 SSH 协议连远程仓库，且系统里的 SSH 配置比较复杂（比如有自定义的 config 文件），可能需要切到 Native。这一项的影响我放到第 4 节细说。

2.3 全局身份必须先配，否则第一次提交就卡住

Git 每次提交都会记录提交者的名字和邮箱。这两个信息如果没配，CLion 点提交按钮时会直接弹错误，而且提示语比较隐晦，不容易一眼看出是身份没配。

在终端里执行：

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

邮箱建议和远程仓库账号绑定的邮箱保持一致，这样提交记录在网页端能正确关联到你的头像和账号。名字随便取，会出现在每一次提交记录里。

配完用git config --global --list验证一下。这里有个容易踩的点：如果你之前配过但打错了字，--global不会覆盖已有的键值，得先git config --global --unset user.email再重新设。我见过有人反复执行设置命令却始终不生效，就是卡在这里。

另外有个可选项值得一配——换行符处理。Mac 下默认是 LF，Windows 是 CRLF，如果你的项目可能被别人在 Windows 上打开，建议设一下：

git config --global core.autocrlf input

这个值的含义是：提交时把 CRLF 转成 LF 存进仓库，检出时不转换。这样仓库里的文件永远是干净的 LF，不会因为换行符差异产生整文件级别的假改动。这个坑我在跨平台协作时踩过一次，一次提交显示改了八百多行，实际只是换行符。

3. 把本地工程变成 Git 仓库：CLion 里的初始化动作

3.1 从已有工程出发的正确方式

假设你已经在 CLion 里打开了一个 C 或 C++ 工程，目录结构大概长这样：

my-project/ ├── CMakeLists.txt ├── src/ │ └── main.cpp └── cmake-build-debug/

这时候点菜单VCS → Enable Version Control Integration，弹窗里选择 Git，确定。CLion 会在项目根目录执行git init，同时界面右下角出现一个 Git 分支标记，左侧项目树里的文件名开始变色——红色代表未跟踪，绿色代表已暂存，蓝色代表已修改。

这个操作的本质就是一次git init。它做的事很轻：在项目根目录创建一个.git隐藏文件夹，里面存放所有版本信息。想验证的话，在终端里cd到项目根目录，执行git status，会看到一长串 "Untracked files"。

3.2 第一步该做的其实不是提交，是写忽略规则

新手最容易犯的错误就在这里：git init之后兴奋地全选、提交，结果把cmake-build-debug/这个编译输出目录（可能有几百兆的中间文件）、.idea/这个 CLion 自己的配置目录，甚至本地的数据库文件、日志文件一起塞进了仓库。推上去之后仓库体积暴涨，别人拉下来一片混乱。

所以初始化之后的第一件事，是在项目根目录建一个.gitignore文件。CLion 自己会提示你创建，也可以手动建。针对 C/C++ 项目，一份够用的规则是这样：

# CLion 与 CMake 产物 cmake-build-*/ .idea/ CMakeCache.txt CMakeFiles/ # 编译输出 *.o *.obj *.a *.so *.dylib *.exe build/ # 系统文件 .DS_Store # 本地配置 .env *.local

逐条说一下为什么这么写，这些不是抄来的模板，每一条都对应一个实际问题。

cmake-build-*/用通配符而不是写死cmake-build-debug，是因为 CLion 会根据构建类型生成cmake-build-debug、cmake-build-release、cmake-build-relwithdebinfo等不同目录，写死一个就会漏。.idea/里存的是 CLion 的窗口布局、运行配置、代码风格设置，这些属于个人偏好，不应该污染公共仓库——但要注意，如果你在.idea里放了团队共享的运行配置（比如统一调试参数），那就得反向处理，把.idea加回来再排除其中个人化的子项。这个取舍我放到第 6 节展开。

*.o、*.a、*.dylib这些是编译中间产物和动态库，Mac 上尤其要注意.dylib和.DS_Store。后者是 Finder 访问目录时自动生成的隐藏文件，不带任何信息量，混进提交记录里非常碍眼。

.gitignore本身也要提交进去，这是团队约定的载体。

3.3 一个必须知道的事：忽略规则对已跟踪文件无效

这条我单独拎出来说，因为它是新手最常遇到的"我明明写了 ignore 为什么没用"的原因。

.gitignore只对尚未被 Git 跟踪的文件生效。如果某个文件已经被git add过（哪怕还没提交），之后再往.gitignore里加规则，Git 会继续跟踪它，规则形同虚设。

解决办法是先把文件从索引里移除，但不删本地文件：

git rm -r --cached cmake-build-debug/ git rm -r --cached .idea/

--cached这个参数是关键，它只动索引不动磁盘。执行完再git status，会看到这些文件变成"deleted"状态（从索引删除）同时又出现在 Untracked 列表里，此时.gitignore就生效了。

注意：这一步的顺序很重要。先写好.gitignore，再执行git rm --cached，最后一起提交。如果顺序反了，中间那一次提交会记录一次删除，看起来像你把文件删了，实际上文件还在本地，只是历史记录里多了一次无意义的变更。

3.4 CMakeLists.txt 与 .idea 的取舍判断

这里展开说一下上面提到的取舍。C/C++ 项目和纯脚本项目不一样，它的构建系统配置文件CMakeLists.txt必须提交，因为那是工程的定义。而.idea/目录里的东西要分情况：

如果你确实要提交.idea里的部分内容，写法是先在.gitignore里忽略整个目录，再用取反规则放行特定子项：

.idea/* !.idea/runConfigurations/ !.idea/codeStyles/

注意取反规则的父目录不能被整体忽略，否则取反无效——所以这里写的是.idea/*而不是.idea/。这个细节很多人不知道，写成了.idea/然后疑惑为什么!那行不生效。

4. 连接远程仓库：HTTPS 和 SSH 到底选哪个

4.1 两种协议的实质差别

远程仓库提供两种访问方式，地址格式不同：

• HTTPS：https://域名/用户名/仓库名.git
• SSH：git@域名:用户名/仓库名.git

新手常问选哪个。我的答案是：如果你会经常推送，用 SSH；如果只是偶尔提交，或者身处网络环境对端口有限制的地方，用 HTTPS。

差别的核心在认证方式。HTTPS 每次推送都要验证身份，早期是输账号密码，现在主流平台都改成了访问令牌（Personal Access Token），也就是一串你自己生成的、有有效期和权限范围的字符串，用它代替密码。好处是不涉及密钥管理，坏处是令牌过期后推送会突然失败，而且要把令牌存起来免得每次输入。

SSH 用的是密钥对：本地生成一把私钥和一把公钥，公钥交给你在远程仓库的账号，之后每次连接由系统自动完成验证，全程无需输入。配好一次，长期有效，这是它的最大优势。

4.2 SSH 方式的完整配置流程

先生成密钥对。终端执行：

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

-t ed25519指定算法，比老的 RSA 更短更快，现在的主流平台都支持。执行后会问三件事：保存路径（直接回车用默认的~/.ssh/id_ed25519）、密码短语（可以留空，也可以设一个增加安全性）、确认密码短语。

留空密码短语意味着任何人拿到你的电脑就能推代码，但对个人开发机来说通常可以接受。如果设了密码短语，每次推送都要输一次，可以配合系统的钥匙串记住，Mac 下用这个命令把它加进去：

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

注意 macOS 不同版本这个参数名有变化，老版本是-K，新版本是--apple-use-keychain。如果报"unknown option"，换成-K试试。

生成完，把公钥内容复制出来：

cat ~/.ssh/id_ed25519.pub

输出的是一行以ssh-ed25519开头的字符串。把它完整复制，粘贴到远程仓库账号设置的 SSH 公钥页面里，保存。

验证是否通了：

ssh -T git@你的代码托管服务域名

返回类似 "Hi 用户名! You've successfully authenticated" 就说明成了。第一次连接会问是否信任主机指纹，输yes。

4.3 在 CLion 里绑定远程地址

回到 CLion，菜单Git → Manage Remotes（不同版本可能叫 Remotes），点加号，Name 填origin（这是惯例名，不是强制的，但建议遵守），URL 填你的仓库地址。

填完点 OK，CLion 会尝试读取远端信息。如果地址写错或者认证不通，这里会直接报错——这其实是个好处，能在推送前就发现问题。

另一种更省事的做法是在终端里直接加：

git remote add origin git@域名:用户名/仓库名.git git remote -v

后者会列出当前配置的所有远端，方便确认没加重复。

4.4 HTTPS 方式的令牌配置细节

如果你选 HTTPS，重点在于令牌的生成。在远程仓库的账号设置里找"访问令牌"或"私人令牌"相关入口，创建一个新的，权限范围至少要勾选仓库的读写。生成的字符串只显示一次，务必当场复制保存。

第一次推送时终端会提示输入用户名和密码，用户名填账号名，密码位置粘贴令牌。Mac 的钥匙串会自动记住，之后不再询问。

如果之前保存过错误的凭据导致一直认证失败，可以清掉重来：

git credential-osxkeychain erase host=你的代码托管服务域名 protocol=https

输入这两行后按两次回车，凭据就被清除了。

提示：令牌通常有有效期。设得太短会频繁失效，设成永不过期又有安全风险。我的做法是设一个较长周期，在日历里加个提醒，到期前主动续。这样不会在赶进度的时候突然推不上去。

5. 提交与推送：把改动真正送出去

5.1 CLion 的提交流程与它的"隐藏动作"

改动完成后，CLion 顶部菜单Git → Commit，或者用快捷键打开提交窗口。左侧是变更文件列表，右侧是差异对比，中间是提交信息输入框。

这里有三个复选框，含义差别很大，必须搞清楚：

• Commit：只提交到本地仓库，不联网
• Commit and Push：提交后立即推送
• Commit and Push... （带省略号）：提交后弹出推送确认窗口

新手容易点成只 Commit，然后以为代码已经上传了，结果换台机器拉不到。实际上本地提交完成的只是"记录"这一步，代码还在你自己的.git文件夹里，没有离开过这台电脑。这个区分在 Git 的设计里是核心——本地仓库和远程仓库是两个独立的实体，提交是前者的事，推送是连接两者的动作。

提交信息（Commit message）怎么填，我建议第一行写一句不超过 50 字的概括，空一行，下面写详细说明。例如：

修复矩阵乘法在边界尺寸下的越界读 当矩阵维度不能被分块大小整除时，尾部处理逻辑会读取 超出缓冲区的数据。改为对尾部单独走一次标量循环。

这个格式不是形式主义。第一行是摘要，很多工具（包括 CLion 的日志视图）只显示这一行，所以它必须能独立说明问题。空行是分隔符，Git 靠它区分标题和正文。

5.2 推送分支与"上游"概念

点 Push 之后，CLion 会弹出窗口让你确认推送的目标。第一次推送时通常会出现一个选项叫 "Set upstream" 或 "Push to origin/master"（分支名可能是main）。

"上游"（upstream）这个概念值得解释一下。它指的是本地分支与远程分支的对应关系。设好之后，以后在这个分支上直接点 Push 就会推到对应位置，不用每次选目标；同时 CLion 底部状态栏会显示本地领先远程几个提交、落后几个，方便判断是否需要拉取。

第一次推送时的命令等价于：

git push -u origin main

-u就是设置上游。如果分支名和远程不一致，需要写成git push -u origin 本地分支名:远程分支名。

如果远程仓库是新建的空仓库，第一次推送顺利。但如果仓库里已经有内容（比如创建时勾选了自动生成说明文件），推送会被拒绝，提示 "Updates were rejected"。原因是你本地没有远程的那段历史，Git 不允许直接覆盖。这种情况下得先拉取合并：

git pull origin main --allow-unrelated-histories

--allow-unrelated-histories这个参数在处理两个独立历史合并时必须加，否则 Git 会因为找不到共同祖先而直接拒绝。合并后可能产生冲突，需要手动解决再提交一次。这个坑很多人都踩过，尤其是在网页上先建了仓库再回来推代码的时候。

5.3 推送失败时的排查顺序

推送报错的情况不少，按这个顺序查基本能覆盖九成：

我在实际工作中最常遇到的是第二类。用 HTTPS 时令牌到期往往毫无征兆，前一天还好好的，第二天推送直接失败，报错信息又不明确指向"令牌过期"。所以我现在的习惯是：只要 HTTS 推送突然认证失败，第一反应就是去检查令牌状态，而不是怀疑网络。

第一类的Permission denied也有个隐蔽变体：密钥文件权限过宽。SSH 对私钥权限有严格要求，如果~/.ssh/id_ed25519的权限是 644（所有人可读），SSH 会直接拒绝使用。修法是：

chmod 600 ~/.ssh/id_ed25519 chmod 700 ~/.ssh

这两个权限值记一下：私钥 600（只有自己能读写），.ssh目录 700（只有自己能进入）。

6. 那些文档里不会写的实际操作细节

6.1 大文件与历史体积：一次真实的教训

我之前接手一个项目，需要把一个带测试数据的工程推上去。数据里有几个几十兆的二进制文件，直接提交了。当时没觉得有问题，推送也成功了。但随着后续每次修改，仓库体积持续膨胀——因为 Git 保存的是每个版本的完整快照，改动一个字节，整个文件都会再存一份。等到仓库涨到几百兆，新同事克隆时卡了十几分钟，我才意识到问题。

如果你的项目里确实有必须版本化的二进制资源（测试数据、素材、预编译库），正确的做法是用 Git LFS（大文件存储），它用一个指针文件代替真实内容，内容单独存放。CLion 对 LFS 的支持需要在设置里手动开启，路径在Settings → Version Control → Git里找 LFS 相关选项。

git lfs install git lfs track "*.bin" git lfs track "data/*.dat"

git lfs track会在.gitignore同级生成一个.gitattributes文件，那个文件必须提交。另外要注意，LFS 是对未来的提交生效的，已经进了历史的旧文件不会自动转过去，需要额外的历史重写操作，风险较高，建议在项目早期就把规则定好。

判断一个文件该不该进 LFS 的经验法则：文本文件走普通 Git，二进制文件超过 1MB 就该考虑 LFS。图片、音频、模型文件、编译好的库都属于后者。

6.2 branch 命名与初始分支的坑

新版本的 Git 默认初始分支名是main，但一些老版本或者某些平台的默认设置仍然是master。如果你的本地是main、远程空仓库默认是master，第一次推送会创建两个不同名的分支，界面上看起来很乱。

统一的做法是创建仓库时就确认默认分支名，本地和远程保持一致。如果已经不一致了，可以重命名本地分支：

git branch -m master main

然后推上去并设置上游。远程那边如果有旧的master分支，在网页端删掉即可。

分支命名本身也值得规范一下。我用的约定是：功能开发用feature/简短描述，修 bug 用fix/问题简述，紧急修复用hotfix/...。好处是日志视图里一眼能看出每个分支的意图，CLion 的分支列表也会按前缀自动分组。

6.3 提交前该不该格式化代码

CLion 自带代码格式化，快捷键是Cmd + Option + L。我强烈建议养成习惯：提交前先格式化，并把格式化单独作为一个提交。

为什么单独提交？因为格式化会改动大量行的空白和缩进，如果和逻辑改动混在同一个提交里，后续用git blame查某行为什么被改时，看到的全是格式化提交，真正的逻辑变更被淹没。分开提交之后，格式化提交可以标记为style: 统一缩进与括号风格，review 时直接跳过，逻辑提交则干净清晰。

CLion 还能配置提交前的自动检查（Settings → Version Control → Commit），比如运行代码检查、清理未使用的头文件。这些我建议开启，但别开太多，否则每次提交等很久，反而会让人绕过它。

6.4 撤销的本事比提交的本事更重要

真正区分熟练度的不是会不会推，而是推错了能不能救回来。几个高频场景：

提交了但还没推送，想改提交信息：

git commit --amend -m "新的提交信息"

提交了但还没推送，想撤掉这次提交保留改动：

git reset --soft HEAD~1

--soft表示只回退提交记录，工作区的改动原样保留，可以改完再重新提交。

已经推送了，发现漏了一个文件：别用reset再强推，那样会改写公共历史。正确做法是补一次提交：

git add 漏掉的文件 git commit --amend --no-edit git push --force-with-lease

严格说 amend 后强推也改写了历史，但--force-with-lease比--force安全得多——它会在远程有你不知道的新提交时拒绝执行，避免覆盖别人的工作。这个参数值得记住，用它替代--force几乎不会有坏处。

想撤销某一次已推送的提交（保留历史，生成一个反向提交）：

git revert 提交哈希

CLion 里这些操作都有图形入口，位置在Git → 日志打开的历史视图里，右键某个提交能看到 Revert、Reset 等选项。我建议先用命令行理解每个操作做了什么，再回到图形界面用，否则很容易点错。

6.5 CLion 图形界面与命令行的分工

用久了会发现，两者各有不可替代的场景。我的分工是：

冲突解决这一项特别值得说。CLion 的三栏合并界面（左边你的、右边对方的、中间结果）是我用过最顺手的之一，能逐块选择接受哪边，还能看到每一块的来源。命令行解决冲突要手动编辑那些<<<<<<<标记，容易出错。所以遇到冲突我一定切回 CLion。

反过来，git rebase -i这种交互式操作，图形界面虽然有，但展示的信息量不如命令行完整。在终端里看到一个提交列表，逐行改pick为squash，心里更有数。

7. 团队协作时才暴露的几个问题

7.1 拉取方式：merge 还是 rebase

多人协作时，你推送前必须先整合别人的改动。CLion 在Settings → Version Control → Git里有一项 "When update: Merge / Rebase"，决定默认用哪种方式。

merge会生成一个合并提交，历史里能看到两条线汇合；rebase会把你的提交"搬"到对方提交之后，历史是一条直线，更整洁但改写了本地提交的哈希。

团队里如果没有明确约定，我倾向选 rebase，但有个前提：只 rebase 自己本地的、还没推送的提交。已经推上去的提交再 rebase 会导致别人拉取时历史不一致，这是协作中的大忌。

如果选了 rebase 又遇到冲突，处理起来比 merge 麻烦：rebase 过程中冲突要一个个提交地解决，中途想放弃得用git rebase --abort。CLion 会在冲突时弹出一个专门的工具栏，有 Continue、Abort、Skip 三个按钮，比命令行提示清楚。

7.2 提交粒度：小步提交的实际好处

这一点在单人项目里感受不明显，一旦有协作就立刻体现。假设你一次提交改了三十个文件、涉及三个功能，别人 review 时无从下手，出问题想定位也难。反过来，如果每完成一个小功能就提交一次，每个提交只动几个文件、信息写得清楚，好处是：

• review 时按提交逐个看，逻辑连贯
• 出问题时用git bisect二分定位，很快能找到引入 bug 的那次提交
• 需要回滚某个功能时，直接 revert 那一个提交，不影响其他

git bisect这个工具值得了解一下，它通过二分查找在提交历史里定位问题引入点。用法是先标记一个好的提交和一个坏的提交，然后它会不断检出中间的提交让你验证，几次之内就能锁定。提交粒度越细，这个工具越好用——如果每个提交都巨大，二分几次就没法继续了。

7.3 忽略文件的团队一致性

.gitignore提交进仓库后，团队所有人共享同一份规则，这是好事。但有个细节：每个人本地可能还有自己的临时文件（比如某个调试脚本、本地数据库），这些不该进公共的.gitignore。

Git 提供了.git/info/exclude文件，作用范围仅限本地，不随仓库分发。个人的临时忽略规则写这里最合适。CLion 的提交窗口里，右键某个未跟踪文件会看到 "Add to .gitignore" 和加入本地排除两个选项，后者就是写进exclude。

另一个容易忽略的点：.gitignore修改后需要提交才会对团队生效。我见过有人本地改了 ignore 规则，自己那边看着正常，别人拉下来还是被那些文件干扰，原因就是忘了提交这个改动。

8. 从能用到好用：几条沉淀下来的习惯

配置完成后，日常使用中真正影响体验的往往不是那些大功能，而是一堆小习惯。这里挑几条我觉得收益最高的说说。

第一条是推送前必看差异。CLion 提交窗口右侧的差异视图，我每次都会扫一眼，重点看有没有误加的文件、有没有调试用的输出语句忘了删、有没有把本地路径硬编码进去。这个动作花不了十秒，但拦下的问题不少。有一次我差点把一个写死了本机绝对路径的配置文件推上去，就是在这个视图里发现的。

第二条是提交信息写"为什么"而不是"改了什么"。差异本身已经说明了改什么，提交信息该交代的是动机。写"修复空指针"不如写"修复空指针：当配置项缺失时未做判空，导致启动崩溃"。半年后回来看，后者能让你立刻想起当时的上下文。

第三条是定期检查仓库健康度。隔一段时间跑一下git count-objects -vH，看看仓库体积。如果发现异常膨胀，多半是误提交了大文件，趁早处理。CLion 里看不到这个信息，得用命令行。

第四条是别在main分支上直接开发。哪怕是一个人做的小项目，也建议开分支写，写完合并。理由不是形式，而是给自己留一条退路——main上永远是能跑的版本，实验性的改动在分支里折腾，折腾坏了直接删分支，主线上干干净净。

最后一条，也是最实际的一条：配置这东西，配完立刻验证一次端到端流程。写完代码、提交、推到远程、在网页端确认能看到、换一个空目录重新克隆下来、编译通过，这一整圈走一遍，才算真的配好了。我见过太多"配置完了"但没验证，等到真正需要同步时才发现某个环节不通的情况。整套流程跑通一次，后面就都是复制粘贴的事了。