一篇解决Git安装配置教程(windows+gitee远程仓库)

官网

https://git-scm.com/

安装

我的电脑是windows64位,所以选择了

  • Git for Windows x64 Setup
  • 如果你想要便携版(不用安装,直接放U盘或文件夹用):
  • Git for Windows x64 Portable

这里注意不要勾选only show new options,不然不会显示各种配置信息,包括安装路径也无法显示

选择组件

一般按照默认即可,点击“Next”;

选择开始菜单文件夹

可以更改名称、不添加或者改到其他目录,一般保持默认;点击“Next”进入下一步

选择默认文本编辑器

-决定了你使用 git commit 等命令时自动打开哪个编辑器来编写提交信息。

如何后续修改编辑器

设置默认初始分支名 

决定了你创建新 Git 仓库时,默认分支的名字。

Let Git decide使用 Git 的默认分支名(目前是 "master")。这是传统名称,但近年来很多团队和平台(如 GitHub)已改用 "main"

设置 PATH 环境变量

  1. Use Git from Git Bash only
    • 只在 Git Bash 中使用 Git 命令。
    • PATH 不会修改,不会影响系统。
    • 不能在 Windows 命令提示符(CMD)或 PowerShell 中直接使用 git 命令。
  2. Git from the command line and also from 3rd-party software(推荐)
    • 将 Git 的核心命令添加到系统 PATH 中。
    • 你可以在 Git Bash、CMD、PowerShell、第三方软件 中直接使用 git 命令。
    • 推荐选择此项,方便日常使用。

选择 SSH 可执行程序

决定了 Git 使用哪个 SSH 客户端来连接远程仓库(如 GitHub、GitLab)。

  • Use bundled OpenSSH(推荐)
    使用 Git 自带的 OpenSSH 客户端(ssh.exe)。
    优点:独立、稳定,不与系统已有 SSH 冲突,适合大多数用户。
  • Use external OpenSSH
    使用系统中已有的 OpenSSH(比如 Windows 10/11 自带的 OpenSSH 客户端)。
    注意:如果你不确定自己是否有或需要外部 SSH,建议不要选此项。

选择 HTTPS 传输后端

决定了 Git 使用哪个 SSL/TLS 库来验证 HTTPS 连接的服务器证书(比如访问 GitHub、GitLab 等)。

  • Use the OpenSSL library
    使用 Git 自带的 OpenSSL 库进行证书验证。
    特点:使用 Git 自带的 ca-bundle.crt 证书文件,独立于 Windows 系统证书。
  • Use the native Windows Secure Channel library
    使用 Windows 自带的 Secure Channel(Schannel) 库进行证书验证。
    特点:使用 Windows 系统证书存储,方便企业用户使用内部 CA 证书(如公司内网代理、自签名证书等)。

如果你是普通个人用户,建议选择第一个选项(OpenSSL),然后点击 [Next]

如果你在公司或学校内网环境下,可能需要使用公司内部的证书,可以选择第二个选项(Windows Secure Channel)。

后续修改

配置换行符转换 

