git 学习，小白第一次学习

文章目录

    • git安装
    • git的配置
    • git的一些基本理论
    • git项目的搭建
      • 创建工作目录与常用的指令
      • 本地仓库搭建
      • git文件操作
        • 文件的四种状态
        • 查看文件状态
        • 忽略文件
      • 生成ssh秘钥
    • 将本地仓库的文件提交到远程仓库
    • idea上集成git
    • git的分支
    • .github/
      • 目录结构
      • 1. dependabot.yml
      • 2. ci.yml（最重要）
      • 3. copilot-setup-steps.yml
      • 4. mcp-diff.yml
      • 5. remote-mcp-diff.yml
      • 6. release.yml
      • 整个流程举例

git安装

盲选下一步就可以了，安装路径可以自定义选择，比如我的安装路径是D:\git\install\Git

git卸载其实就是git的反安装，首先删除git的环境变量（如果有的话），然后就在控制面板上直接删除就可以了。

git的配置

git 的配置都是在git的安装目录下相关的配置文件里面，也就是git的配置本质上是git的一些读写文件而已

git的相关配置文件的路径

（1）系统配置，是在安装路径/etc/gitconfig文件下，如D:\git\install\Git\etc

（2）用户配置（global），在个人用户路径下/.config，如C:\Users\Administrator/.config

#查看系统的config git config --system --list #查看当前用户（global）配置 git config --global --list #配置自己的用户名 git config --global user.name "your name" #配置自己的邮箱 git config --global user.email "your email"

git也可以直接配置环境变量，但是配置环境变量是在为了能够在全局使用，但是只要正确安装好git，鼠标右键就可以在任意地方打开git，而且git默认会在path中配置环境变量的。

git的一些基本理论

git本地上有三个工作区域：工作目录(Working Directory)、暂存区(Stage/index)、资源区(Repository/Git Directory)。加上远程的git仓库(Remote Direcyory)的话可以分为四个，转换关系如下：

Working Directory：工作区，平时存放项目代码的地方

Stage/index：暂存区，用来临时存放改动的，它的本质是一个文件，保存即将提交的文件列表信息，看不到

Repository/Git Directory：仓库区，安全存放数据的位置，这里有提交的所有版本的数据，其中HEAD指向最新放入仓库的版本

Remote Direcyory：远程仓库，托管代码的服务器，比如说github、gitee

git的工作流程

  1. 在工作目录中添加、修改文件；
  2. 将需要进行版本管理的文件放入暂存区域；git add .
  3. 将暂存区域的文件提交到git仓库；git commit

因此，git管理的文件有三种状态：已修改(modified)，已暂存(staged)，已提交(committed)

git项目的搭建

创建工作目录与常用的指令

工作目录(Working Directory)一般的都是帮助管理的文件夹，可以是项目的目录，也可以是一个空目录，建议不要有中文

本地仓库搭建

创建本地仓库有两种方法：一种是创建全新的仓库，另一中是克隆远程仓库

  1. 创建全新的仓库，需要到git管理项目的根目录执行
#在当前目录上创建一个git代码库 git init

执行之后就会看到项目多了一个.git的隐藏文件，所有的版本信息都在这个目录上

  1. 克隆远程仓库，就是将远程服务器上仓库完全镜像到本地
#克隆一个项目和他的整一个代码历史（版本信息） git clone [url]

我们可以去gitee或者github克隆一个进行测试。

git文件操作

文件的四种状态

  • untracked：未追踪，此文件在文件夹中，并没有加入到git库，不参与版本控制，可以使用git add filename转变成staged。

  • unmodify：文件已经入库，没有修改，也就是版本库中的文件快照内容和文件夹中完全一致，这种类型的文件有两种去处，如果它被修改，变成modified，如果使用git rm就会变成untracked文件。

  • modified：文件已经被修改，仅仅只是修改，并没有进行其他的操作，这种文件也有两种去处，一种是通过git add filename可以进去到暂存staged状态，使用git checkout则丢弃修改过，返回到unmodify状态，这个git checkout就是从库中提取文件，覆盖当前修改。

  • staged：暂存状态，执行git commit就修改同步到库中，这时候库的文件和本地文件又变为一致，文件为unmodify状态执行git reset HEAD filename取消暂存，文件变成modifiled。

查看文件状态
#查看文件状态 git status [filename] #追踪文件，添加文件到暂存区 git add filename/. #提交暂存区内容到本地仓库，-m是提交信息 git commit -m "消息内容"
忽略文件

我们有一些文件不需要纳入到版本控制中，就可以在主目录中创建.gitignore文件，这个文件的规则如下：

  1. 忽略文件中的空行，或者#号开始的行。
  2. 可以使用Linux的通配符，*星号代表任意多的字符，？问号代表一个字符，[]方括号代表可选字符范围，{}花括号代表可选的字符串。
  3. 如果名称前面有一个感叹号！表示例外，不会被忽略。
  4. 如果名称前面是一个路径分隔符/，表示要忽略的文件在这个目录下，但是子目录中的文件不会被忽略。
  5. 如果名称最后面是一个路径分隔符/,表示要忽略的是这个目录下这个名称的子目录，而不是文件（默认是文件或者目录都忽略）。
*.txt #忽略所有的.txt结尾的文件，这样上传是不会被选中的 !lib.txt #但是lib.txt除外 /temp #仅仅忽略项目根目录下的TODO文件，不包括其他目录temp build/ #忽略build/目录下的所有文件 doc/*.txt #忽略doc/notes.txt但是不包括doc/server/arch.txt

