git bash|下载、安装与配置(Windows11)

git bash|下载、安装与配置(Windows11)

序言

Git 是一个 分布式版本控制系统(DVCS),用于高效、可靠地跟踪文件(尤其是代码)的变更历史。它由 Linus Torvalds 于 2005 年创建,最初是为了管理 Linux 内核开发而设计。


🌟 核心特点

  1. 分布式
    每个开发者本地都拥有完整的代码仓库(包括全部历史记录),不依赖中央服务器也能提交、分支、合并等操作。
  2. 高性能
    Git 在处理大型项目时依然快速,无论是提交、切换分支还是合并,都经过高度优化。
  3. 数据完整性
    Git 使用 SHA-1 哈希值标识每次提交和文件内容,确保历史记录不可篡改(“内容寻址”存储)。
  4. 强大的分支与合并
    创建、切换、合并分支非常轻量快捷,鼓励基于分支的开发流程(如 Git Flow、GitHub Flow)。
  5. 开源 & 免费
    Git 是自由软件,广泛应用于个人项目、企业开发和开源社区。

🧩 基本概念

表格

术语说明
Repository(仓库)存储项目所有文件及其历史的地方
Commit(提交)一次快照,记录文件在某个时间点的状态
Branch(分支)独立的开发线,主分支通常叫 main 或 master
Merge(合并)将一个分支的更改整合到另一个分支
Remote(远程仓库)托管在服务器上的仓库(如 GitHub、GitLab)
Clone / Pull / Push克隆(下载整个仓库)、拉取(获取更新)、推送(上传更改)

💡 常用命令示例

1# 初始化新仓库 2git init 3 4# 克隆远程仓库 5git clone https://github.com/user/repo.git 6 7# 查看状态 8git status 9 10# 添加文件到暂存区 11git add . 12 13# 提交更改 14git commit -m "描述本次修改" 15 16# 推送到远程 17git push origin main 18 19# 拉取最新代码 20git pull origin main 21 22# 创建并切换分支 23git checkout -b feature-x

🌐 与 GitHub/GitLab 的关系?

  • Git 是本地使用的工具(命令行程序)。
  • GitHub / GitLab / Gitee 是基于 Git 的 代码托管平台,提供远程仓库、协作、CI/CD、Issue 跟踪等功能。
  • 你可以只用 Git(不联网),也可以配合平台实现团队协作。

✅ 为什么开发者都要学 Git?

  • 回溯任意历史版本(“后悔药”)
  • 多人协作不冲突
  • 实验新功能不影响主代码(用分支)
  • 开源贡献的标准工具
  • 几乎所有现代开发流程的基础

📌 简单说:Git = 代码的时间机器 + 协作引擎

如果你刚开始学习,推荐使用 GitHub Desktop 或 Sourcetree 图形工具辅助理解,再逐步过渡到命令行。

本篇主要讲是 Git 在 Windows 系统上的完整安装与配置教程


📥 一、下载 Git

1、前往官方地址下载最新版:
🔗 https://git-scm.com/download/win

✅ 推荐下载 64-bit Git for Windows Setup

2、windows-2.52.0版本下载链接,可复制到第三方下载(大约63M)



⚙️ 二、安装 Git

1. 启动安装程序(多图)