决定了 Git 如何处理文本文件中的换行符(Windows 用 CRLF,Unix/Linux/macOS 用 LF

  1. Checkout Windows-style, commit Unix-style line endings(推荐)
    • 检出文件时:LF → CRLF(适合 Windows 编辑)
    • 提交文件时:CRLF → LF(存储为 Unix 风格)
    • 适合 Windows 用户参与跨平台项目(如与 Linux/macOS 开发者协作)。
  2. Checkout as-is, commit Unix-style line endings
    • 检出时不转换,提交时 CRLF → LF
    • 适合 Unix/macOS 用户 或仅使用现代编辑器(如 VSCode)的 Windows 用户。

选择 Git Bash 的终端模拟器

  1. Use MinTTY (the default terminal of MSYS2)
    • 推荐选择
    • 功能更现代:支持窗口自由缩放、非矩形文本选择、更好的字体渲染、完整的滚动条等。
    • 需要运行 Windows 控制台程序(如交互式 Python、Node.js)时,需在命令前加 winpty(例如:winpty python)。
  2. Use Windows' default console window
    • 使用传统的 Windows 控制台(cmd.exe)。
    • 优点:直接兼容所有 Windows 控制台程序,无需 winpty
    • 缺点:功能受限(滚动条有限、字体渲染可能有问题、窗口缩放不灵活)。

选择 git pull 的默认行为

决定了执行 git pull 时如何合并远程分支的更改到本地分支。

  1. Fast-forward or merge(推荐)
    • 如果本地分支可以快进合并(即本地没有新提交),则直接移动指针。
    • 如果不能快进(本地有提交),则创建合并提交(merge commit)。
    • 适合大多数用户,保留完整历史。
  2. Rebase
    • 将本地提交变基到远程分支之后(重写历史,使历史线更整洁)。
    • 适合习惯保持线性历史的开发者,但需注意变基会改变提交哈希。
  3. Only ever fast-forward
    • 只允许快进合并。
    • 如果不能快进,则 git pull 会失败,需要手动处理。
    • 适合严格保持线性历史的团队,但对新手不太友好。

选择凭证(登录信息)管理器

决定了 Git 如何保存你的账号密码或令牌(如访问 GitHub、GitLab 时的登录信息)

  1. Git Credential Manager(推荐)
    • 自动保存你的 Git 远程仓库登录凭据(如 GitHub 用户名和密码/令牌)。
    • 支持 Windows 凭据存储、macOS 钥匙串等。
    • 方便安全,无需每次推送/拉取都输入密码。
  2. None
    • 不使用任何凭证助手。
    • 每次操作远程仓库都需要手动输入用户名和密码(或令牌)。
    • 不推荐,除非你有特殊的安全策略。

配置额外选项

  • ✅ Enable file system caching(推荐勾选)
    启用文件系统缓存,Git 会批量读取文件系统数据并缓存到内存中,能显著提升操作速度(如状态检查、提交等)。
    建议保持勾选,除非你的内存非常紧张。
  • 🔗 Enable symbolic links(可选)
    启用符号链接(软链接)支持。
    注意:需要系统权限(SeCreateSymbolicLink),且不影响已有仓库。
    如果你不创建或不需要使用符号链接,可以不勾选。
  • Launch Git Bash:如果勾选,安装完成后会自动打开 Git Bash(一个命令行工具,用于运行 Git 命令)。
  • View Release Notes:如果勾选,会打开浏览器查看 Git 的版本更新说明。

配置

检查安装成功

选择一个盘符,创建一个新的文件夹,右键

输入git,如下图所示则安装成功,或者输入git --version查看

git config --global --list 是一个 Git 命令,用于列出当前用户的所有全局 Git 配置项

这个错误表示 你的全局 Git 配置文件(.gitconfig)不存在,因为你还没设置过任何全局配置。

配置用户名和邮箱

检查配置是否成功

修改配置文件

也可以通过记事本打开.gitconfig文件进行配置

  • git status 用于查看当前仓库的状态(如哪些文件已修改、已暂存等)。
  • 但该命令必须在 Git 仓库目录中执行(即该目录或上级目录包含 .git 文件夹)。

初始化仓库

创建git本地仓库,先初始化仓库

查看仓库文件夹发现多了一个.git文件

同时,在命令行最后多了一个 “main” (因为我们在安装的时候选择的是使用main作为新仓库的分支名称的),这代表目前处于仓库的 “main” 分支

在本地仓库新建一个文本文档,查看仓库状态(git status)

  • On branch main:当前在 main 分支。
  • No commits yet:仓库还没有任何提交(第一次初始化)。
  • Untracked files:有一个未被跟踪的文件 test01.txt(Git 尚未开始管理它)。
  • Changes to be committedtest01.txt 已暂存,等待提交。
  • 提示你可以用 git rm --cached <file> 将文件从暂存区移除(如果不想提交它)。

记得要输入git commit -m "提交信息"(提交信息自定义,其实就是备注信息)

Git 的提交信息编辑界面。这是因为执行 git commit 时没有使用 -m 参数指定提交信息,所以 Git 打开了默认编辑器手动输入。

如果输入的是git commit就会进入到git的提交信息编辑界面

解决办法:

输入git log就可以查看到提交的作者、时间、提交信息

git branch

  • 查看当前仓库有哪些分支。
  • 当前所在分支前面会有一个 * 号标记。

为常用命令配置别名

打开用户目录,创建.bashrc文件,找不到文件就输入

ls -la ~/.bashrc

用记事本打开.bashrc,输入如下:

输入git-log如果没有正确显示日志,可以先查看

cat ~/.bashrc

确认别名成功配置,查看输出中是否有 alias git-log=... 这一行。

如果有但是命令执行失败可能没有被 Git Bash 加载,输入:

source ~/.bashrc

手动重新加载,但是发现有

文字乱码

配置.bashrc文件

应用后保存即可

Gitee码云远程仓库连接

初始化本地仓库后设置提交忽略文件

touch .gitignore

参考:

# 编译产物 target/ classes/ *.class # 依赖管理 *.jar *.war *.ear .m2/ # Maven本地仓库(通常不提交) # IntelliJ IDEA Files .idea/ *.iml *.ipr *.iws *.idea .classpath .project

输入命令,成功

Read more

鸿蒙金融理财全栈项目——合规审计、风险控制、产品创新优化

鸿蒙金融理财全栈项目——合规审计、风险控制、产品创新优化

《鸿蒙APP开发从入门到精通》第21篇:鸿蒙金融理财全栈项目——合规审计、风险控制、产品创新优化 📊🛡️🚀 内容承接与核心价值 这是《鸿蒙APP开发从入门到精通》的第21篇——合规审计、风险控制、产品创新优化篇,100%承接第20篇的运维监控、性能优化、安全加固架构,并基于金融场景的合规审计、风险控制、产品创新要求,设计并实现鸿蒙金融理财全栈项目的合规审计、风险控制、产品创新优化功能。 学习目标: * 掌握鸿蒙金融理财项目的合规审计优化设计与实现; * 实现合规审计自动化、合规审计报告优化、合规审计风险预警; * 理解风险控制优化在金融场景的核心设计与实现; * 实现风险评估自动化、风险监控实时化、风险预警智能化; * 掌握产品创新优化在金融场景的设计与实现; * 实现产品创新敏捷化、产品创新数据化、产品创新生态化; * 优化金融理财项目的用户体验(合规审计、风险控制、产品创新优化)。 学习重点: * 鸿蒙金融理财项目的合规审计优化设计原则; * 风险控制优化在金融场景的应用; * 产品创新优化在金融场景的设计要点。 一、 合规审计优化基础

By Ne0inhk
Flutter 三方库 remove_markdown 的鸿蒙化适配指南 - 打造纯净文本提取、内容预处理实战、鸿蒙级文本解析专家

Flutter 三方库 remove_markdown 的鸿蒙化适配指南 - 打造纯净文本提取、内容预处理实战、鸿蒙级文本解析专家

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 remove_markdown 的鸿蒙化适配指南 - 打造纯净文本提取、内容预处理实战、鸿蒙级文本解析专家 在鸿蒙跨平台应用处理海量的 Markdown 博文、技术文档或用户输入的富文本内容时,有时我们需要剥离所有的样式标记(如加粗、链接、列表),还原出最原始、最纯洁的文字内容。如果你需要为搜索索引构建、智能语音播报(TTS)或是内容摘要生成提供高质量的数据源。今天我们要深度解析的 remove_markdown——一个专注于高效、无损 Markdown 语法剥离的轻量级 Dart 库,正是帮你实现“内容减负”的核心引擎。 前言 remove_markdown 是一套基于正则表达式与高效字符扫描的转换工具。它的设计初衷极其明确:将复杂的 Markdown 源码瞬间坍缩为易于阅读和处理的纯文本。在鸿蒙端项目中,利用它你可以确保在展示搜索片段(

By Ne0inhk
Flutter 组件 riverpod_signals 的适配 鸿蒙Harmony 实战 - 驾驭双剑合璧状态架构、实现鸿蒙端强依赖注入与细粒度刷新深度融合方案

Flutter 组件 riverpod_signals 的适配 鸿蒙Harmony 实战 - 驾驭双剑合璧状态架构、实现鸿蒙端强依赖注入与细粒度刷新深度融合方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 riverpod_signals 的适配 鸿蒙Harmony 实战 - 驾驭双剑合璧状态架构、实现鸿蒙端强依赖注入与细粒度刷新深度融合方案 前言 在鸿蒙(OpenHarmony)生态的极繁数字化政务底座、大型分布式供应链管理系统以及对架构严密性与交互流畅度有“双重严苛审计要求”的各类企业级应用开发中,“架构的解耦深度与 UI 的响应广度”是衡量软件成熟度的两把关键标尺。面对包含上百个全局服务(Service)与数千个高频局部刷新节点(Widget)的复杂资产体系。如果全量使用 Riverpod 的 Consumer 监听,可能会在大型列表中产生不必要的树扫描开销;而如果仅使用 Signals,又会因为缺乏完善的依赖注入(DI)机制。导致业务逻辑流的组织变得松散且难以维护。 我们需要一种“顶级架构对齐、局部响应闭环”的融合艺术。 riverpod_signals 是一套专注于将

By Ne0inhk