生成ssh秘钥

#进入到C:\Users\Administrator\.ssh目录 #生成公钥 ssh-keygen

把生成的秘钥直接就复制到github或者gitee就可以了。这样就实现把远程仓库和本地仓库绑定在一起

将本地仓库的文件提交到远程仓库

如果是有新内容更新的，都需要进行git init操作

git init git add . git commit -m git push

idea上集成git

  1. 新建项目，绑定git（最简单就是在新建的项目中，把本地上已经绑定了git的文件直接复制过来就可以了）
  2. 修改项目，使用idea操作git
    idea上集成了git的所有命令，可以使用命令行打开，也可以直接在idea图形界面上打开

git的分支

#查看本地仓库所有的分支gitbranch#查看远程仓库所有的分支gitbranch-r#新建一个分支，新建成功后，当前还是停留在master分支上gitbranch[branchName]#新建一个分支，并且跳转到这个分支中去gitcheckout-b[branch-name]#合并分支gitmerge[branch]#删除分支gitcheckout-d[branch-name]#删除远程分支gitpush origin--delete[branch-name]

master分支一般都比较稳定，是用来发布新版本的，建议不要在上面进行开发，一般开发的时候新建dev项目，等项目开发稳定后合并到master上就可以发布了。

.github/

.github/是 GitHub 仓库的"自动化配置中心"。

它和你的 MCP Server 本身没有关系，而是控制GitHub 网站在什么时候自动帮你做什么事情。

目录结构

一般长这样：

.github/ ├── dependabot.yml └── workflows/ ├── ci.yml ├── release.yml ├── mcp-diff.yml ├── remote-mcp-diff.yml └── copilot-setup-steps.yml

其中：

  • dependabot.yml：属于 Dependabot 配置。
  • workflows/：属于 GitHub Actions 工作流。

1. dependabot.yml

例如：

package.json express 4.18 ↓ express 4.20 发布

Dependabot 每周自动检查：

package.json package-lock.json GitHub Actions

发现：

express 有新版本

它会自动创建一个 PR：

Update express to 4.20

你只需要点 Merge。

作用：自动升级依赖。

2. ci.yml（最重要）

CI = Continuous Integration（持续集成）。

例如有人提交代码：

git push

GitHub 自动运行：

npm install npm run lint npm run build npm test

如果：

✓ build 成功 ✓ test 成功

PR 就显示绿色 ✔。

否则：

❌ Build Failed

别人不能合并。

所以：

CI 就是自动帮你检查代码有没有问题。

3. copilot-setup-steps.yml

这是 GitHub Copilot Agent 使用的。

Copilot 在云端帮你修改代码时，需要知道：

怎么安装依赖？

于是执行：

npm install

或者：

pnpm install

所以：

这是给 Copilot 准备开发环境。

普通开发者一般不用管。

4. mcp-diff.yml

这个比较特殊。

你的 MCP Server 可能昨天有：

Tool A Tool B

今天改完以后：

Tool A Tool C

GitHub 可以自动检测：

Tool B 被删了

或者：

Schema 改了

它会告诉你：

MCP Capability Changed

这样避免：

客户端突然不能用了

所以：

它是检查 MCP 接口变化。

5. remote-mcp-diff.yml

上面那个检查的是：

本地代码

这个检查的是：

已经部署到服务器上的 MCP

例如：

https://mcp.example.com

GitHub 自动：

连接服务器 ↓ 获取 Tool List ↓ 和仓库中的 Tool 对比

发现：

服务器少一个 Tool

就报警。

  1. mcp-diff（内部代码审查员）：
    • 检查对象：纯粹针对 GitHub 仓库里的代码。
    • 作用：每次代码合并时，对比新旧代码。比如发现开发者在代码里删了一个工具（Tool B），它就会在代码层面发出警告，提醒团队注意。
  2. remote-mcp-diff（线上环境验收员）：
    • 检查对象：GitHub 仓库里的代码VS公网上真实运行的 MCP Server。
    • 作用：拿着仓库里的“标准图纸”，去公网服务器上“对实物”。如果发现代码里明明写了 Tool C，但公网服务器上的工具列表里却没有，它就会立刻报警，说明“代码没部署成功”或者“线上环境出了问题”。

一句话总结：
mcp-diff确保的是**“代码变更被记录”，而remote-mcp-diff确保的是“线上服务与代码保持绝对一致”**。这两个机制配合在一起，就能完美保障 AI 客户端调用的工具永远是最新且正确的！

6. release.yml

例如：

你执行：

git tag v1.0.0 git push origin v1.0.0

GitHub 自动：

Build ↓ 打包 ↓ 生成 Release ↓ 上传 zip ↓ 发布 v1.0.0

于是别人看到：

Release v1.0.0 Download ZIP Release Notes

不用你手工创建。

整个流程举例

假设你今天写了一段代码：

git add . git commit git push

GitHub 会自动执行：

收到 push ↓ ci.yml ↓ npm install ↓ lint ↓ build ↓ test ↓ 全部通过 ↓ 允许 Merge

如果你后来发布版本：

git tag v1.2.0 git push origin v1.2.0

又会自动：

release.yml ↓ 创建 Release ↓ 上传文件 ↓ 发布版本
开发 ↓ 提交代码 ↓ 自动检查（CI） ↓ 自动测试 ↓ 自动发布 ↓ 自动升级依赖 ↓ 自动生成 Release ↓ AI 辅助开发