双击下载的 .exe 文件(如 Git-2.52.0-64-bit.exe

  • 默认:C:\Program Files\Git
  • 我改成:F:\ProgramFiles\Git

1、select componet页面解释:

选项是否建议勾选说明
✅ Additional icons✅ 建议勾选在桌面添加 Git 快捷方式
➡️ On the Desktop✅ 建议勾选添加到桌面图标
✅ Windows Explorer integration✅ 推荐勾选右键菜单中添加 Git 功能
➡️ Open Git Bash here✅ 强烈推荐右键 → “在此处打开 Git Bash”
➡️ Open Git GUI here❌ 可不勾选图形界面,新手用不到
✅ Git LFS (Large File Support)✅ 推荐勾选支持大文件版本控制(如视频、模型)
✅ Associate .git* configuration files with the default text editor✅ 推荐勾选.gitignore.gitconfig 用默认编辑器打开
✅ Associate .sh files to be run with Bash✅ 推荐勾选.sh 脚本可直接运行(Linux 风格)
❌ Check daily for Git for Windows updates❌ 不推荐每天检查更新会弹窗打扰
❌ Add a Git Bash Profile to Windows Terminal⚠️ 视情况而定如果你用 Windows Terminal,可以勾选;否则不用
✅ Scalar (Git add-on to manage large-scale repositories)✅ 推荐勾选大项目管理工具,适合团队协作

2、📊 Git 默认编辑器对比表

编辑器优点缺点适用人群
✅ Use Notepad++ as Git's default editor- 中文支持好
- 界面简洁易用
- 轻量级,启动快
- 支持语法高亮
- 功能不如 VS Code 强大
- 不支持插件扩展(部分版本)
Windows 新手、轻量级用户
❌ Use Nano by default- 简单易学
- Linux 命令行常用
- 无图形界面
- 仅适合终端环境
- Windows 上基本不用
Linux 用户、极简主义者
❌ Use Vim as Git's default editor- 强大、可高度定制
- 无需鼠标操作
- 学习曲线陡峭
- 快捷键复杂
- 初学者容易卡住
高级开发者、Vim 爱好者
✅ Use Visual Studio Code as Git's default editor- 图形化界面
- 支持中文
- 插件丰富(如 GitLens)
- 自动保存、智能提示
- 启动稍慢
- 占内存较大
所有用户,尤其是开发者
✅ Use Visual Studio Code Insiders as Git's default editor- 最新功能预览版
- 比正式版更早体验新特性
- 可能不稳定
- 会频繁更新
- 不适合生产环境
技术爱好者、尝鲜者
✅ Use Sublime Text as Git's default editor- 极速启动
- 界面美观
- 支持多行编辑
- 插件生态良好
- 免费版有限制
- 付费后才能完全使用
追求效率的开发者
❌ Use Atom as Git's default editor- 开源免费
- 插件丰富
- 性能较差
- 已被 GitHub 官方弃用
- 更新缓慢
旧项目维护者
✅ Use VSCodium as Git's default editor- 与 VS Code 完全兼容
- 开源免费
- 无跟踪、无广告
- 社区支持略弱
- 更新可能滞后
注重隐私的用户

3、Choosing the SSH executable(选择 Git 使用的 SSH 客户端)

🔍 页面内容解析

两个选项:

  1. Use bundled OpenSSH
    → 使用 Git 自带的 ssh.exe(推荐)
  2. Use external OpenSSH
    → 使用系统 PATH 中已有的 OpenSSH(如 Windows 内置或手动安装的)

✅ 推荐选择:Use bundled OpenSSH

✅ 为什么选这个?

优点

说明

📦 简单可靠

Git 自带的 OpenSSH 已经过测试,兼容性好

⚙️ 不依赖系统环境

即使你没装其他 SSH 工具也能用

🔐 安全更新

Git 官方会定期更新内置版本

💡 默认推荐

大多数用户都应选择此选项

✅ 这是 最安全、最稳定、最适合新手的选择

❌ 为什么不选 “Use external OpenSSH”?

原因

说明

🔄 冲突风险

如果你同时安装了多个 SSH 工具(如 Windows OpenSSH、Git 自带、WSL),可能产生冲突

🔁 配置复杂

需要确保外部 ssh.exe 在 PATH 中,并且版本兼容

🛠️ 维护麻烦

更新时需要手动同步多个组件

❌ 除非你有特殊需求(如使用 WSL 的 SSH),否则不建议选择。

🧩 特殊情况说明

✅ 什么时候该选 “Use external OpenSSH”?

  • 你在使用 Windows 10/11 内置的 OpenSSH
  • 你已经通过 winget install openssh 安装了官方 SSH
  • 你想统一使用系统级别的 SSH 工具(避免重复安装)
💡 此时可选此项,但需确保:
where ssh 

能返回系统路径(如 C:\Windows\System32\OpenSSH\ssh.exe


📌 总结:这里该选啥?

强烈推荐选择:Use bundled OpenSSH

这是默认且最稳妥的选择,适合绝大多数用户。

4、Git for Windows 安装程序的“选择 HTTPS 传输后端”页面

Choosing HTTPS transport backend
(选择 Git 使用的 SSL/TLS 库)

🔍 页面内容解析

两个选项:

  1. Use the OpenSSL library
    → 使用 Git 自带的 OpenSSL 库验证证书
  2. Use the native Windows Secure Channel library
    → 使用 Windows 内置的安全通道(SChannel)库验证证书

✅ 推荐选择:Use the native Windows Secure Channel library

✅ 为什么选这个?

优点

说明

🛡️ 更安全

使用 Windows 系统级证书信任链(受控于系统更新)

🏢 企业兼容

支持公司内部 CA 证书(如 Active Directory、企业内网)

⚙️ 自动更新

随 Windows 更新自动获取最新根证书

💡 默认推荐

大多数用户都应选择此选项

✅ 这是 最稳定、最安全、最适合企业/日常使用的选项

❌ 为什么不选 “Use the OpenSSL library”?

原因

说明

🔁 证书管理复杂

需要手动维护 ca-bundle.crt 文件

🌐 不支持企业内网

无法识别公司内部 CA 发布的证书

🔄 可能过期

OpenSSL 的证书库可能滞后于系统更新

⚠️ 安全风险

如果未及时更新,可能导致中间人攻击漏洞

❌ 除非你在特殊网络环境(如某些 Linux 虚拟机),否则不建议选择。

🧩 特殊情况说明

✅ 什么时候该选 “Use the OpenSSL library”?

  • 你在使用 Linux 或 WSL 环境
  • 你需要绕过 Windows 证书限制(极少数场景)
  • 你有自定义的 ca-bundle.crt 文件需要加载
💡 此时可选此项,但需确保:
git config --global http.sslBackend "openssl" 

并正确配置证书文件路径。


📌 总结:这里该选啥?

强烈推荐选择:Use the native Windows Secure Channel library

这是默认且最稳妥的选择,适合绝大多数用户。


5、 Git for Windows 安装程序的“配置行尾换行符转换”页面

Configuring the line ending conversions
(如何处理文本文件的行尾换行符)

🔍 页面内容解析

三个选项(从上到下):

  1. Checkout Windows-style, commit Unix-style line endings
    → 检出时用 Windows 格式(CRLF),提交时用 Unix 格式(LF)
  2. Checkout as-is, commit Unix-style line endings
    → 不转换检出格式,提交时统一转为 LF
  3. Checkout as-is, commit as-is
    → 完全不转换,保持原始格式

📚 行尾换行符基础知识

系统

换行符

说明

Windows

CRLF (\r\n)

回车 + 换行

Unix/Linux/macOS

LF (\n)

只有换行

💡 Git 默认会自动处理这些差异,避免代码在不同系统间出现乱码或冲突。

✅ 推荐选择:Checkout Windows-style, commit Unix-style line endings

✅ 为什么选这个?

优点

说明

🌐 跨平台兼容

提交时统一使用 LF(Unix 风格),防止 Linux/Unix 系统报错

💻 Windows 显示正常

检出时自动转为 CRLF,编辑器不会显示异常

⚙️ 自动管理

Git 自动处理转换,无需手动修改

📄 推荐设置

对于大多数项目,这是官方推荐的配置

✅ 这是 最安全、最通用、最适合 Windows 用户的选择

❌ 其他选项分析

2. Checkout as-is, commit Unix-style line endings

  • 检出时不转换 → 你在 Windows 上看到的文件可能是 LF 格式
  • 编辑器可能显示奇怪的空白行或乱码
  • 适合 Linux 开发者纯 Unix 项目
  • 不推荐普通用户使用

3. Checkout as-is, commit as-is

  • 完全不转换 → 你在 Windows 上保存的文件就是 CRLF
  • 提交后其他平台(如 Linux)可能会出问题
  • 极易导致 合并冲突代码风格混乱
  • ❌ 不推荐任何跨平台项目使用

🧩 实际效果对比

选项

检出文件

提交文件

是否推荐

✅ Checkout Windows-style, commit Unix-style

CRLF

LF

✅ 强烈推荐

❌ Checkout as-is, commit Unix-style

原始格式(可能为 LF)

LF

⚠️ 仅限特定场景

❌ Checkout as-is, commit as-is

原始格式

原始格式

❌ 不推荐


🛠️ 如何查看当前设置?

安装完成后,运行:

git config --get core.autocrlf 

✅ 正常输出:

true 
表示已启用“检出 Windows 格式,提交 Unix 格式”

📌 总结:这里该选啥?

强烈推荐选择:Checkout Windows-style, commit Unix-style line endings

这是 Windows 用户的标准配置,既能保证本地编辑正常,又能确保提交到 GitHub 的代码兼容所有平台。

6、Git for Windows 安装程序的“配置 Git Bash 终端模拟器”页面

Configuring the terminal emulator to use with Git Bash
(选择与 Git Bash 配合使用的终端模拟器)

🔍 页面内容解析

两个选项:

  1. Use MinTTY (the default terminal of MSYS2)
    → 使用 MinTTY(MSYS2 的默认终端)
  2. Use Windows' default console window
    → 使用 Windows 默认控制台(cmd.exe)

🧩 详细分析

✅ 推荐选择:Use MinTTY

✅ 优点:

特性

说明

🖼️ 可调整窗口大小

窗口可以自由缩放,适合大屏使用

📋 支持非矩形选中

可以用鼠标拖动任意形状区域复制文本

🌐 Unicode 字体支持

正确显示中文、emoji、特殊符号等

🎮 支持交互式程序

如 Python、Node.js、npm 等可以在 MinTTY 中正常运行

🔄 自动处理换行符

无需额外配置即可正确显示多行输出

💡 这是 Git for Windows 的官方推荐选项,也是绝大多数用户的首选。

❌ 不推荐选择:Use Windows' default console window

⚠️ 缺点:

问题

说明

🖼️ 窗口不可调整

在旧版 Windows 上无法自由缩放

📋 只能矩形选中

不能像现代终端那样自由选择文本

🌐 不支持 Unicode

中文、emoji 显示异常或乱码

🎮 限制交互程序

某些命令行工具(如 python -i)可能无法正常工作

🔄 滚动缓冲区小

默认只保留几行历史记录,不适合调试

❌ 虽然兼容性好,但功能落后,不推荐新用户使用。

🛠️ 实际体验对比

项目

MinTTY

Windows 控制台

是否支持中文

✅ 是

❌ 否(需手动配置)

是否可缩放

✅ 是

❌ 否(旧版)

是否支持 emoji

✅ 是

❌ 否

是否支持非矩形选中

✅ 是

❌ 否

是否适合开发

✅ 强烈推荐

⚠️ 仅限简单操作


📌 总结:这里该选啥?

强烈推荐选择:Use MinTTY (the default terminal of MSYS2)

这是 最现代化、最实用、最适合开发者的选择

7、 Git for Windows 安装程序的“选择 git pull 默认行为”页面

Choose the default behavior of 'git pull'
(设置 git pull 的默认操作方式)

🔍 页面内容解析

三个选项:

  1. Fast-forward or merge
    → 尽可能快进合并,否则创建合并提交
  2. Rebase
    → 将本地提交重置到远程分支上(变基)
  3. Only ever fast-forward
    → 只允许快进,不能合并,失败则报错

🧩 每个选项详解

✅ 推荐选择:Fast-forward or merge

✅ 优点:

  • 简单直观:大多数情况自动快进,复杂时自动创建合并提交
  • 避免冲突:Git 自动判断是否可以快进,减少手动干预
  • 适合新手:无需理解 rebase 或 fast-forward 的区别
  • GitHub/VS Code 等工具兼容性好
💡 这是 Git 官方推荐的默认行为,也是最广泛使用的设置。

📌 实际效果:

git pull 
  • 如果远程有新提交,且本地无提交 → 快进(fast-forward)
  • 如果本地有提交 → 创建一个合并提交(merge commit),保留历史清晰

❌ 为什么不选 “Rebase”?

⚠️ 缺点:

  • 重写提交历史:会修改本地提交的时间戳和哈希值
  • 协作风险:如果已经推送到远程,rebase 后再推送会导致其他人无法拉取
  • 不适合团队项目:容易引发混乱,尤其在多人协作中
  • 学习成本高:需要理解 rebase 原理,否则容易出错
❌ 仅建议 高级开发者 在个人分支上使用,不推荐作为默认行为。

❌ 为什么不选 “Only ever fast-forward”?

⚠️ 缺点:

  • 严格限制:只有当能快进时才允许拉取,否则失败
  • 无法处理合并:如果你有本地提交,而远程也更新了,就会报错
  • 用户体验差:必须手动执行 git pull --rebasegit merge 才能继续
❌ 虽然这是 Git 最早的标准行为,但现代开发中已不再推荐。

📊 对比总结表

选项

是否推荐

说明

✅ Fast-forward or merge

✅ 强烈推荐

自动处理,适合绝大多数场景

❌ Rebase

⚠️ 高级用户可选

重写历史,不适合团队

❌ Only ever fast-forward

❌ 不推荐

太严格,易失败


🛠️ 如何查看或修改此设置?

安装完成后,你可以通过以下命令查看或更改:

# 查看当前设置 git config --get pull.rebase # 设置为 "fast-forward or merge"(默认) git config --global pull.rebase false # 设置为 "rebase" git config --global pull.rebase true # 设置为 "only fast-forward" git config --global pull.ff only 
✅ 默认值是 false,即对应“Fast-forward or merge”

📌 总结:这里该选啥?

强烈推荐选择:Fast-forward or merge

这是 最安全、最通用、最适合大多数用户的设置

8、 Git for Windows 安装程序的“配置额外选项”页面是:

Configuring extra options
(选择是否启用附加功能)

🔍 页面内容解析

两个选项:

  1. Enable file system caching(已勾选)
    → 启用文件系统缓存
  2. Enable symbolic links(未勾选)
    → 启用符号链接(软链接)

🧩 每个选项详解

✅ 推荐选择:Enable file system caching

✅ 优点:

  • 🚀 显著提升性能:Git 会将文件系统数据批量读取并缓存在内存中
  • ⏱️ 加快操作速度:如 git statusgit addgit commit 等命令响应更快
  • 💾 减少磁盘 I/O:尤其对大项目(如 React、Vue、Node.js)效果明显
  • 📦 默认开启:这是 Git 的推荐设置,适合绝大多数用户
💡 这个选项通过设置 core.fscache = true 实现,是 强烈建议启用的功能

❌ 不推荐选择:Enable symbolic links

⚠️ 注意事项:

  • 🔐 需要管理员权限:必须有 SeCreateSymbolicLink 权限才能使用
  • 🛠️ 仅在特定场景下有用:例如你在项目中使用了符号链接(软链接)来引用其他目录或文件
  • 📁 不影响已有仓库:此设置只影响新创建的仓库,不会改变现有项目的结构
  • 🔄 Windows 限制:普通用户可能无法创建符号链接,除非以管理员身份运行
❌ 如果你不了解符号链接,或者不打算在项目中使用它,不要勾选

📊 对比总结表

选项

是否推荐

说明

✅ Enable file system caching

✅ 强烈推荐

提升性能,无副作用

❌ Enable symbolic links

⚠️ 视情况而定

需要权限,仅特殊用途


🛠️ 如何手动配置这些选项?

安装完成后,你可以通过以下命令查看或修改:

# 查看文件系统缓存状态 git config --get core.fscache # 手动启用(如果被关闭) git config --global core.fscache true # 查看符号链接支持状态 git config --get core.symlinks # 手动启用(需管理员权限) git config --global core.symlinks true 
✅ 默认值:core.fscache = true(已启用),core.symlinks = false(未启用)

📌 总结:这里该选啥?

保持“Enable file system caching”勾选
不勾选“Enable symbolic links”(除非你明确需要)


✅ 三、配置环境变量与验证安装是否成功

1、配置环境变量:

win+r>>sysdm.cpl

把用户变量和系统变量的PATH都增加以下路径,记得确定保存:

2. 重启所有终端(测试代码如下)

关闭并重新打开:

VS Code
# 查看 Git 版本 git --version >>git version 2.52.0.windows.1 #方法1: Get-Command git >> >> >> CommandType    Name   Version    Source -----------                ----          -------    ------ Application     git.exe      2.52.0.1       F:\ProgramFiles\Git\bin\git.exe 方法二: where.exe git >>F:\ProgramFiles\Git\bin\git.exe >>F:\ProgramFiles\Git\cmd\git.exe
PowerShell
# 查看 Git 版本 git --version >>git version 2.52.0.windows.1 # 查找 git 位置 where git >>F:\ProgramFiles\Git\bin\git.exe >>F:\ProgramFiles\Git\cmd\git.exe
CMD

(略)


🔐 四、配置 Git 用户信息(首次使用必做)

# 设置用户名(你的 GitHub 用户名) git config --global user.name "YourGitHubUsername" # 设置邮箱(必须与 GitHub 注册邮箱一致) git config --global user.email "[email protected]" 
#一次性配置:

git config --global user.name "Ama_tor"
git config --global user.email "[email protected]"
git config --list

✅ 这些信息会写入提交记录,务必正确。

🔑 五、SSH 密钥配置(可选但推荐)

开始前:检查 OpenSSH 客户端是否已安装

  1. 按 Win + R → 输入 optionalfeatures → 回车
    (打开“Windows 功能”)
  2. 查看是否勾选了:
    • ✅ OpenSSH 客户端
    • ✅ OpenSSH 服务器(可选,但建议勾上)
💡 如果没安装:勾选 OpenSSH 客户端点击“确定”,等待安装完成重启电脑

1. 生成 SSH 密钥(如果还没做)

ssh-keygen -t ed25519 -C "[email protected]" 
  • 按回车使用默认路径(~/.ssh/id_ed25519
  • 可设置密码短语(passphrase)

2. 启动 SSH Agent⚠️ 必须 以管理员身份运行 PowerShell

# 设置服务为自动启动 Set-Service -Name ssh-agent -StartupType Automatic # 启动服务 Start-Service ssh-agent # 添加私钥 ssh-add F:\你私钥的文件路径\ 

3. 将公钥添加到 GitHub

# 复制公钥 cat (F:\公钥路径含有.pub名字的就是\整个括号内容换掉)| clip 

然后粘贴到:
GitHub Settings → SSH and GPG keys → New SSH key


4. 测试连接

ssh -T [email protected] 

✅ 成功提示:

Hi YourGitHubUsername! You've successfully authenticated... 

5、🔑 SSH 认证原理:公钥 + 私钥 配合工作

✅ 正确理解:

  • 公钥(public key) → 存在 服务器上(比如 GitHub)
  • 私钥(private key) → 存在 你的本地电脑上
  • 认证时,用的是私钥,但验证的是公钥是否匹配

🔄 认证过程(简化版)

  1. 你运行 ssh [email protected]
  2. GitHub 说:“我这里有你的公钥(_id_ed25519.pub),请证明你是它的主人”
  3. 你的电脑用 私钥(_id_ed25519 生成一个 数字签名
  4. GitHub 用 公钥 验证这个签名
    • 如果能解开 → 说明你拥有对应的私钥 → 认证成功
    • 如果不能 → 拒绝访问
💡 所以:私钥用于“证明身份”,公钥用于“验证身份”

❓ 为什么 ssh-add 要加载私钥?

  • ssh-add 的作用是:把 私钥 加载到 ssh-agent(SSH 代理)中
  • 这样当你连接 GitHub 时,ssh 客户端会自动使用这个私钥签名
  • 不需要每次都输入密码(passphrase)
✅ 公钥已经上传到 GitHub(你之前做了),现在只需要让本地提供私钥即可。

📌 类比理解(现实世界)

想象一把 锁 + 钥匙

表格

数字世界现实世界
公钥锁(公开挂在门上)
私钥钥匙(只有你有)
GitHub门卫
想进门的人
  • 门卫(GitHub)看到门上有锁(公钥)
  • 你说:“我能打开它!”
  • 你拿出钥匙(私钥)一试 → 锁开了 → 门卫放行
🔐 门卫不需要你的钥匙,但他知道只有配对的钥匙才能开这把锁

✅ 总结

表格

问题答案
为什么用私钥?因为私钥是“身份证明”,用来生成签名
公钥的作用?存在服务器上,用于验证签名
ssh-add 加什么?加 私钥,让 SSH 自动使用它
安全吗?✅ 安全!私钥永不离开你的电脑

🛠️ 六、常见问题解决

❌ 问题:'git' is not recognized...

  • 原因:PATH 未配置
  • 解决:重装 Git 并选择 "Git from the Windows Command Prompt"

❌ 问题:PowerShell 能用,CMD 不能用(或反之)

  • 原因:环境变量未全局生效
  • 解决:重启电脑,或手动检查系统 PATH

❌ 问题:node.js调用失败

  • 原因:pnpm 调用 Git 时找不到命令
  • 解决:确保 git 在系统 PATH 中

🐶终极:如果找不到问题根源,直接卸载重装与配置把,肯定是中间漏了什么

步骤关键点
下载官网下载 64 位安装包
安装路径标准 + 勾选“Git from Windows Command Prompt”
验证git --version + where git
配置设置用户名/邮箱 + SSH(可选)
使用在任何终端、IDE、插件中均可调用

七、开始使用 Git

#新建项目并指向(不然整个F盘作为项目会很麻烦) mkdir ama_gitproject cd ama_gitproject # 创建版本库 git init #附删除命令:rm -rf /f/.git # 克隆远程仓库 git clone https://github.com/username/repo.git(版式)


#git基本语句:

# 0. 修改或新建文件 echo "<h1>Hello</h1>" > index.html echo "body { color: red; }" > style.css # 1.创建版本库 git init # 2. 添加到暂存区 git add . # 3. 查看暂存区状态 git status # 4. 提交到版本库 git commit -m "Add initial HTML and CSS" # 5.查看提交日志 git log # 6.推送到远程(首次需设置 upstream) git push -u origin main

summit后ama_gitproject自动添加图中文件:

✅ 至此,你已完成 Git 的安装与基本配置

Read more

从零开始:学生与教育工作者如何免费解锁GitHub Copilot的全套能力

学生与教育工作者如何零成本解锁GitHub Copilot的完整指南 1. 教育认证:开启免费Copilot之旅的关键步骤 对于在校学生和教师而言,GitHub提供了一条专属的绿色通道。通过教育认证,你可以完全免费获得Copilot的专业级代码辅助功能,无需经历60天试用期的繁琐流程。这个认证过程虽然需要一些耐心,但绝对值得投入时间。 教育认证的核心在于验证你的学术身份真实性。GitHub会要求你提供以下材料之一: * 学生身份验证:有效的学生证、在学证明或学信网认证报告 * 教师身份验证:教师资格证、工作证或学校官方邮箱 重要提示:使用学校邮箱(.edu或学校专属域名)能大幅提升认证通过率。如果材料非英文,建议附上简单翻译说明。 认证流程中的常见陷阱包括: 1. 上传的证件照片模糊不清 2. 证件有效期信息缺失 3. 使用非官方邮箱提交申请 4. 网络IP地址与学校地理位置不符 我曾帮助三位同学完成认证,发现下午3-5点(美国西部时间)提交的申请通常能在24小时内获得回复,这可能与GitHub审核团队的工作时段有关。 2. PyCharm环境下的Co

By Ne0inhk
我用Openclaw + Claude搭了一套自动写作系统,每天省3小时

我用Openclaw + Claude搭了一套自动写作系统,每天省3小时

这是我目前最重要的一套AI工作流。从信息获取到发布,几乎不用手动完成。 一、为什么我要搭建这套系统? 信息过载的困境 如果你也在持续关注AI,应该会有同样的感受: 信息太多了。 每天打开 X、公众号、GitHub、技术社区,都会冒出大量新内容。 AI模型更新、工具更新、Agent框架、自动化方案…… 想跟上这些信息,本身就已经是一项工作。 手动写作的低效循环 更别说: * 整理信息 * 找选题 * 写文章 * 配图 * 发布到各个平台 如果全部手动完成,写作就会变成一件非常消耗精力的事。 我一度也在这种状态里: 想持续输出,但写作本身占用了太多时间。 一个关键问题 后来我开始思考一个问题: 如果写作这件事可以被"系统化",会发生什么? 于是,我不再把AI当成写作工具。 而是开始搭一套完整的 AI写作工作流。 二、思路转变:从优化写作到优化流程 大多数人的AI写作方式 大多数人使用AI写作,是这样:

By Ne0inhk

【MCP AI Copilot考试通关宝典】:90%考生忽略的3个关键得分点

第一章:MCP AI Copilot考试概述 MCP AI Copilot考试是面向现代云平台开发者与人工智能工程实践者的一项专业能力认证,旨在评估考生在集成AI助手、自动化代码生成、智能运维及安全合规等方面的实际应用水平。该考试结合理论知识与实操技能,要求考生熟练掌握主流开发环境中的AI协作工具,尤其是基于Microsoft Azure平台的AI Copilot生态组件。 考试目标与适用人群 * 具备至少一年云开发或DevOps实践经验的工程师 * 熟悉AI辅助编程工具如GitHub Copilot、Azure AI Studio的开发者 * 希望验证其在自动化流程设计与AI集成方面能力的专业人士 核心技能考核范围 技能领域占比说明AI驱动的代码生成30%评估使用自然语言生成可靠代码的能力智能调试与优化25%考察AI辅助定位性能瓶颈与修复缺陷安全与合规检查20%识别AI生成代码中的潜在风险CI/CD集成AI流程25%实现AI模型在流水线中的自动部署 典型操作示例:启用AI Copilot插件 在Visual Studio Code中集成Copilot需执行

By Ne0inhk
2026年3月1日-阿里CoPaw开源炸场!百度云1分钱服务器秒变多平台AI个人助理

2026年3月1日-阿里CoPaw开源炸场!百度云1分钱服务器秒变多平台AI个人助理

1. 前言 在AI个人助理赛道竞争愈发激烈的今天,如何拥有一个真正"为你工作、与你成长"的AI助手成为了技术圈的热门话题。市面上的AI助手要么功能单一只能聊天,要么接入渠道有限只支持网页端,要么部署门槛极高需要专业运维知识,普通开发者想要拥有一个多平台、可扩展、支持记忆的私人AI助理一直是个难题。 还记得上个月我们那篇1分钱部署私人AI助手!百度云OpenClaw极速版,3分钟搞定零代码吗?当时百度智能云推出了0.01元抢购轻量应用服务器的活动,不少小伙伴都成功上车拿到了一台2核4G的云服务器。虽然那个1分钱活动已经结束了,但服务器还在手里呢!今天我们就要物尽其用,在这台百度云服务器上部署阿里刚开源的重磅项目——CoPaw(协同个人智能体工作台),让你的服务器从单一的OpenClaw升级为支持钉钉、飞书、QQ等多平台接入的全能AI个人助理。 这2天CoPaw非常火爆,话不多说,今天我们就在百度云轻量应用服务器上手把手教大家部署这个阿里开源的AI个人助理平台,体验和感受一下CoPaw"你的搭档小爪子"的强大能力。 2. 项目介绍 什么是CoPaw? CoPaw是阿里Age

By Ne0inhk