Git 与 GitHub on 扎塔-Zata

gh使用教程

Sun, 12 Apr 2026 21:50:00 +0800

1. 常用命令速查

case

# 创建私有仓库并推送本地代码
gh repo create my-project --private --source=. --push

# 查看帮助与版本
gh --version
gh help
gh <command> --help

# 登录与认证
gh auth login
gh auth status
gh auth logout

# 仓库
gh repo clone owner/repo
gh repo create
gh repo view --web
gh repo fork
gh repo sync

# Pull Request
gh pr create --fill
gh pr list
gh pr view
gh pr checkout 123
gh pr diff
gh pr review --approve
gh pr merge

# Issue
gh issue create
gh issue list
gh issue view 123
gh issue comment 123 --body "补充说明"
gh issue close 123

# GitHub Actions
gh workflow list
gh run list
gh run view <run-id>
gh run watch
gh run download <run-id>

# Release
gh release create v1.0.0
gh release list
gh release view v1.0.0
gh release upload v1.0.0 dist/app.tar.gz

# 浏览器与搜索
gh browse
gh browse 123
gh search prs --author @me
gh search issues --owner your-org

# API 与脚本
gh api user
gh api repos/OWNER/REPO/pulls
gh pr list --json number,title,url

# 配置与效率
gh alias set pv "pr view"
gh config set editor vim
gh extension search
gh extension install owner/gh-extension-name

2. `gh` 是什么

gh 是 GitHub 官方命令行工具，核心价值不是替代 git，而是把原本要在 GitHub 网页上完成的事情搬到终端里。

适合用 git 做的事情：

本地提交、分支切换、变基、合并、查看工作区变更
与任意 Git 远程交互，而不局限于 GitHub

适合用 gh 做的事情：

登录 GitHub 账号
创建和管理 Pull Request、Issue、Release
查看和触发 GitHub Actions
直接调用 GitHub API
安装 GitHub CLI 扩展

最实用的理解方式是：git 管仓库历史，gh 管 GitHub 平台能力。

3. 安装与初始化

安装

常见安装方式如下：

# macOS
brew install gh

# Windows
winget install --id GitHub.cli

# Ubuntu / Debian
type -p curl >/dev/null || sudo apt install curl -y
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | \
 sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | \
 sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update
sudo apt install gh -y

安装后先确认版本：

gh --version

4. 仓库操作

克隆仓库

gh repo clone owner/repo

它本质上还是帮你完成 GitHub 仓库级别的克隆，但写法更统一，也方便后续继续使用 gh。

创建仓库

gh repo create

这个命令会进入交互流程，通常会问你：

仓库名称
是否公开
是否添加 README
是否推送当前目录

如果你想快速把当前项目推到 GitHub，经常很好用。

查看仓库信息

gh repo view
gh repo view --web
gh repo view owner/repo

常见用途：

在终端查看仓库概要
直接在浏览器打开仓库页面
脱离当前目录查看别的仓库

Fork 与同步

gh repo fork
gh repo sync

典型场景：

fork 别人的仓库到自己账号下
在自己的 fork 上开发
上游仓库更新后，用 gh repo sync 同步

如果你平时经常参与开源项目，这两个命令非常顺手。

5. Pull Request 工作流

gh 最有价值的部分之一，就是把 PR 的完整链路搬到命令行里。

创建 PR

gh pr create
gh pr create --fill

--fill 会自动用当前分支的提交信息帮你生成标题和描述，适合已经写好了比较规范 commit message 的情况。

常见流程：

git checkout -b feature/login
git add .
git commit -m "feat: add login page"
git push -u origin feature/login
gh pr create --fill

查看 PR

gh pr list
gh pr view
gh pr view 123
gh pr view --web

适合查看：

当前仓库有哪些 PR
某个 PR 的详情
直接跳转浏览器继续看评论和检查项

切换到某个 PR

gh pr checkout 123

这个命令很适合代码评审场景。你不用先找分支名，直接通过 PR 编号就能把代码拉到本地。

查看差异、检查、评审、合并

gh pr diff 123
gh pr checks 123
gh pr review 123 --approve
gh pr review 123 --comment -b "建议补一个测试"
gh pr merge 123

这一组命令基本覆盖了 PR 审查最常见的动作：

看 diff
看 CI 是否通过
approve / comment / request changes
合并 PR

如果团队流程比较规范，gh 能明显减少频繁切浏览器的次数。

6. Issue 管理

创建与查看

gh issue create
gh issue list
gh issue view 123
gh issue view 123 --web

适合用来做：

快速提 bug
记录待办事项
查看当前仓库未关闭的问题

评论、编辑、关闭

gh issue comment 123 --body "我来处理这个问题"
gh issue edit 123 --add-label bug
gh issue close 123
gh issue reopen 123

如果你把 GitHub Issues 当轻量项目管理工具，这一组命令会非常高频。

7. GitHub Actions 与 CI/CD

gh 对 Actions 的支持很实用，尤其适合你在终端里排查 CI。

查看工作流和运行记录

gh workflow list
gh run list
gh run view <run-id>

观察运行状态

gh run watch

这个命令适合在你刚 push 代码后盯 CI 结果，不用一直刷新网页。

下载产物与重新运行

gh run download <run-id>
gh run rerun <run-id>

常见场景：

下载构建产物
CI 因偶发网络问题失败时重跑
快速定位是哪一步报错

8. Release 管理

如果你的项目通过 GitHub Release 发版本，gh 可以把整个流程命令化。

创建与查看 Release

gh release create v1.0.0
gh release list
gh release view v1.0.0

上传构建产物

gh release upload v1.0.0 dist/app.tar.gz

这在发布二进制、压缩包、安装包时很方便，尤其适合配合脚本或 CI 自动化。

9. `gh api`：把 GitHub API 直接带进终端

很多人低估了 gh api，但它其实是 gh 最强的能力之一。

基本调用

gh api user
gh api repos/OWNER/REPO
gh api repos/OWNER/REPO/issues

如果某个能力暂时没有现成的 gh <group> <subcommand>，往往可以直接退回到 gh api。

搭配 JSON 输出

gh pr list --json number,title,url
gh issue list --json number,title,labels
gh workflow list --json id,name,path,state

这类写法很适合：

给 shell 脚本喂数据
做自动化统计
和 jq 配合筛选字段

例如：

gh pr list --json number,title,author --jq '.[] | {number, title, author: .author.login}'

如果你经常写脚本，建议尽快把 --json、--jq 这套用起来。

10. 提效能力：别名、配置、扩展

alias

gh alias set pv "pr view"
gh alias set pc "pr create --fill"
gh pv
gh pc

适合把高频长命令压缩成自己熟悉的缩写。

config

gh config set editor vim
gh config get editor

最常见的是设置默认编辑器，避免某些命令唤起你不想用的编辑器。

extension

gh extension search
gh extension install owner/gh-extension-name
gh extension list
gh extension upgrade --all

扩展机制可以理解为给 gh 加外挂命令。对于一些官方没内置、但社区已经做好了的能力，扩展通常是最快方案。

11. 推荐的实际使用方式

如果你是个人开发者，可以先掌握这条最实用链路：

gh auth login
gh repo clone owner/repo
git checkout -b feature/xxx
本地开发并提交
git push -u origin feature/xxx
gh pr create --fill
gh pr checks
gh pr merge

如果你负责 CI/CD 或平台维护，再补上这些：

gh workflow list
gh run list
gh run watch
gh release create
gh api

如果你经常参与开源协作，再补上这些：

gh repo fork
gh repo sync
gh issue list
gh pr checkout
gh pr review

12. 常见问题

`gh` 和 `git` 到底怎么分工？

一句话：

git 负责版本控制
gh 负责 GitHub 平台交互

最合理的方式不是二选一，而是组合使用。

为什么有些仓库命令要加 `-R`？

因为 gh 默认优先使用当前目录对应的仓库上下文。如果你不在仓库目录里，或者你想操作别的仓库，就显式指定：

gh pr list -R OWNER/REPO

命令太多记不住怎么办？

先记住三件事：

gh
gh <command>
gh <command> --help

gh 的帮助系统本身就做得很好，遇到不熟悉的子命令时直接查帮助通常最快。

13. 参考资料

Self-hosted Runner

Tue, 24 Feb 2026 09:22:30 +0800

实现从 Windows 开发机通过 CI/CD 部署到另一台 Windows 机器的方法

要实现从一台 Windows 开发机通过 CI/CD 直接部署到另一台 Windows 机器，最主流且最稳定的做法是：在目标 Windows 机器上安装一个“自托管运行器 (Self-hosted Runner 或 Agent)”。

这样一来，CI/CD 平台就可以直接向你的目标机器发送指令，让它自动拉取最新代码（或构建好的程序包）、替换旧文件并重启软件。

以下是实现这一目标的标准流程，以目前最常用的 GitHub Actions 为例（GitLab CI/CD 或 Azure DevOps 的原理几乎完全相同）：

开发机上，你编写代码，然后执行 git push 命令将代码推送到云端仓库（如 GitHub）。

云端代码仓库（如 GitHub）检测到代码更新后，会触发 CI/CD 流程。此时，目标机器上运行的后台程序（Runner）接收到来自云端的指令，会自动在本地执行编译、覆盖文件和重启软件的脚本。

在你的目标机器上配置 Runner 是最关键的一步。你需要让目标机器和云端仓库建立连接。具体步骤如下：

在 GitHub 上，进入你的代码仓库，点击 Settings，然后选择 Actions，再进入 Runners 页面。点击 New self-hosted runner，选择 Windows 操作系统及对应的架构（通常是 x64）。

随后，在你的目标 Windows 机器上打开 PowerShell，按照 GitHub 页面上提供的步骤逐行复制并运行命令。这些命令会下载 Runner 程序、进行身份验证并将其注册到你的仓库中。

在配置的最后一步，建议将 Runner 安装为 Windows 服务 (Windows Service)，这样目标机器每次开机都会自动启动 Runner，随时准备接收部署任务。

在目标机器上更新软件时，通常会遇到“文件被占用”的问题。因此，你需要写一个简单的 PowerShell 脚本来处理部署逻辑。例如，你的软件运行在 C:\MyApp：

停止正在运行的软件进程（或 Windows 服务）。
将新编译好的文件复制到 C:\MyApp 并覆盖。
重新启动软件。

在你的开发机上，在项目根目录下创建一个文件夹 .github/workflows/，并在其中新建一个文件（例如 deploy.yml），填入以下内容：

name: Windows Auto Deploy

# 当推送到 main 分支时触发
on:
 push:
 branches: [ "main" ]

jobs:
 build-and-deploy:
 # 这里的 self-hosted 是关键，它告诉 GitHub 在你的目标机器上运行这些步骤
 runs-on: self-hosted 

 steps:
 - name: 1. 获取最新代码
 uses: actions/checkout@v4

 - name: 2. 编译项目 (根据你的语言修改)
 run: |
 echo "开始编译..."
 # 例如 C# 项目: dotnet build -c Release
 # 例如 Node 项目: npm install && npm run build

 - name: 3. 停止当前运行的程序
 run: |
 # 假设你的程序叫 MyApp.exe
 Stop-Process -Name "MyApp" -ErrorAction SilentlyContinue
 # 如果是 Windows 服务，使用: Stop-Service -Name "MyService"

 - name: 4. 部署/覆盖文件
 run: |
 echo "复制文件到运行目录..."
 # 将编译好的产物复制到目标文件夹 (根据实际路径修改)
 Copy-Item -Path ".\bin\Release\net8.0\*" -Destination "C:\Deployments\MyApp" -Recurse -Force

 - name: 5. 重启程序
 run: |
 echo "启动程序..."
 # 启动进程或重启服务
 Start-Process -FilePath "C:\Deployments\MyApp\MyApp.exe"
 # 如果是 Windows 服务，使用: Start-Service -Name "MyService"

在配置 Runner 时，需要注意权限问题。Runner 默认以配置它的用户身份运行。如果你需要操作 C 盘敏感目录或管理 Windows 服务，确保 Runner 对应的用户（或服务账号）具有管理员权限。

此外，如果你的目标机器性能较弱，或者不想安装编译工具链，可以将 CI/CD 拆分为两个 Job：第一个 Job 使用 GitHub 官方的云端 Windows 服务器进行编译并上传产物 (Artifacts)；第二个 Job 运行在 self-hosted 的目标机器上，只负责下载产物并覆盖文件。

Self-hosted Runner 搭建教程

当 GitHub Actions 的免费额度用完，或者需要在特定硬件/内网环境上执行构建时，可以将自己的机器注册为 Self-hosted Runner。它不消耗 GitHub Actions 分钟数，job 会直接运行在你的机器上。

注册 Runner

进入仓库 Settings → Actions → Runners → New self-hosted runner（组织级别则在组织 Settings 中），选择对应的操作系统和架构，页面会生成一段包含一次性 registration token 的命令，照着执行即可。

Linux 安装示例

mkdir actions-runner && cd actions-runner

# 版本号以 GitHub 页面给出的为准
curl -o actions-runner-linux-x64-2.325.0.tar.gz -L \
 https://github.com/actions/runner/releases/download/v2.325.0/actions-runner-linux-x64-2.325.0.tar.gz

tar xzf actions-runner-linux-x64-*.tar.gz

./config.sh --url https://github.com/<用户名>/<仓库> --token <页面生成的token>

# 前台测试运行
./run.sh

# 生产环境建议注册为系统服务
sudo ./svc.sh install
sudo ./svc.sh start

Windows 安装示例

在 PowerShell 中执行（建议在 C:\actions-runner 这类位于驱动器根目录下的短路径中安装；注册为服务时需要在管理员权限下执行）：

# 在驱动器根目录下创建安装目录
mkdir actions-runner; cd actions-runner

# 下载最新 Runner 包；版本号以 GitHub 页面给出的为准
Invoke-WebRequest -Uri https://github.com/actions/runner/releases/download/v2.337.0/actions-runner-win-x64-2.337.0.zip -OutFile actions-runner-win-x64-2.337.0.zip

# 可选：校验 SHA256 哈希，避免下载包损坏
if((Get-FileHash -Path actions-runner-win-x64-2.337.0.zip -Algorithm SHA256).Hash.ToUpper() -ne '1150692afa94e71f872017e254ea55b6eece1eece3fe7e3a6d4c93d0a1b85cfc'.ToUpper()){ throw 'Computed checksum did not match' }

# 解压到当前目录
Add-Type -AssemblyName System.IO.Compression.FileSystem;
[System.IO.Compression.ZipFile]::ExtractToDirectory("$PWD/actions-runner-win-x64-2.337.0.zip", "$PWD")

./config.cmd --url https://github.com/<用户名>/<仓库> --token <页面生成的token>

# 前台测试运行
./run.cmd

# 注册为 Windows 服务并启动
./svc.cmd install
./svc.cmd start

按页面给出的命令完成下载、校验、解压和 config.cmd 配置后，Runner 就会注册到仓库的 Runners 列表中。只要状态显示为 Idle，说明它已经在线并等待接收任务：

配置过程中会给 Runner 起名并选择 label（默认 self-hosted、linux 或 windows 等）。注册为服务后，即使关闭终端或注销用户，Runner 也会在后台常驻。

在 Workflow 中使用

jobs:
 build:
 runs-on: self-hosted  # 或 [self-hosted, linux] / [self-hosted, windows] 指定更细的 label
 steps:
 - uses: actions/checkout@v4
 - name: Build
 run: echo "running on my own machine"

注意事项

安全：公开仓库不要随意接入 self-hosted runner，任何 fork 的 PR 都可能执行代码。建议仅用于私有仓库，或在仓库设置中严格限制 workflow 权限。
环境隔离：job 直接运行在宿主机上，会留下缓存和文件。建议用 Docker 容器或一次性虚拟机运行 Runner，或在每次 job 前后做清理。
服务账户权限：Windows 下 Runner 默认以 NETWORK SERVICE 运行，如果 job 需要 Docker、文件系统或网络共享权限，需在安装服务时指定有权限的账户，或在 services.msc 中修改服务登录账户。
环境依赖：确保 Runner 所在机器已安装构建所需的工具链（Node、Python、Docker 等），且服务账户的 PATH 中可访问。
在线要求：Runner 需要保持在线才能接收任务，建议通过 systemd（Linux）或 Windows 服务常驻运行。

github release

Thu, 01 May 2025 01:28:06 +0800

关于版本的管理可以参考： https://www.bilibili.com/video/BV1Ee411W79K

GitHub Release 是 GitHub 上用来标记项目可发布版本的一种方式。它可以包含该版本的源代码快照、编译好的二进制文件以及相关的发行说明。创建 Release 有助于用户清晰地了解项目的版本历史和获取特定版本的可执行文件或库。

为什么使用 GitHub Release？

版本管理： 清晰地标记项目的不同版本，方便追溯和管理。
软件分发： 提供稳定版本的下载链接，方便用户获取和使用。
发行说明： 在 Release 中包含详细的说明，介绍该版本的特性、改进、Bug 修复等。
自动化： 可以结合 CI/CD 工具实现自动化 Release 发布。

在创建 GitHub Release 之前，你需要满足以下条件：

拥有一个 GitHub 账号。
拥有一个 GitHub 仓库。
对该仓库有写入权限。
通常情况下，你需要有一个 Git Tag 与 Release 关联。Tag 用于标记代码库中的某个特定的提交（commit），代表着该版本代码的状态。

有两种主要的方式来创建 GitHub Release：通过 GitHub 网页界面和通过 Git 命令行工具（结合 GitHub CLI）。

方法一：通过 GitHub 网页界面创建 Release

这是最直观和常用的方法。

步骤 1：进入你的仓库页面

在浏览器中打开你的 GitHub 仓库主页。

步骤 2：创建新的 Release

“Create a new release"（创建新 Release），点击这个按钮。

步骤 3：选择或创建 Tag

在新 Release 页面，你需要关联一个 Git Tag。

选择现有 Tag： 点击 “Choose a tag”（选择一个标签）下拉菜单，选择一个已经存在的 Tag。
创建新 Tag： 在输入框中直接输入你想要创建的新 Tag 名称（例如 v1.0.0）。输入后，会显示 “Create new tag on publish"（发布时创建新标签）。

重要提示： Tag 的命名通常遵循 Semantic Versioning 规范，格式通常是 MAJOR.MINOR.PATCH（大版本，小版本，bug修复版本），例如 v1.0.0、v1.2.3 等。建议在 Tag 前加上 v。

步骤 4：选择目标分支 (如果创建新 Tag)

如果你在步骤 4 中创建了一个新的 Tag，你需要选择这个 Tag 将关联到哪个分支上的最新提交。通常情况下，你会选择你的主分支（如 main 或 master）。点击 “Target”（目标）下拉菜单进行选择。

步骤 5：填写 Release 标题和描述

Release title (发行标题): 输入你的 Release 的标题，通常与 Tag 名称相同或稍作描述（例如 “Version 1.0.0 Release”）。
Describe this release (描述此发行版): 在这里填写详细的发行说明（Release Notes）。你可以使用 Markdown 格式来美化你的说明。发行说明通常包括：
- 新功能 (New Features)
- 改进 (Improvements)
- Bug 修复 (Bug Fixes)
- 已知问题 (Known Issues)
- 重大变化 (Breaking Changes) (如果适用)
- 致谢 (Acknowledgements) (如果适用)

步骤 6：自动生成 Release Notes (可选)

GitHub 可以根据最近的提交历史自动生成 Release Notes。在描述框上方，点击 “Generate release notes"（生成发行说明）按钮。你可以基于生成的笔记进行修改和完善。

步骤 7：上传二进制文件 (可选) 这只能上传25M，Github CLi可以2G

如果你的 Release 包含编译好的可执行文件、安装包或其他二进制文件，可以在 “Attach binaries by dropping them here or selecting them"（通过将二进制文件拖放到此处或选择它们来附加）区域上传。直接将文件拖放到该区域，或者点击选择文件。

步骤 8：选择 Release 类型 (可选)

This is a pre-release (这是一个预发行版): 如果这个 Release 是一个测试版本、Beta 版本或 RC (Release Candidate) 版本，勾选此选项。预发行版会在 Release 列表中有特殊的标记。
Set as the latest release (设置为最新发行版): 默认情况下，新发布的 Release 会被标记为最新发行版。如果你发布的是一个旧版本或一个特殊的 Release，可以取消勾选此选项。

步骤 9：创建讨论 (可选)

如果你的仓库开启了 GitHub Discussions 功能，你可以选择为这个 Release 创建一个讨论。勾选 “Create a discussion for this release"（为此发行版创建讨论），并选择一个讨论分类。

步骤 10：发布 Release

Publish release (发布发行版): 如果你准备好将 Release 公开，点击此按钮。
Save draft (保存草稿): 如果你还没有准备好发布，想稍后再完善，点击此按钮将 Release 保存为草稿。草稿状态的 Release 只有仓库的协作者可见。

发布后，你的 Release 将会在仓库的 Releases 页面列出，并且与你关联的 Tag 也会被创建（如果你创建了新 Tag）。

方法二：通过 Git 命令行和 GitHub CLI 创建 Release

对于习惯使用命令行或需要自动化发布流程的用户，可以使用 Git 命令创建 Tag，然后结合 GitHub CLI 来创建 Release。

前提条件：

安装并配置好 Git。
安装并认证 GitHub CLI (https://cli.github.com/)。

CLI可以看：GitHub CLI 命令行工具（gh)

步骤 1：在本地仓库创建并推送 Tag

首先，在你的本地 Git 仓库中创建并推送一个 Tag。

# 切换到你想要打 Tag 的 commit (可选，如果不是最新的 commit)
# git checkout <commit_hash>

# 创建一个轻量级 Tag (不推荐用于 Release)
# git tag <tag_name>

# 创建一个附注 Tag (推荐用于 Release，可以包含说明信息)
git tag -a <tag_name> -m "发行说明"

# 推送 Tag 到远程仓库
git push origin <tag_name>

例如：

git tag -a v1.0.0 -m "Initial release"
git push origin v1.0.0

如果想要删除tag，使用下面的命令

# 删除本地tag
git tag -d v1.0.0

# 删除远程tag
git push origin --delete v1.0.0

步骤 2：使用 GitHub CLI 创建 Release

在 Tag 推送到 GitHub 后，你可以使用 GitHub CLI 命令来创建 Release。

gh release create <tag_name> [flags]

一些常用的 flag：

-t, --title <string>: 设置 Release 的标题。
-n, --notes <string>: 设置 Release 的描述/发行说明。
-F, --notes-file <file>: 从文件中读取 Release 的描述/发行说明。
-d, --draft: 将 Release 创建为草稿。
-p, --prerelease: 将 Release 标记为预发行版。
--latest=false: 不将此 Release 设置为最新发行版。
<filename> | <pattern>...: 指定要上传到 Release 的资产文件。

例如，创建一个包含描述并上传一个文件的 Release：

gh release create v1.0.0 --title "Version 1.0.0" --notes "This is the first release." my_app.zip

如果你的发行说明比较长，可以将其写入一个文件（例如 release_notes.md），然后使用 -F 参数：

gh release create v1.0.0 --title "Version 1.0.0" -F release_notes.md my_app.zip

如果你只创建 Tag，然后想基于该 Tag 在 GitHub 上起草 Release，也可以直接去网页界面操作，选择刚刚推送的 Tag。但是网页只能上传25MB的附件

通过命令行编辑和删除 Release：

GitHub CLI 也提供了编辑和删除 Release 的命令：

编辑 Release：gh release edit <tag_name> [flags]
删除 Release：gh release delete <tag_name>

总结

创建 GitHub Release 是项目版本管理和软件分发的重要环节。你可以选择使用直观的网页界面进行操作，也可以通过命令行工具实现更灵活和自动化的流程。无论哪种方式，核心都是为代码库的特定状态（通过 Git Tag 标记）创建一个带有详细说明和可选附件的版本发布。

希望这个详细教程对你有帮助！

git-submodule-子模块

Tue, 29 Apr 2025 11:10:22 +0800

这是一份关于 Git Submodule（子模块）的详细教程，包括概念、使用场景、常用命令以及详细的可执行代码示例。

Git Submodule 允许你将一个 Git 仓库作为另一个 Git 仓库的子目录。这在你有一个主项目依赖于其他独立开发的库或项目时非常有用。子模块会固定在你指定的一个特定的提交（commit）上，而不是分支的最新状态。

知识点总结

Git Submodule 记录的是子模块仓库中一个特定的提交

Git Submodule 的一个核心概念是：主仓库记录的是子模块仓库中一个特定的提交（commit），而不是跟踪子模块的某个分支的最新状态。

这意味着当你使用 git submodule add <远程仓库URL> 命令时：

Git 会克隆远程子模块仓库到指定的路径。默认情况下，Git 会检出子模块仓库的默认分支（通常是 main 或 master）。最重要的一点：主仓库会记录下子模块仓库在那个默认分支上当前的最新提交的 SHA-1 值。

为什么是这样？

这种设计是为了保证主项目的稳定性。主项目依赖于子模块的一个确定版本。如果主项目仅仅跟踪子模块的某个分支（比如 main），那么子模块的任何新提交都可能在你不经意间破坏主项目的功能。通过锁定到特定的提交，你可以精确控制主项目使用的子模块代码版本，确保每次克隆或更新主项目时，子模块都处于预期的状态。

如何指定添加子模块时使用的分支或标签？

如果你不想使用子模块仓库的默认分支，可以在 git submodule add 命令中使用 -b 选项指定一个特定的分支：

git submodule add -b <分支名> <远程仓库URL> <子模块在主仓库中的路径>

示例：指定 develop 分支

假设你想添加子模块，并使用其 develop 分支的当前提交：

git submodule add -b develop https://github.com/your-username/your-submodule-repo.git submodule_directory

这样，Git 会克隆子模块仓库，检出 develop 分支，然后主仓库记录 develop 分支当前的最新提交。

你也可以指定一个标签（tag）：

git submodule add -b <标签名> <远程仓库URL> <子模块在主仓库中的路径>

更新子模块时如何处理分支？

当你运行 git submodule update –remote 命令来更新子模块时：

Git 会进入子模块目录。

它会拉取子模块远程仓库的最新提交。

默认情况下，它会根据 .gitmodules 文件中记录的信息（如果添加时指定了 -b 分支，则使用该分支；否则使用远程仓库的默认分支）找到该分支的最新提交。

然后，它会将子模块的工作树更新到该分支的最新提交，并更新主仓库对子模块的引用到这个新的提交。

为什么使用 Git Submodule？

管理外部依赖： 当你的项目依赖于第三方库或其他内部独立项目时，可以使用子模块来包含它们，而不是直接复制代码。
分离关注点： 将大型项目拆分成更小的、可管理的独立仓库。
版本控制依赖： 精确控制主项目使用的外部依赖的版本（通过指定特定的提交）。

Git Submodule 的一些注意事项：

复杂性增加： 使用子模块会增加工作流程的复杂性，特别是对于不熟悉子模块的团队成员。
更新子模块： 子模块不会随主项目自动更新到最新版本，需要手动更新。
克隆的特殊性： 克隆包含子模块的项目需要额外的步骤。

具体教程

准备工作：创建示例仓库

为了演示，我们需要创建两个 Git 仓库：一个作为主仓库（parent），另一个作为子模块仓库（submodule）。

创建子模块仓库 (submodule_repo):

# 创建一个目录作为子模块仓库
mkdir submodule_repo
cd submodule_repo

# 初始化 Git 仓库
git init

# 创建一个示例文件
echo "This is the submodule content." > submodule_file.txt

# 添加并提交
git add .
git commit -m "Initial commit for submodule"

# (可选) 如果你使用 GitHub 或 Gitee，可以创建一个远程仓库并关联
# git remote add origin <你的远程仓库地址>
# git push -u origin master

创建主仓库 (parent_repo):

# 回到上一级目录
cd ..

# 创建一个目录作为主仓库
mkdir parent_repo
cd parent_repo

# 初始化 Git 仓库
git init

# 创建一个示例文件
echo "This is the parent content." > parent_file.txt

# 添加并提交
git add .
git commit -m "Initial commit for parent"

# (可选) 如果你使用 GitHub 或 Gitee，可以创建一个远程仓库并关联
# git remote add origin <你的远程仓库地址>
# git push -u origin master

现在我们有了两个本地 Git 仓库：parent_repo 和 submodule_repo。

1. 添加子模块

在主仓库 parent_repo 中，我们将 submodule_repo 添加为一个子模块。

打开终端，进入 parent_repo 目录：

cd parent_repo

使用 git submodule add 命令添加子模块。语法是：git submodule add <子模块仓库地址> <子模块在主仓库中的路径>

如果你的子模块仓库是本地的，可以使用相对或绝对路径。如果是远程仓库（如 GitHub），使用其 URL。

示例：添加本地子模块

因为 Git 的安全设置默认禁止通过 file:// 协议（也就是直接的本地文件路径）进行克隆，这包括添加本地子模块。

这是 Git 为了防止某些安全风险而设置的。当你使用相对路径 ../submodule_repo 时，Git 内部会将其解析为 file:// 协议来尝试克隆。

因此可以通过配置全局允许file协议解决

# 任何目录下执行，写入配置
git config --global protocol.file.allow always



## 如果想取消
git config --global --unset protocol.file.allow

假设 submodule_repo 目录与 parent_repo 目录在同一级。

# 在主仓库目录，添加子模块
git submodule add ../submodule_repo submodule_directory

../submodule_repo: 子模块仓库的路径。
submodule_directory: 子模块在 parent_repo 中的存放路径。

执行此命令后，你会看到类似以下的输出：

Cloning into 'submodule_directory'...
done.

查看变化：

运行 git status，你会发现有两项变化：

.gitmodules 文件被创建。
submodule_directory 目录被添加。

git status

输出会显示：

On branch master
Changes to be committed:
 (use "git reset HEAD <file>..." to unstage)

 new file: .gitmodules
 new file: submodule_directory

.gitmodules 文件记录了子模块的信息，包括路径和 URL。查看其内容：

cat .gitmodules

输出类似：

[submodule "submodule_directory"]
 path = submodule_directory
 url = ../submodule_repo

submodule_directory 目录现在是 submodule_repo 的一个工作副本，但它处于一个特殊的“游离 HEAD”（detached HEAD）状态，指向添加子模块时 submodule_repo 的最新提交。

提交子模块的添加：

将 .gitmodules 文件和子模块目录的添加提交到主仓库：

git add .gitmodules submodule_directory
git commit -m "Add submodule_repo as a submodule"

现在，主仓库已经记录了子模块的存在以及它指向的特定提交。

2. 克隆包含子模块的仓库

当其他人克隆包含子模块的仓库时，默认情况下子模块目录是空的。需要额外的步骤来初始化和更新子模块。

假设你要克隆上面创建的 parent_repo。

正常克隆主仓库：
```
# 回到上一级目录
cd ..

# 克隆主仓库
git clone parent_repo cloned_parent_repo
```
进入克隆后的 cloned_parent_repo 目录，你会发现 submodule_directory 目录存在，但里面是空的：
```
cd cloned_parent_repo
ls submodule_directory
```
（没有输出或显示目录为空）

初始化并更新子模块：

需要运行以下命令来初始化子模块配置并拉取子模块的代码：
```
git submodule init
git submodule update
```
- git submodule init: 这个命令会读取 .gitmodules 文件，并将子模块的信息添加到主仓库的 .git/config 文件中。
- git submodule update: 这个命令会克隆子模块仓库到指定的路径，并检出 .gitmodules 文件中记录的特定提交。
运行 git submodule update 后，submodule_directory 目录就会包含子模块的代码了：
```
ls submodule_directory
```
输出：
```
submodule_file.txt
```

更便捷的克隆方式：

可以在克隆主仓库时直接使用 --recurse-submodules 选项，一步完成克隆、初始化和更新子模块：

# 回到上一级目录并删除之前克隆的仓库
cd ..
rm -rf cloned_parent_repo

# 使用 --recurse-submodules 选项克隆
git clone --recurse-submodules parent_repo cloned_parent_repo_recursive

# 进入目录并查看子模块内容
cd cloned_parent_repo_recursive
ls submodule_directory

输出：

submodule_file.txt

这种方式更推荐，因为它简化了克隆包含子模块的项目流程。

3. 更新子模块

子模块固定在主仓库记录的特定提交上。如果子模块仓库有了新的提交，你需要手动更新主仓库中对子模块的引用。

假设 submodule_repo 有了新的提交。

在子模块仓库中进行新的提交：

进入 submodule_repo 目录（或者克隆后的 cloned_parent_repo/submodule_directory 目录），进行修改并提交：

# 进入子模块目录 (如果你还在 parent_repo 或其克隆目录中)
cd submodule_directory # 或者 cd ../submodule_repo

# 创建或修改文件
echo "Adding new content to submodule." >> submodule_file.txt

# 添加并提交
git add .
git commit -m "Add new content to submodule"

# (如果子模块有远程仓库) 推送到子模块的远程仓库
# git push origin master

在主仓库中更新子模块引用：

回到主仓库（parent_repo 或其克隆目录）。此时，主仓库仍然指向子模块的旧提交。进入子模块目录之后运行 git status 会显示子模块目录已被修改：
```
cd .. # 回到主仓库目录 (parent_repo 或 cloned_parent_repo)
cd parent_repo
cd submodule_directory
git status
```
输出类似：
```
On branch master
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)

 modified: submodule_directory (new commits)

no changes added to commit (use "git add" and/or "git commit -a")
```
要将主仓库更新到子模块的最新提交，可以使用 git submodule update --remote 命令：
```
git submodule update --remote
```
这个命令会进入每个子模块目录，拉取最新的代码，并更新主仓库中子模块的引用到最新的提交。

注意： git submodule update --remote 默认会更新到子模块仓库当前分支的最新提交。如果你希望更新到特定分支，可以使用 --remote --merge <分支名> 或 --remote --rebase <分支名>。

更新后，再次运行 git status，你会看到子模块目录再次被标记为已修改，但这次是因为它的引用指向了新的提交：
```
git status
```
输出类似：
```
On branch master
Changes to be committed:
 (use "git reset HEAD <file>..." to unstage)

 modified: submodule_directory
```
提交主仓库的更新：

将主仓库中对子模块引用的更新进行提交：
```
git add submodule_directory # 当然直接git add . 也可以
git commit -m "Update submodule_directory to latest commit"

# (如果主仓库有远程仓库) 推送到主仓库的远程仓库
# git push origin master
```
这样，主仓库就记录了子模块的最新状态。

4. 在子模块中工作

在子模块目录中，你可以像在任何独立的 Git 仓库中一样进行操作：切换分支、创建提交、推拉代码等。

进入子模块目录：

cd submodule_directory

现在你就在 submodule_repo 的工作目录中了。你可以进行正常的 Git 操作：

# 查看当前分支
git branch

# 切换分支
# git checkout <分支名>

# 创建新的提交
# (修改文件，git add，git commit)

# 推送到子模块的远程仓库
# git push origin <分支名>

完成在子模块中的工作后，回到主仓库目录：

cd ..

如果子模块中有了新的提交，主仓库会检测到变化（如上面更新子模块的步骤所示），你需要再次在主仓库中提交对子模块引用的更新。

5. 切换分支（包含子模块）

在包含子模块的主仓库中切换分支可能会有些复杂，因为不同分支可能引用子模块的不同提交，甚至在某些分支上没有子模块。

当切换到一个新分支时，Git 会尝试根据新分支的 .gitmodules 文件和主仓库记录的子模块提交信息，自动更新子模块。

示例：切换到新分支

假设在 parent_repo 中创建一个新分支 feature_branch：

git checkout -b feature_branch

如果在 feature_branch 上对子模块进行了修改（例如，更新到新的提交），然后切换回 master 分支：

git checkout master

Git 会尽力将子模块恢复到 master 分支所指向的提交。如果出现问题（例如，子模块目录有未提交的修改），Git 可能会报错或将子模块目录标记为未追踪。

为了避免潜在的问题，建议在切换主仓库分支之前，确保子模块目录是干净的（没有未提交的修改）。如果子模块中有修改需要保留，先在子模块内部进行提交。

6. 删除子模块

删除子模块比添加子模块要麻烦一些，需要执行几个步骤来彻底移除子模块的记录和文件。

假设我们要从 parent_repo 中删除 submodule_directory 子模块。

取消初始化子模块：
```
git submodule deinit submodule_directory
```
这个命令会移除 .git/config 文件中关于该子模块的配置。
移除 .gitmodules 文件中的对应条目：

使用文本编辑器打开 .gitmodules 文件，删除对应子模块的配置段落（例如，[submodule "submodule_directory"] 开始的部分）。

或者使用命令：
```
git config -f .gitmodules --remove-section submodule.submodule_directory
```
从暂存区移除子模块：

子模块在 Git 中被记录为一个特殊的工作树条目。需要将其从暂存区移除：
```
git rm --cached submodule_directory
```
手动删除子模块的工作目录和 .git/modules 中的相关文件：
```
rm -rf submodule_directory
rm -rf .git/modules/submodule_directory
```
- rm -rf submodule_directory: 删除子模块在主仓库中的工作目录。
- rm -rf .git/modules/submodule_directory: 删除 Git 在主仓库内部为该子模块存储的元数据和对象。

提交删除操作：

git add .gitmodules
git commit -m "Remove submodule_directory submodule"

现在，子模块就彻底从主仓库中删除了。

总结常用命令

git submodule add <url> <path>: 添加子模块。
git submodule init: 初始化本地的子模块配置。
git submodule update: 克隆子模块仓库并检出主仓库指定的提交。
git clone --recurse-submodules <url>: 克隆主仓库并递归地初始化和更新子模块。
git submodule update --remote: 将子模块更新到其远程仓库的最新提交，并更新主仓库的引用。
git submodule deinit <path>: 取消初始化子模块。
git rm --cached <path>: 从暂存区移除子模块。

更高级的用法和注意事项

指定分支或标签： 添加子模块时，可以使用 -b <分支名> 或指定一个特定的提交 SHA1 来控制子模块的初始状态。
子模块的子模块： 如果子模块本身也包含子模块，在克隆和更新时需要使用 --recursive 选项，例如 git clone --recursive 和 git submodule update --recursive。
游离 HEAD 状态： 在子模块目录中进行修改并提交后，子模块会处于游离 HEAD 状态。如果你想在子模块中固定跟踪某个分支，需要在子模块目录中 git checkout <分支名>，然后在主仓库中提交对子模块引用的更新。
使用 .gitattributes 忽略子模块的某些文件： 可以在主仓库的 .gitattributes 文件中配置，以便 Git 在某些操作（如 git status）中忽略子模块目录中的未追踪或已修改文件。
替代方案： 对于简单的依赖管理，考虑使用包管理器（如 npm, yarn, pip, Composer, Maven, Gradle 等），它们通常比 Git Submodule 更易于管理依赖版本和更新。Git Submodule 更适合于包含独立的、需要独立开发和版本控制的子项目或库。

希望这份详细的教程能帮助你理解和使用 Git Submodule！如果在实践中遇到问题，可以根据具体的错误信息进行搜索或提问。

2-github action 使用

Mon, 03 Mar 2025 00:00:00 +0800

参考：

常用知识

基础概念

Workflow（工作流）
工作流是一个自动化过程，定义在一或多个 YAML 文件中，存放在 .github/workflows 目录下。一个项目可以有多个工作流，他们顺序执行，你也可以在一个工作流里面引用执行另一个工作流
Event（事件）
触发工作流的事件，例如 push（推送代码）、pull_request（拉取请求）或定时触发。也可以手动执行，
Job（任务）
工作流中的一组步骤（Steps），运行在同一个虚拟机上。多个 Job 可以并行或按顺序执行。
Step（步骤）
Job 中的单个操作，例如运行命令或调用一个 Action。
Action（动作）
可重用的代码单元，通常由社区或官方提供，简化常见任务。
Runner（运行器）
执行工作流的服务器，GitHub 提供托管的 Runner，也支持自托管。
共享的action 很多操作在不同项目里面是类似的，完全可以共享。GitHub 注意到了这一点，想出了一个很妙的点子，允许开发者把每个操作写成独立的脚本文件，存放到代码仓库，使得其他开发者可以引用。

如果你需要某个 action，不必自己写复杂的脚本，直接引用他人写好的 action 即可，整个持续集成过程，就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。

GitHub 做了一个官方市场 https://github.com/marketplace?type=actions ，可以搜索到他人提交的 actions。另外，还有一个 awesome actions 的仓库 https://github.com/sdras/awesome-actions ，也可以找到不少 action。

每个 action 就是一个独立脚本，因此可以做成代码仓库，使用userName/repoName的语法引用 action。比如，actions/setup-node就表示github.com/actions/setup-node这个仓库，它代表一个 action，作用是安装 Node.js。事实上，GitHub 官方的 actions 都放在 github.com/actions 里面。既然 actions 是代码仓库，当然就有版本的概念，用户可以引用某个具体版本的 action。下面都是合法的 action 引用，用的就是 Git 的指针概念，详见官方文档。https://docs.github.com/en/actions/sharing-automations/creating-actions/about-custom-actions#versioning-your-action
```
actions/setup-node@74bc508 # 指向一个 commit
actions/setup-node@v1.0 # 指向一个标签
actions/setup-node@master # 指向一个分支
```
仓库密钥和环境密钥的区别，以及组织密钥

参考：

https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions

仓库密钥：（仓库下面的所有分支和标签可用）
- 仓库密钥是在 GitHub 仓库级别设置的，用于保护仓库的访问权限和敏感信息。
- 仓库密钥可以在仓库的“Settings” > “Secrets” > “Actions”中设置。
- 仓库密钥只能在仓库内使用，不能跨仓库共享。
环境密钥：（可设置哪些分支可用）
- 环境密钥是在 GitHub 分支级别设置的，可以通过设置去设置哪些分支可用
组织密钥：（可以设置哪些仓库可用）

另外，在工作流里面是打印不出来密钥的

构建画爱心为可执行程序

原始代码效果：

代码：

# 版权https://github.com/royalneverwin/beating-heart

from tkinter import * # 导入tkinter库，用于创建GUI界面
from math import sin, cos, pi, log # 导入数学函数，用于心形计算
import random # 导入随机数模块，用于生成随机点
import time # 导入时间模块（当前代码未使用，但保留）

# 定义画布的宽度和高度
CANVAS_WIDTH = 640
CANVAS_HEIGHT = 480
# 计算画布中心坐标
CANVAS_CENTER_X = CANVAS_WIDTH / 2
CANVAS_CENTER_Y = CANVAS_HEIGHT / 2
# 心形放大倍数
IMAGE_ENLARGE = 11


def scatter_inside(x, y, beta=0.15): # 在心形内部生成散点
 """使用对数分布在给定点附近生成内部散点"""
 ratiox = -beta * log(random.random()) # 对数分布计算x方向偏移量，可调整beta值改变分布
 ratioy = -beta * log(random.random()) # 对数分布计算y方向偏移量
 dx = ratiox * (x - CANVAS_CENTER_X) # 计算x方向的实际偏移
 dy = ratioy * (y - CANVAS_CENTER_Y) # 计算y方向的实际偏移
 return x - dx, y - dy # 返回散点的新坐标


def heart_function(t, enlarge_ratio: float = IMAGE_ENLARGE): # 定义心形曲线方程
 """根据参数t生成心形曲线的x,y坐标"""
 # 心形曲线参数方程
 x = 16 * (sin(t)**3)
 y = -(13 * cos(t) - 5 * cos(2*t) - 2 * cos(3*t) - cos(4*t))

 # 放大心形
 x *= enlarge_ratio
 y *= enlarge_ratio

 # 将心形移动到画布中心
 x += CANVAS_CENTER_X
 y += CANVAS_CENTER_Y

 return int(x), int(y) # 返回整数坐标


def shrink(x, y, ratio): # 向心形中心收缩点
 """根据距离中心点的平方反比计算收缩量"""
 sk_range = -1 / ((x - CANVAS_CENTER_X) ** 2 + (y - CANVAS_CENTER_Y) ** 2) # 平方反比因子
 dx = ratio * sk_range * (x - CANVAS_CENTER_X) # x方向收缩量
 dy = ratio * sk_range * (y - CANVAS_CENTER_Y) # y方向收缩量
 return x - dx, y - dy # 返回收缩后的坐标


class Heart:
 def __init__(self, frame): # 初始化心形类
 self.points = set() # 存储心形曲线上的点
 self.edge_points = set() # 存储边缘散点
 self.inside_points = set() # 存储内部散点
 self.all_points = {} # 存储每一帧的所有点坐标
 self.build(2000) # 构建初始点集，可调整点的数量
 self.frame = frame # 动画的总帧数
 for f in range(frame): # 预计算每一帧的点位置
 self.calc(f)
 self.random_halo = 1000 # 用于光晕效果的随机点数量（未直接使用）

 def build(self, number): # 生成初始点集
 """在心形上生成随机点及其边缘和内部散点"""
 # 在心形曲线上随机生成number个点
 for _ in range(number):
 t = random.uniform(0, 2 * pi) # 随机生成角度t
 x, y = heart_function(t) # 计算心形上的点
 x, y = shrink(x, y, -1000) # 向中心收缩点
 self.points.add((int(x), int(y))) # 添加到点集

 # 生成边缘散点
 for px, py in self.points:
 for _ in range(3): # 每个点生成3个边缘散点，可调整数量
 x, y = scatter_inside(px, py, 0.05) # 在点附近生成散点，可调整beta值
 self.edge_points.add((x, y)) # 添加到边缘点集

 # 生成内部散点
 pt_ls = list(self.points) # 将点集转为列表以便随机选择
 for _ in range(4000): # 生成4000个内部散点，可调整数量
 x, y = random.choice(pt_ls) # 随机选择一个基础点
 x, y = scatter_inside(x, y) # 在其附近生成散点
 self.inside_points.add((x, y)) # 添加到内部点集

 def cal_position(self, x, y, ratio): # 计算点在跳动时的位置
 """根据距离中心的平方反比计算跳动幅度"""
 bt_range = 1 / ((x - CANVAS_CENTER_X) ** 2 + (y - CANVAS_CENTER_Y) ** 2) # 跳动因子
 dx = ratio * bt_range * (x - CANVAS_CENTER_X) + random.randint(-1, 1) # x方向位移
 dy = ratio * bt_range * (y - CANVAS_CENTER_Y) + random.randint(-1, 1) # y方向位移
 return x - dx, y - dy # 返回跳动后的位置

 def calc(self, frame): # 计算每一帧的点位置
 """预计算每帧中所有点的动态位置"""
 ratio = 800 * sin(frame / 10 * pi) # 跳动幅度随正弦变化，30fps，可调整
 all_pts = [] # 存储当前帧所有点的列表

 # 生成光晕效果
 halo_radius = int(4 + 6 * (1 + sin(self.frame / 10 * pi))) # 光晕半径随时间变化
 halo_number = int(3000 + 4000 * abs(sin(self.frame / 10 * pi) ** 2)) # 光晕点数量
 heart_halo_point = set() # 存储光晕点
 for _ in range(halo_number):
 t = random.uniform(0, 2 * pi) # 随机角度
 x, y = heart_function(t, enlarge_ratio=11.6) # 生成光晕基础点
 x, y = shrink(x, y, halo_radius) # 向中心收缩
 if (x, y) not in heart_halo_point: # 避免重复
 heart_halo_point.add((x, y))
 x += random.randint(-14, 14) # 添加随机偏移
 y += random.randint(-14, 14)
 size = random.choice((1, 2, 2)) # 随机选择点大小
 all_pts.append((x, y, size)) # 添加到点列表

 # 计算心形曲线上的点
 for x, y in self.points:
 x, y = self.cal_position(x, y, ratio) # 计算跳动位置
 size = random.randint(1, 3) # 随机点大小，可调整
 all_pts.append((x, y, size))

 # 计算边缘点
 for x, y in self.edge_points:
 x, y = self.cal_position(x, y, ratio)
 size = random.randint(1, 2) # 随机点大小，可调整
 all_pts.append((x, y, size))

 # 计算内部点
 for x, y in self.inside_points:
 x, y = self.cal_position(x, y, ratio)
 size = random.randint(1, 2) # 随机点大小，可调整
 all_pts.append((x, y, size))

 self.all_points[frame] = all_pts # 保存当前帧的点数据

 def render(self, canvas, frame): # 渲染点到画布上
 """在画布上绘制当前帧的所有点"""
 for x, y, size in self.all_points[frame % self.frame]: # 循环取帧数据
 # 绘制矩形点，颜色为粉红色
 canvas.create_rectangle(x, y, x+size, y+size, width=0, fill='#ff7171')


def draw(root: Tk, canvas: Canvas, heart: Heart, frame=0): # 动画绘制函数
 """递归调用实现心形跳动动画"""
 canvas.delete('all') # 清空画布
 heart.render(canvas, frame) # 绘制当前帧
 # 每30毫秒刷新一次，相当于约33fps
 root.after(30, draw, root, canvas, heart, frame+1)


if __name__ == '__main__': # 主程序入口
 root = Tk() # 创建主窗口
 root.title('漂亮宝贝一周年快乐') # 设置窗口标题
 # 创建画布，背景黑色
 canvas = Canvas(root, bg='black', height=CANVAS_HEIGHT, width=CANVAS_WIDTH)
 canvas.pack() # 将画布添加到窗口
 heart = Heart(20) # 创建心形对象，帧数设为20
 draw(root, canvas, heart) # 开始动画
 root.mainloop() # 进入主循环，显示窗口

然后创建一个.github/workflows文件夹，并在其中创建一个love_heart.yml文件。文件内容如下填写,功能是创建一个windows的可执行程序

# This workflow will install Python dependencies, run tests and lint with a single version of Python
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python
# 这是一个 GitHub Actions 工作流，用于安装 Python 依赖、运行测试和代码检查，使用单一 Python 版本
# 更多信息请参考上述 GitHub 文档链接

name: 画爱心Windows版  # 工作流名称，显示在 GitHub Actions 界面上，表示这是一个在 Windows 上构建“画爱心”程序的工作流

on: # 定义触发工作流的事件
 workflow_dispatch: # 手动触发事件，允许用户通过 GitHub 界面手动运行此工作流

permissions: # 设置工作流的权限
 contents: read  # 授予读取仓库内容的权限，确保工作流可以访问代码

jobs: # 定义工作流中的任务
 pyinstaller-build: # 任务名称，表示使用 PyInstaller 构建可执行文件
 runs-on: windows-latest  # 指定运行环境为最新的 Windows 系统
 steps: # 定义任务的具体步骤
 - name: Create Executable  # 步骤名称，表示创建可执行文件
 uses: sayyid5416/pyinstaller@v1  # 使用社区提供的 PyInstaller Action，版本为 v1
 with: # 配置 Action 的参数
 python_ver: '3.12' # 指定使用的 Python 版本为 3.12
 spec: 'love_heart.py' # 指定 PyInstaller 的构建配置文件或主 Python 文件为 love_heart.py
 upload_exe_with_name: 'love_heart' # 指定上传的可执行文件名称为 love_heart
 options: --onefile, --name "love_heart", --windowed,  # PyInstaller 的构建选项
 # --onefile: 将所有内容打包为单个可执行文件（生成 .exe 文件）
 # --name "love_heart": 设置输出可执行文件的名称为 love_heart（最终为 love_heart.exe）
 # --windowed: 生成无控制台窗口的 GUI 应用程序，适合 Windows 上的图形界面程序
 # 注意：选项之间用逗号分隔，最后一个选项后不需要逗号，但此处保留原始格式

快速入门教程

目标

创建一个简单的 GitHub Actions 工作流，在每次推送代码时运行一个脚本，输出 “Hello, GitHub Actions!"。

步骤

创建仓库
在 GitHub 上创建一个新仓库（或使用现有仓库）。
添加工作流文件
- 在仓库根目录下创建文件夹 .github/workflows。
- 在该文件夹中创建一个文件，例如 hello.yml。

编写工作流文件
将以下内容写入 hello.yml：

name: Hello World Workflow

# 触发条件：在推送代码到 main 分支时运行
on:
 push:
 branches:
 - main

# 定义任务
jobs:
 say-hello:
 runs-on: ubuntu-latest # 使用 GitHub 提供的最新 Ubuntu 虚拟机
 steps:
 - name: Checkout code
 uses: actions/checkout@v3 # 检出代码到虚拟机

 - name: Say Hello
 run: echo "Hello, GitHub Actions!" # 运行简单的 shell 命令

提交文件
将 hello.yml 提交到仓库的 main 分支。
查看运行结果
- 转到仓库的 Actions 标签页。
- 你会看到名为 “Hello World Workflow” 的工作流正在运行。
- 点击工作流名称，查看日志，确认 “Hello, GitHub Actions!” 已输出。

进阶示例

运行测试并部署

假设你有一个 Node.js 项目，想在推送代码时运行测试并部署到服务器。

工作流文件示例
创建 .github/workflows/test-and-deploy.yml：

name: Test and Deploy

on:
 push:
 branches:
 - main

jobs:
 test:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout code
 uses: actions/checkout@v3

 - name: Setup Node.js
 uses: actions/setup-node@v3
 with:
 node-version: '16'

 - name: Install dependencies
 run: npm install

 - name: Run tests
 run: npm test

 deploy:
 needs: test # 在 test 任务成功后运行
 runs-on: ubuntu-latest
 steps:
 - name: Checkout code
 uses: actions/checkout@v3

 - name: Deploy to server
 run: |
 echo "Deploying to server..."
 # 这里可以添加实际部署命令，例如通过 SSH

添加秘密（Secrets）
如果部署需要敏感信息（如 SSH 密钥）：
- 转到仓库的 Settings > Secrets and variables > Actions。
- 点击 New repository secret，添加密钥（如 SSH_KEY）。
- 在工作流中通过 secrets.SSH_KEY 使用它。

常用配置

触发事件

on:
 push: # 推送时触发
 branches:
 - main
 pull_request: # 拉取请求时触发
 branches:
 - main
 schedule: # 定时触发（每天凌晨0点）
 - cron: '0 0 * * *'

设置环境变量

env:
 MY_VAR: "Hello"
jobs:
 example:
 runs-on: ubuntu-latest
 steps:
 - run: echo $MY_VAR # 输出 "Hello"

使用社区 Action
示例：使用 actions/cache 缓存依赖：

- name: Cache node modules
 uses: actions/cache@v3
 with:
 path: ~/.npm
 key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

调试技巧

查看日志：在 Actions 标签页点击工作流，展开每个 Job 和 Step 查看详细输出。
添加调试步骤：在步骤中运行 ls -la（Linux）或 dir（Windows）检查文件。
使用 GitHub 提供的测试工具：在本地安装 act（需要 Docker）模拟运行工作流。

常见问题

工作流没触发？
检查 on 配置是否匹配事件和分支。
权限不足？
在仓库设置中确认 Actions 已启用（Settings > Actions > General）。
需要更多计算资源？
考虑使用自托管 Runner。

扩展阅读

官方文档：https://docs.github.com/en/actions
社区 Actions：https://github.com/marketplace?type=actions

on字段

在 GitHub Actions 的 on 字段中，你可以定义触发工作流的事件。workflow_dispatch 是其中一种触发方式，表示手动触发。除了 workflow_dispatch，还有许多其他触发事件可以选择，具体取决于你的需求。以下是 on 可以填写的参数（触发事件类型），以及它们的用途和可能配置项：

`on` 可填写的触发事件类型

1. `workflow_dispatch`（手动触发）

作用：允许用户通过 GitHub 界面手动触发工作流。
可选配置：
- inputs：定义手动触发时可以输入的参数。

示例：

on:
 workflow_dispatch:
 inputs:
 name:
 description: '输入你的名字'
 required: true # 是否必填
 default: 'Anonymous' # 默认值
 version:
 description: '选择版本'
 type: choice  # 类型可以是 string, boolean, choice 等
 options:
 - 'v1'
 - 'v2'
 required: false

用途：适合需要用户干预或自定义参数的场景，例如手动选择构建版本。

2. `push`（推送事件）

作用：当代码被推送到指定分支或路径时触发。
可选配置：
- branches：指定触发分支。
- branches-ignore：忽略特定分支。
- paths：指定触发文件路径。
- paths-ignore：忽略特定文件路径。
- tags：指定触发标签。

示例：

on:
 push:
 branches:
 - main
 - 'feature/*' # 支持通配符
 paths:
 - 'src/**' # 只在 src 目录下文件变更时触发
 tags:
 - 'v*'

用途：适合每次代码提交时自动构建或测试。

3. `pull_request`（拉取请求事件）

作用：当拉取请求（PR）被创建、更新或合并时触发。
可选配置：
- branches：目标分支。
- types：触发的事件类型（如 opened, synchronize, closed）。
- paths：触发文件路径。

示例：

on:
 pull_request:
 branches:
 - main
 types:
 - opened  # PR 创建时触发
 - synchronize  # PR 更新时触发
 paths:
 - '*.py' # 只在 Python 文件变更时触发

用途：用于 PR 的自动化检查或构建。

4. `schedule`（定时触发）

作用：按计划时间触发，使用 cron 表达式。
可选配置：
- cron：定义运行时间（UTC）。

示例：

on:
 schedule:
 - cron: '0 0 * * *' # 每天 UTC 00:00 触发
 - cron: '*/15 * * * *' # 每 15 分钟触发一次

用途：适合定时任务，例如每天构建或检查。

5. `release`（发布事件）

作用：当 GitHub 发布（release）相关操作发生时触发。
可选配置：
- types：触发类型（如 published, created, edited）。

示例：

on:
 release:
 types:
 - published  # 发布时触发
 - prereleased  # 预发布时触发

用途：用于发布版本时的自动化构建或部署。

6. `issues`（问题事件）

作用：当 GitHub Issues 相关操作发生时触发。
可选配置：
- types：触发类型（如 opened, closed, labeled）。

示例：

on:
 issues:
 types:
 - opened  # 新建 issue 时触发
 - labeled  # 添加标签时触发

用途：适合与问题管理相关的自动化任务。

7. `workflow_run`（工作流运行事件）

作用：当另一个工作流完成时触发当前工作流。
可选配置：
- workflows：指定监听的工作流名称。
- types：触发类型（如 completed）。
- branches：触发分支。

示例：

on:
 workflow_run:
 workflows: ['Build'] # 监听名为 Build 的工作流
 types:
 - completed  # Build 完成后触发
 branches:
 - main

用途：用于工作流间的依赖关系，例如先构建再部署。

8. 其他事件

create：当创建分支或标签时触发。
```
on:
 create:
 branches:
 - 'feature/*'
```
delete：当删除分支或标签时触发。
fork：当仓库被 fork 时触发。

watch：当用户点击“Star”时触发。

on:
 watch:
 types:
 - started  # 用户 star 仓库时触发

组合使用

你可以组合多个事件类型。例如：

on:
 push:
 branches:
 - main
 pull_request:
 branches:
 - main
 workflow_dispatch:

这样，工作流会在推送、拉取请求或手动触发时运行。

参数总结表

触发事件	主要配置项	示例用途
`workflow_dispatch`	`inputs`	手动构建，带自定义参数
`push`	`branches`, `paths`, `tags`	代码提交时构建
`pull_request`	`branches`, `types`, `paths`	PR 检查
`schedule`	`cron`	定时任务
`release`	`types`	发布版本
`issues`	`types`	Issue 管理
`workflow_run`	`workflows`, `types`, `branches`	工作流依赖
`create`	`branches`	创建分支或标签

针对你的需求

你的工作流目前使用 workflow_dispatch，适合手动触发构建“画爱心”程序。如果需要其他触发方式：

自动构建：用 push 或 pull_request，在代码变更时触发。
定时构建：用 schedule，每天生成新版本。
发布版本：用 release，在发布时生成可执行文件。

如果你想具体调整（例如添加 push 或 schedule），可以告诉我，我帮你写出对应配置！

git&github_tutorial

Fri, 28 Feb 2025 00:00:00 +0000

Git 基础操作
远程仓库操作
- git clone 远程项目,同步远程项目更新
- git 版本标签
分支与合并
版本回退与撤销
GitHub 相关
身份验证
问题解决
实战
- Git 项目依赖管理：Submodule 与 Subtree 实战教程
- 如何将 clone 下来的项目推送到自己的新仓库并同步原始仓库更新

git基本使用

安装

windows 安装

简单常用命令


%%设置用户签名%%
git config --global user.name [username]
git config --global user.email [useremail]

%%设置对于非ASCII字符的显示方式%%
git config--global core.quotepath false

%%设置init分支名%%
git config --global init.defaultBranch main

git branch --set-upstream-to=origin/<远程分支> <本地分支> # 绑定本地分支和远程分支

# 设置 HTTP/HTTPS 代理
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

# 或者设置 SOCKS5 代理（更稳定）
git config --global http.proxy socks5://127.0.0.1:7890

git pull --rebase # 变基拉取


git stash push --keep-index #只 stash 未暂存但已跟踪的修改 加-u 参数同时 stash 未跟踪文件

git stash pop # 恢复被 stash 的未暂存部分
# 或
git stash apply

git remote prune <remote-name> # 清理本地仓库中对远程仓库 zata 已删除分支的过时跟踪引用。 并不是删除分支


git gc --prune=now #清理不必要的文件并优化本地仓库


%% 设置远端库别名
git remote add <别名> <网址>

%% 查看远端库
git remote -v

%%获取远程仓库的所有更新，并删除本地已经不存在的远程分支的跟踪引用，以保持本地仓库与远程仓库的同步
git fetch --prune

%%查看本地库状态%%
git status

%%追踪文件，放入暂存区%%
git add [filename]
git add . #所有文件放入暂存区
%%撤销追踪%%
git restore 【file】

%%删除暂存区的文件%%
git rm --cache 【filename】

%%提交本地库%%
git commit -m "[提交信息]" 【文件名（可以不加）】

%%撤销commit提交%%
git reset --soft HEAD


%%推送远程库
git push [<远程主机名>] [<本地分支>:<远程分支>] #如果不加分支对应信息就默认上次记录的全部分支
git push origin $(git branch --show-current) # 将当前分支推送到远程仓库（通常是 `origin`），并保持相同的分支名

%%拉取远程库%%
git pull [<远程主机名>] [<远程分支>:<本地分支>] # 从远程仓库（名为 origin）的 main 分支拉取代码并自动与本地的 main 分支合并 ,如果方括号里面的不加就默认拉去上一次的
git pull [<远程主机名>] --depth <分支深度> [<远程分支>:<本地分支>] # 例如git pull zata --depth 1 hugo:hugo ，用于历史内容过多，只拉取少量历史记录


%%查看引用日志版本信息%%
git reflog
%%查看详细日志%%
git log
%%以图形化方式查看本地和远程分支的结构%%
git fetch origin
git log --graph --oneline --all --remotes

%%版本穿梭%% 一般用soft多一点
git reset --hard 【版本号】


git log --oneline --graph --all # 显示所有分支的提交记录建议直接使用gitG

--.gitignore--------------------
test* 忽略以test开头的文件

一些问题解决

Git Rebase 冲突解决（VS Code） — 20260308

当你执行 git rebase <目标分支> 开始变基后，Git 会尝试将你的提交依次应用到目标分支上。如果在这个过程中发生代码冲突，Git 会自动暂停变基操作，等待你解决冲突。

此时，VS Code 会清晰地提示你当前状态：

文件列表中被检测到冲突的文件旁边会出现警告标记（⚠️）。
编辑器底部状态栏会显示“合并冲突”的提示。

解决冲突的核心步骤分为以下环节：

第一步：打开并处理冲突文件 在编辑器中打开有冲突标记的文件，你会看到类似以下结构的代码块：

<<<<<<< HEAD
这是你当前分支（正在变基的提交）的代码
=======
这是来自目标分支（或历史提交中）的代码
>>>>>>> commit-hash

你需要决定如何整合这些代码。你有两种主要方式来完成这一步：

使用 VS Code 内置工具：直接点击冲突标记区域上方出现的选项按钮。你可以选择“接受当前更改”、“接受传入更改”或“保留双方更改”。如果内置选项不能满足需求，你也可以手动删除所有的 <<<<<<<、======= 和 >>>>>>> 标记，并编辑成你最终想要的代码。
使用 GitLens 扩展：如果你安装了 GitLens 扩展，它会提供更加强大和直观的并排对比视图，方便你逐块检查和解决冲突。

第二步：标记冲突文件为已解决 在完成一个文件的所有冲突编辑后，你需要告诉 Git 这个文件的冲突已经处理完毕。

你可以在 VS Code 的源代码管理侧边栏（√图标）中，找到该文件，点击旁边的“+”号或右键选择“暂存更改”。
或者在终端中执行命令 git add <文件名>。

第三步：继续变基过程 标记完所有已解决的冲突文件后，你需要让 Git 继续执行变基操作。

在 VS Code 中，你可以点击底部状态栏的“继续变基”按钮。
或者在终端中执行命令 git rebase --continue。

随后，Git 会尝试应用下一个提交，你可能需要重复上述步骤来解决后续可能出现的冲突，直到所有提交都应用完成。

其他有用的命令 在变基过程中，你还可以使用以下命令：

git rebase --skip：跳过当前正在应用的提交（请谨慎使用，这意味着完全丢弃这个提交的更改）。
git rebase --abort：完全终止本次变基操作，分支将回退到执行 git rebase 之前的状态。

快速流程总结 一个典型的 rebase 解决冲突流程可以简化为：

git rebase main
# 发生冲突
# 使用 VS Code 编辑文件解决冲突
git add .
git rebase --continue
# 可能重复“编辑->add->continue”直到完成

最后的重要提示

变基过程可能需要解决多个提交引发的冲突，请耐心处理完一个后继续下一个。
随时可以使用 git status 命令来查看当前的变基进度和状态。
在进行变基等重写历史的操作前，创建一个备份分支是一个好习惯：git checkout -b backup-branch。

解决Mac、linux下使用git命令时中文乱码的办法

git config --global core.quotepath false

要将远程仓库的 `other` 分支设置为 `main` 分支，并删除原来的 `main` 分支，可以按照以下步骤操作：

确保本地仓库是最新的 首先，确保你的本地仓库与远程仓库同步，并切换到 other 分支：
```
git fetch origin
git checkout other
git pull origin other
```
将 other 分支推送到远程的 main 分支 使用 git push 的 --force 选项，将 other 分支的内容强制覆盖远程的 main 分支：
```
git push origin other:main --force
```
这会将 other 分支的内容直接推送到远程的 main 分支，覆盖原有的 main 分支。
更新本地仓库 在本地仓库中，确保你的 main 分支与远程的 main 分支同步：
```
git checkout main
git pull origin main
```
删除本地的 other 分支（可选） 如果你不再需要本地的 other 分支，可以删除它：
```
git branch -d other
```
验证操作 确认远程仓库的分支状态：
```
git fetch origin
git branch -r
```
你应该看到 origin/main 包含了 other 分支的内容，且 origin/other 仍然存在（除非你也想删除它）。
（可选）删除远程的 other 分支 如果 other 分支不再需要，可以删除远程的 other 分支：
```
git push origin --delete other
```

使用windows系统服务器做远程开发碰到的问题

使用哪个版本的git

感觉这个没有太大关系，不过后面发现便携版本的git也是可用的，感觉以后可以就使用便携版的，毕竟不需要界面
使用windows远程服务器进行git pull总是卡死

2025年0617，买了一个腾讯云到2h2G服务器，想用来写hugo博客，但是在pull代码的时候总是卡死，试了很多次，我以为是服务器性能太烂了，最后发现，如果使用http地址pull的话就没有问题。但是后面又发现使用github的http地址的话会存在无法push的情况，所以我最终给出的解决方案就是：使用github的http地址拉取项目，然后使用ssh地址同步

如果想要临时查看某次commit时项目的全部代码

git log --oneline
git checkout <commit哈希值> # 查看代码
git checkout main # 返回主分支

在本地开发环境检查远程是否更新

第一种方法

git log --oneline --graph --all

第二种方法

# 设置跟踪远程分支
git branch --set-upstream-to=origin/<branch> <branch> # git branch --set-upstream-to=origin/main main


# 查看是否跟踪
git branch -vv


# 下载数据
git fetch origin

# 查看是否有更新
git status

是否跟踪对比

git clone 远程项目,同步远程项目更新

git fetch origin #查看远程项目更新
git pull origin 远程分支：本地分支

git 版本标签

什么是版本标签？标签（Tag）是 Git 中的一个引用（reference），指向某个特定的提交。它通常用于标记一个稳定的发布版本，比如 v1 表示第一个正式版本。在 GitHub 上，标签还会显示在 Releases 页面，便于用户下载或查看。两种标签类型轻量标签（Lightweight Tag）：只是一个简单的指针，指向某个提交，不包含额外信息。附注标签（Annotated Tag）：包含额外元数据（如创建者、日期、描述），更常用于正式发布。

# 假设你已经完成代码更改并提交
git add .
git commit -m "Finalize version 1.0"

# 创建一个轻量标签（简单标记当前提交）
git tag v1

# 或者创建一个附注标签（带描述信息，推荐用于正式发布）
git tag -a v1 -m "Release version 1.0"

# 查看所有本地标签
git tag

# 推送单个标签到远程仓库（如 GitHub）
git push origin v1

# 或者推送所有标签到远程仓库
git push origin --tags

# （可选）如果需要删除本地标签
git tag -d v1

# （可选）如果需要删除远程标签
git push origin --delete v1

git merge详解

如果没有冲突，Git 会自动完成合并，并创建一个合并提交（merge commit，如果需要的话）。如果有冲突，Git 会暂停合并，提示你解决冲突（后面会讲怎么处理）。

无冲突的合并（Fast-forward）

如果 main 分支没有额外改动，而 feature 分支只是基于 main 增加了提交，Git 会执行"快进合并"（fast-forward）。这时候历史记录会变成一条直线，看起来像是直接在 main 上开发了一样。

有额外提交的合并（Merge Commit）

如果 main 和 feature 都有各自的提交，Git 会创建一个新的合并提交，保留两个分支的历史。命令一样：

git merge <分支名>

但是，合并后，Git 会自动生成一个 Merge commit，这样，从历史上看，分支信息就非常清楚。

冲突的合并当两个分支修改了同一文件的同一部分，Git 无法自动决定用哪个版本，就会报冲突。这时你需要手动解决：

运行 git merge feature 后，Git 会提示冲突文件。打开这些文件，冲突部分会被标记为：

<<<<<<< HEAD
（main 分支的内容）
=======
（feature 分支的内容）
>>>>>>> feature

编辑文件，保留你想要的部分，删除标记。解决完后，标记文件为已解决：“git add "，然后提交：“git commit -m ‘解决冲突’

实用技巧查看合并状态：用 git status 检查当前是否在合并过程中。中止合并：如果合并出了问题，想放弃，可以用：

git merge –abort

指定合并策略：默认情况下 Git 会自动选择合并方式，但你可以用选项调整，比如强制非快进合并：

git merge –no-ff feature

如何解决 “fatal: Need to specify how to reconcile divergent branches” 错误

问题根源：什么是“分支分叉”？

这个错误的核心原因是：您的本地分支和它所跟踪的远程分支，各自都有了新的、对方不知道的提交。

让我们用一个形象的例子来说明：

您和您的同事都在 main 分支上工作。你们最后一次同步时的代码状态是 Commit O。
之后，您在本地写了新功能，并创建了两个提交 A 和 B。
在您提交的这段时间里，您的同事完成了另一个任务，并将他的提交 C 和 D 推送（push）到了远程仓库。

这时，Git 的历史记录就变成了两条独立的路径，即“分叉”了：

A—B <– 您的本地 main 分支

—O—C—D <– 远程 origin/main 分支

当您执行 git pull 时，Git 发现它无法简单地“快进”（Fast-forward）来更新您的代码，因为它不知道应该如何处理这两条分叉的路径。为了避免自动操作可能带来的混乱，新版 Git 强制要求您必须明确告诉它您的合并策略。

二、核心概念：两种合并策略 Merge vs. Rebase

要解决分叉问题，您有两种主要的方法：Merge (合并) 和 Rebase (变基)。

方案 A：临时解决本次问题

您可以只在本次 pull 命令中指定策略。

使用 Rebase (推荐)：
```
git pull --rebase
```
这会用变基的方式拉取并应用远程更新。
使用 Merge：
```
git pull --no-rebase # 或者 git pull --merge
```
这会用传统合并的方式，并生成一个合并提交。

方案 B：永久配置默认行为 (一劳永逸)

为了避免每次都输入额外参数，您可以为 Git 设置一个全局的默认 pull 行为。

将 Rebase 设置为默认 (推荐)：

如果您喜欢干净的线性历史，这是大多数现代开发者的首选。
```
git config --global pull.rebase true
```
将 Merge 设置为默认：

如果您偏爱保留所有合并痕迹的传统方式。
```
git config --global pull.rebase false
```
更严格的 ff-only 策略：

还有一个选项是 fast-forward only。
```
git config --global pull.ff only
```
这个设置意味着，只有当您的本地分支没有任何新提交时（即可以“快进”时），git pull 才能成功。如果分支出现分叉，pull 会直接失败，强制您手动执行 git rebase 或 git merge，让您对每一次合并操作都更加谨慎。

|git pull|merge| git 多人协作的时候怎么解决冲突？

使用git-pull 然后git-commit 最后git-push

如果有冲突可以看get merge使用

使用rebase调换最后两个Commit的顺序


# Git 教程：使用 rebase 调换最后两个 Commit 的顺序



本教程将指导你如何使用 `git rebase -i`（交互式 rebase）来调换你本地最后两个 commit 的顺序。## 场景



你通过 `rebase` 将你的本地修改放在了远程分支的最新 commit 之上，但你现在希望反过来，让你自己的修改在前面，让远程的 commit 成为最后一个。**你当前的状态 (HEAD 指向你的修改):**

... -> 远程的最后一个commit -> 你的本地修改 (HEAD)



**你希望达到的状态 (HEAD 指向远程的 commit):**

... -> 你的本地修改 -> 远程的最后一个commit (HEAD)



---



## ⚠️ 重要警告



此操作会**重写 Git 历史**。



**请只在尚未将这些 commit 推送（push）到远程仓库时执行此操作。**

如果你已经推送了 `你的本地修改`，强行修改历史（`git push --force`）会给你的协作者带来严重问题。



---



## 操作步骤



### 步骤 1: 启动交互式 Rebase



你需要编辑最后两个 commit。运行以下命令来启动交互式 rebase，`HEAD~2` 表示“从 HEAD 开始往前数 2 个 commit”。



```bash

git rebase -i HEAD~2

步骤 2: 在编辑器中编辑 Rebase 列表

运行上述命令后，Git 会打开你的默认文本编辑器，显示一个列表。这个列表的顺序是从旧到新（从上到下）。

它看起来会是这样：

pick <hash_A> 远程的最后一个commit 的消息

pick <hash_B> 你的本地修改 的消息



# Rebase ...

# Commands:

# p, pick <commit> = use commit

# ...

pick <hash_A> 是那个较旧的 commit（远程的 commit）。

pick <hash_B> 是那个较新的 commit（你的本地修改）。

步骤 3: 调换 Commit 顺序

你只需要在编辑器中交换这两行的文本顺序，把你的本地修改放到上面（即让它更早发生）：

修改为：

pick <hash_B> 你的本地修改 的消息

pick <hash_A> 远程的最后一个commit 的消息

步骤 4: 保存并退出编辑器

保存文件并关闭编辑器。Git 会立即按照你指定的新顺序重新应用这两个 commit。

步骤 5: 验证结果

操作完成后，你可以使用 git log 来检查历史记录，确认顺序已经被正确调换。

Bash



# 查看最后两个 commit

git log --oneline -2

你现在应该会看到 远程的最后一个commit 的消息 在最上面（最新）的位置。

附录：如何在编辑器中快速调换行顺序

在步骤 3 中，你不需要手动剪切和粘贴。几乎所有编辑器都支持“移动当前行”的快捷键（将光标放在该行任意位置即可）。

常用 GUI 编辑器

Visual Studio Code (VS Code):

Windows / Linux: Alt + ↑ (上移) / Alt + ↓ (下移)

macOS: Option + ↑ (上移) / Option + ↓ (下移)

Sublime Text:

Windows / Linux: Ctrl + Shift + ↑ (上移) / Ctrl + Shift + ↓ (下移)

macOS: Cmd + Ctrl + ↑ (上移) / Cmd + Ctrl + ↓ (下移)

Notepad++:

Ctrl + Shift + ↑ (上移) / Ctrl + Shift + ↓ (下移)

常用终端编辑器 (Git 默认)

Vim / Vi (最常见的默认编辑器):

按 Esc 键确保你处于普通模式 (Normal Mode)。

将光标移动到你想移动的行。

输入 ddp：dd (剪切当前行) + p (粘贴到下一行)，效果是与下一行交换。

输入 ddkP：dd (剪切) + k (上移) + P (粘贴到上一行)，效果是与上一行交换。

(在你的场景中，光标在第二行 pick <hash_B> ... 上时，按 ddkP 即可)

Nano (较简单的编辑器):

Nano 没有直接的“移动行”快捷键，你必须使用剪切和粘贴：

将光标放在要移动的行上。

按 Ctrl + K (剪切该行)。

将光标移动到目标位置（例如，移动到第一行）。

按 Ctrl + U (粘贴该行)。

|公式 | github | github不显示md文件中的公式

第一种方法：使用github推荐的公式写法（推荐） 在写md的时候，使用

$` 和 `$

来包围行内公式

```math
和
 ```

来包围单行公式，如下

第二种方法：插件

但是还是会有一部分显示不正确

解决方法：安装插件：https://chrome.google.com/webstore/detail/mathjax-plugin-for-github/ioemnmodlmafdkllaclgeombjnmnbima/related

git 使用ssh密钥登录github

注意一个密钥只能登录一个github，如果你想要在新的github账户上面添加旧的ssh密钥，就会报错 准备工作：本地先下载安装好git，注册并登陆github账号在注册好后的github账号中先创建一个仓库在本地git创建SSH key 第一步：设置全局的用户名和邮箱（这样主要是不用总是重填）

git config --global user.name '用户名' // 切换到你的github用户名上
git config --global user.email 'github账号注册用的邮箱'

第二步：生成密钥，有可能提示没有这个库，需要安装一下，去搜索一下

ssh-keygen -t rsa -C "你的邮箱地址"

第三步：查看自己本地的密钥，执行以下命令

ls -al ~/.ssh // 查看本机是否有秘钥文件 没有秘钥文件生成秘钥文件
cd ~/.ssh
ls // 查看 .ssh 中有什么文件
cat id_rsa.pub // 查看本地的公钥
cat id_rsa // 查看本地的私钥
（如果是windows系统可以直接到C盘的对应用户名文件夹下的.ssh文件夹中查看）

第四步：将公钥复制粘贴到github上

github上点击头像，点击Settings，进入后点击 SSH and GPS keys，接着点击 New SSH key 将公钥粘贴在key输入框那里，Title则随便输入可以就行

`git 使用token登录github 并拉取项目` （如果电脑上已经登录过了，需要把账户信息清除掉。如果是用ssh密钥登录的也不行，清除token账户信息请看下面"清除电脑上已经登录的github账户信息”）

图1 打开设置	图2 开发者设置	图3 点击Token
图4 生成classic Token	图5 设置命名和权限

最后一步： 在新设备上pull或者push的时候，会让你登录，有两种方式，一种是账号密码，另一种就算token，选择token，然后粘贴上一步生成的token就可以了

github 要求2FA认证

今天上线的时候突然发现，github要求我设置2FA认证，不然就不能登录，手机号我必然是没有的，只能用安全密钥控制具体的github说明在这里：https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication

一句话说，就是需要用TOPT密钥管理工具生成动态密码，然后输入动态密码登录，然后第一次登录会给你一个github-recovery-codes.txt,如果更换设备需要使用这个恢复码登录新设备，然后登录新设备之后也是会给你一个新的恢复码

如果是第一次登录，看到github要求进行2FA，可以安装如下 chrome插件：Github 2FA（去chrome商店搜索）

然后你回到github页面刷新，在上面图片红框的那个位置就会出现一个30s的密码，输入就可以确认，确认好之后会让你下周恢复密钥，记得下载保存

github 清除电脑上已经登录的github账户信息

step1：进入控制面板点击用户账户

step2：管理windows凭证

step3：删除github相关的凭证

git config –global –add safe.directory 设置安全目录

命令用途 git config --global --add safe.directory 命令用于将指定的目录添加到 Git 的安全目录列表中，解决 Git 安全机制导致的仓库访问问题。

问题背景从 Git 2.35.2 开始，Git 引入了更严格的安全机制，默认情况下会拒绝访问由其他用户拥有的目录中的 Git 仓库。这通常发生在以下情况：

在 WSL (Windows Subsystem for Linux) 环境中
在共享目录或挂载的目录中
在 Docker 容器中访问宿主机目录
在多用户系统中

命令语法

git config --global --add safe.directory <directory-path>

使用示例

# 添加单个目录到安全目录列表
git config --global --add safe.directory /code/GRT

# 添加当前目录到安全目录列表
git config --global --add safe.directory "$(pwd)"

# 添加多个目录
git config --global --add safe.directory /path/to/repo1
git config --global --add safe.directory /path/to/repo2

查看当前安全目录列表

# 查看所有安全目录
git config --global --get-all safe.directory

# 查看所有全局配置
git config --global --list | grep safe.directory

删除安全目录

# 删除特定的安全目录
git config --global --unset-all safe.directory /code/GRT

# 删除所有安全目录配置
git config --global --unset-all safe.directory

常见错误信息当遇到安全目录问题时，Git 会显示类似以下的错误：

fatal: detected dubious ownership in repository at '/code/GRT'
To add an exception for this directory, call:
 git config --global --add safe.directory /code/GRT

安全注意事项

谨慎添加目录：只添加你信任的目录，避免添加系统关键目录
使用绝对路径：建议使用绝对路径而不是相对路径
定期检查：定期检查安全目录列表，删除不再需要的目录
环境隔离：在不同环境中使用不同的安全目录配置

替代方案如果不想使用全局配置，也可以：

使用本地配置：在特定仓库中使用 --local 而不是 --global
修改目录权限：确保目录的所有权正确
使用 Git 环境变量：设置 GIT_SAFE_DIRECTORIES 环境变量

验证配置配置完成后，可以验证是否生效：

# 进入目标目录
cd /code/GRT

# 尝试执行 Git 命令
git status

# 如果没有错误信息，说明配置成功

GitHub 分支保护规则（Rulesets）配置

在团队协作中，保护主分支（如 main）是非常重要的一项最佳实践。GitHub 提供了 Rulesets（规则集）功能，可以灵活地配置分支保护策略，而无需启用组织级别的付费功能。

下面介绍两种常见的配置方案：

方案一：极简保护（防删 + 防强制推送）

适用于个人仓库或小型项目，仅开启最核心的两项保护：

Restrict deletions — 限制删除匹配的分支，防止误删主分支。
Block force pushes — 阻止强制推送，避免历史被覆盖。

配置截图如下：

方案二：严格保护（推荐用于团队项目）

适用于多人协作的项目，要求更规范的代码合入流程：

Restrict deletions — 限制删除分支。
Require a pull request before merging — 必须通过 Pull Request 才能合并代码。
Require status checks to pass — 要求指定的 CI 检查通过后才能合并。例如：
- Python Quality Gate
- Frontend Build
Block force pushes — 阻止强制推送。

配置截图如下：

提示：Rulesets 对私有仓库完全免费即可使用。对于团队项目，建议至少开启「Require a pull request before merging」和「Require status checks to pass」，以保证代码质量和审计追踪。

`git clone 出现以下问题：fatal: unable to access XXX: gnutls_handshake() failed: The TLS connection was non-properly terminated.`

git clone 出现以下问题：fatal: unable to access 'https://github.com/QwenLM/Qwen.git/': gnutls_handshake() failed: The TLS connection was non-properly terminated.

可以参考stack overflow里面的Stack 我是执行下面两行代码解决（ubuntu系统）

apt-get update
apt-get install curl

`[git push] ssh: connect to host github.com port 22: Connection timed out fatal: Could not....`

最有可能是防火墙问题，可以参考github官方的解决方法用443端口解决 https://docs.github.com/en/authentication/troubleshooting-ssh/using-ssh-over-the-https-port

第一步,用以下代码测试443端口是否可用

ssh -T -p 443 git@ssh.github.com

如果出现这样就是可用的，那么恭喜，十拿九稳了！用如下ssh地址替代原来的

git clone ssh://git@ssh.github.com:443/YOUR-USERNAME/YOUR-REPOSITORY.git

注意是替代，直接用原来的地址加端口是不行的。

拿下！

`远程分支是v3版本，本地的v2版本，但是本地修改了文件还没有add也没有commit，应该怎么更新本地？`

1. 第一步：首先保存你的本地修改：

git stash

这会将你当前的修改暂时保存起来

2. 第二步：拉取远程更新

git fetch origin

3. 第三步：更新本地分支到远程版本

git merge FETCH_HEAD

4. 第四步，恢复你之前的本地修改

cpp git stash pop

5. 如果在恢复 stash 时遇到冲突，你需要手动解决这些冲突。解决完冲突后，你可以:

添加解决冲突后的文件 git add .

提交你的修改 git commit -m “your commit message”

提示：

如果你想在应用 stash 前查看保存了什么内容，可以用 git stash list 查看 stash 列表如果你想查看具体改动，可以用 git stash show -p 如果合并时遇到问题，随时可以用 git status 查看当前状态如果想放弃当前操作回到起点，可以用 git reset –hard HEAD（注意这会丢失未提交的修改）

用githooks解决github大文件报错100M限制或50M限制-大文件-50M-githooks-git

如果你已经commit了大文件，并且报错了，可以使用下面方法，基本上都起作用

apt-get install git-filter-repo

# 删除指定的大文件（路径必须完全匹配）
git filter-repo --path "路径地址" --invert-paths

如果还没有提交

# 1. 把大文件取消追踪
git rm --cached "path/to/large/file" # 引号括起来的是大文件地址
# 2. 把大文件加入.gitignore
echo "path/to/large/file" >> .gitignore
# 3. 更改提交 （当然不commit直接git push XXX 也是可以的）
git add .gitignore
git commit -m "Update .gitignore to exclude large files"
git push XXX main:main --force

如果已经在过去的几次commit提交了，并且知道在哪个commit开始出现，可以使用以下方法

# 1. 撤销最近的提交，但保留更改
git reset --soft HEAD~1
# 如果大文件在更早的提交（比如倒数第二次），用 HEAD~2 或具体哈希：
# git reset --soft abc123^ # abc123 是包含大文件的提交

# 2. 移除大文件
git rm --cached "大文件名"

# 3.重新提交
git commit -m "Remove large file XXX"

# 4. 强制推送
git push XXX main:main --force

我写了一个git hooks 文件，在commit大于设定size的文件的时候，拦截commit，并且把大文件名写入.gitignore ，同时从缓存区中移除大文件进行版本控制的时候，经常会由于大文件导致上传github出问题，并且版本回退也比较麻烦。实际上我们很少代码文件会超过50M，而往往是由于数据文件过大导致错误，这些数据文件往往我们可能都不需要进行版本控制于是，不如直接通过脚本，默认不对这些大文件进行版本控制

代码（文件名设置为pre-commit，防在.git/hooks目录下，注意文件名要一致，这涉及到git hooks的逻辑，不做过多解释）


#!/usr/bin/env python3
# 我在2025年之前用的是 #!/bin/python,但是报错了，改成了上面的内容
import subprocess
import os


if __name__ == "__main__":
 files = subprocess.check_output(['git', 'diff', '--cached', '--name-status'], text=True, encoding='utf-8').split('\n')
 for file in files:
 if len(file.split("\t")[0]) > 0 and file.split("\t")[0] != 'D':
 file_path = file.split("\t")[-1]
 file_size = os.path.getsize(file_path)
 size_in_mb = file_size / (1024 * 1024)
 if size_in_mb >= 50:
 with open('.gitignore', 'a', encoding='utf-8') as f:
 f.write(file_path + '\n')
 try:
 # Remove the file from the Git index (staged area)
 subprocess.check_output(['git', 'rm', '--cached', file_path])
 print("Removed {} from stage".format(file_path))
 except subprocess.CalledProcessError as e:
 print("Error removing file from stage: {}".format(e))

 try:
 # Reset the file to unstage changes
 subprocess.check_output(['git', 'reset', file_path])
 except subprocess.CalledProcessError as e:
 print("Error while resetting file: {}".format(e))

 print("The file is larger than 50MB and has been added to .gitignore. Please confirm and recommit!")
 print(file_path + "\n")
 exit(1)

下面可以配置全局Git 钩子

LINUX平台

# 创建全局 Git 钩子目录
mkdir -p ~/.git-template/hooks

# 创建并编辑 pre-commit 钩子脚本
cat > ~/.git-template/hooks/pre-commit << 'EOF'
#!/bin/bash
MAX_SIZE=$((50 * 1024 * 1024)) # 50MB in bytes

# 获取暂存区所有文件的列表
files=$(git diff --cached --name-only --diff-filter=ACM)

for file in $files; do
 # 检查文件是否存在
 if [ -f "$file" ]; then
 # 获取文件大小（字节）
 size=$(stat -f%z "$file" 2>/dev/null || stat -c%s "$file" 2>/dev/null)
 if [ "$size" -gt "$MAX_SIZE" ]; then
 echo "错误：文件 '$file' 超过 50MB（大小：$((size / 1024 / 1024))MB）"
 exit 1
 fi
 fi
done
exit 0
EOF

# 赋予执行权限
chmod +x ~/.git-template/hooks/pre-commit

# 配置 Git 使用全局钩子模板
git config --global init.templatedir ~/.git-template

# （可选）为现有仓库手动复制钩子（替换 /path/to/your/repo 为实际路径）
# cp ~/.git-template/hooks/pre-commit /path/to/your/repo/.git/hooks/pre-commit
# chmod +x /path/to/your/repo/.git/hooks/pre-commit

WINDOWS平台

需要 POWERSHELL 因为环境变量

# 创建全局 Git 钩子目录
$templateDir = "$env:USERPROFILE\.git-template\hooks"
New-Item -ItemType Directory -Force -Path $templateDir

# 创建 pre-commit 钩子脚本
$hookPath = "$templateDir\pre-commit"
Set-Content -Path $hookPath -Value @'
#!/bin/sh
MAX_SIZE=$((50 * 1024 * 1024)) # 50MB in bytes

# 获取暂存区所有文件的列表
files=$(git diff --cached --name-only --diff-filter=ACM)

for file in $files; do
 # 检查文件是否存在
 if [ -f "$file" ]; then
 # 获取文件大小（字节）
 size=$(wc -c < "$file")
 if [ "$size" -gt "$MAX_SIZE" ]; then
 echo "错误：文件 '$file' 超过 50MB（大小：$((size / 1024 / 1024))MB）"
 exit 1
 fi
 fi
done
exit 0
'@

# 赋予执行权限（Windows 下无需 chmod，但确保 Git Bash 支持）
# 配置 Git 使用全局钩子模板
git config --global init.templatedir "$env:USERPROFILE\.git-template" # 如果你不用变量，那么就赋绝对路径

# （可选）为现有仓库手动复制钩子（将以下路径替换为实际仓库路径）
# $repoPath = "C:\path\to\your\repo"
# Copy-Item -Path $hookPath -Destination "$repoPath\.git\hooks\pre-commit"

也可以按照下面进行手动配置

首先创建一个文件夹，然后git init，可以手动将上面代码粘贴修改pre-commit文件

配置全局钩子，需要绝对路径

可以测试一下，原理就是git init的时候，把设置的这些配置复制一份

cannot_lock_ref_error

root@ce4322c051c6:/codes/dataAnalysisModels# git pull
remote: Enumerating objects: 193, done.
remote: Counting objects: 100% (193/193), done.
remote: Compressing objects: 100% (178/178), done.
remote: Total 191 (delta 10), reused 188 (delta 10), pack-reused 0 (from 0)
Receiving objects: 100% (191/191), 115.48 MiB | 149.00 KiB/s, done.
Resolving deltas: 100% (10/10), completed with 2 local objects.
error: cannot lock ref 'refs/remotes/zata/main': is at 801efa1db3242f2be077de0d34e4eb29af0a5751 but expected aab6c46b69629454c3ad76e5a030157169eabb6e
From github.com:zata-zhangtao/dataAnalysisAndModeling_In-GY
 ! aab6c46..801efa1 main -> zata/main (unable to update local ref)

我的解决方法是

git fetch --prune
git pull

云服务器无法访问Github导致git失败方案

可以先去这个网站，哪些ip可用

https://ping.chinaz.com/github.com

然后要修改服务器端的HOSTS

例如：

20.205.243.166 github.com
20.205.243.166 raw.githubusercontent.com

hosts位置在 /etc/hosts

知识点

GitHub Actions 密钥管理全指南：Repository、Environment 与 Organization Secrets 的区别与最佳实践

在配置 GitHub Actions CI/CD 流水线时，管理敏感信息（API Key、数据库密码、部署 Token）是重中之重。GitHub 提供了多种存储 Secrets（密钥）的方式，最常见的是 Repository Secrets，但你可能也注意到了 Environment Secrets 和 Organization Secrets。

它们到底有什么区别？如果我想让一个变量在几十个仓库里通用，又该怎么办？这篇文章将为你彻底理清这三者的关系、优先级和最佳应用场景。

一、Repository Secrets vs. Environment Secrets

这是最基础的两个概念，决定了你的密钥是在“仓库级别”可见，还是在“特定部署环境”下可见。

1. Repository Secrets (仓库级密钥)

这是最常用的类型。

位置：Settings -> Secrets and variables -> Actions -> Repository secrets
作用域：整个代码仓库。仓库内的任何 Workflow、任何分支、任何 Job 都可以直接读取。
适用场景：
- 通用的 CI 工具 Token（如 Codecov, SonarQube）。
- 构建阶段需要的非敏感于环境的凭证（如拉取私有 Docker 镜像的 Token）。

2. Environment Secrets (环境级密钥)

这是为 CD（持续部署）设计的更高级功能。

位置：Settings -> Environments -> 选择环境（如 production） -> Environment secrets
作用域：仅限在 Workflow YAML 中明确指定了该环境的 Job。
核心优势：
1. 部署保护（Deployment Protection Rules）：你可以设置 Required reviewers (人工审批)。例如，Workflow 运行到部署生产环境的步骤时会暂停，直到管理员点击"Approve”，代码才能拿到 Environment Secret 并继续执行。
2. 同名变量覆盖：允许开发环境和生产环境使用同一个变量名（如 DB_HOST），但值不同。

代码示例：如何使用 Environment Secret

jobs:
 deploy-prod:
 runs-on: ubuntu-latest
 # 关键点：必须声明 environment，才能读取到该环境下的 Secret
 environment: production 
 steps:
 - name: Deploy
 env:
 # 如果 production 环境里定义了 API_KEY，这里读到的就是生产环境的 Key
 API_KEY: ${{ secrets.API_KEY }}
 run: ./deploy.sh

3. 对比总结

特性	Repository Secrets	Environment Secrets
可见性	所有 Job 可见	仅声明 `environment: xxx` 的 Job 可见
审批机制	不支持	支持人工审批、等待计时器等
优先级	较低	最高 (覆盖同名 Repository Secret)
典型用途	单元测试、Lint 检查、构建镜像	生产环境数据库密码、AWS 生产证书

二、进阶痛点：我想定义所有仓库都能用的变量怎么办？

当你拥有 20 个微服务仓库，且都需要使用同一个 NPM Token 或者 Slack 通知 Webhook URL 时，在每个仓库里重复配置 Repository Secrets 会让人崩溃。

这时你需要 Organization Secrets (组织级密钥)。

1. 什么是 Organization Secrets？

位置：组织主页 -> Settings -> Secrets and variables -> Actions。
前提：你的仓库必须属于一个 Organization（组织账号），个人账号不支持此功能。

2. 强大的访问策略 (Access Policy)

在创建组织密钥时，你可以控制它的传播范围：

All repositories：组织下所有（现有和未来新建的）仓库都能自动读取。
Private repositories only：仅私有仓库可用（防止开源项目泄露公司 Token）。
Selected repositories：手动勾选特定仓库可用（推荐，遵循最小权限原则）。

3. Organization Variables (组织级变量)

除了加密的 Secrets，GitHub 还允许在组织级定义 Variables（明文变量）。

适用于非敏感配置，如 API_BASE_URL、COMPANY_NAME。
在代码中通过 ${{ vars.MY_VAR }} 访问。

三、终极问题：同名变量的优先级（覆盖逻辑）

如果我在 Organization、Repository 和 Environment 里都定义了同一个名字的变量（比如 DATABASE_URL），GitHub 会读取哪一个？

遵循 “越具体，优先级越高” 的原则：

Environment Secrets (最高优先级) 👑
Repository Secrets (中等优先级)
Organization Secrets (最低优先级)

实战场景：

你在 组织级 设置了 SLACK_WEBHOOK 用于日常通知。
突然有个特定仓库 Project-X 需要发送通知到另一个独立的 Slack 频道。
你只需在 Project-X 的 Repository secrets 里新建一个同名的 SLACK_WEBHOOK。
GitHub 会自动优先使用仓库级的配置，而不会影响组织内其他 99 个仓库。

四、最佳实践决策清单

在创建变量前，请对照此清单选择存储位置：

这个变量是所有（或多个）项目通用的吗？
- 是 -> Organization Secrets (如：公司通用的 NPM Token, Slack Webhook)。
- 否 -> 往下看。
这个变量涉及“生产环境”或“高风险”操作吗？
- 是（如 AWS Prod Key, 生产库密码）-> Environment Secrets (并开启人工审批保护)。
- 否 -> 往下看。
这个变量需要在不同的环境（Dev/Test/Prod）有不同的值吗？
- 是 -> Environment Secrets (在不同环境里设同名变量)。
- 否 -> 往下看。
默认选项：
- 上述情况都不是 -> Repository Secrets。

结语

掌握这三个层级的 Secrets 管理，不仅能让你的 GitHub Actions Workflow 代码更简洁（由 if/else 地狱转变为统一变量名），还能大幅提升 CI/CD 流程的安全性。

Tip: 如果你是个人开发者账号，无法使用 Organization Secrets，建议创建一个免费的 Organization 并将仓库 Transfer 进去，以便享受全局变量管理的便利。

将Python包发布到GitHub并通过pip安装的教程

创建Python包结构
构建以下目录结构：

your_package/
├── your_package/
│ ├── __init__.py
│ └── your_module.py
├── setup.py
├── README.md
├── LICENSE
└── requirements.txt

编写关键文件

setup.py 示例：

from setuptools import setup, find_packages

setup(
 name='your_package_name',
 version='0.1.0',
 packages=find_packages(),
 install_requires=[
 'requests>=2.25.1',
 ],
 author='Your Name',
 author_email='your.email@example.com',
 description='A short description of your package',
 long_description=open('README.md').read(),
 long_description_content_type='text/markdown',
 url='https://github.com/yourusername/your_package',
 classifiers=[
 'Programming Language :: Python :: 3',
 'License :: OSI Approved :: MIT License',
 ],
)

your_package/init.py：
```
__version__ = '0.1.0'
```

初始化Git并上传到GitHub

git init
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/yourusername/your_package.git
git branch -M main
git push -u origin main

创建GitHub Release（可选，但推荐）
- 访问GitHub仓库页面，点击"Releases" -> “Create a new release”
- 输入版本号（如v0.1.0），发布

通过pip安装

直接从GitHub安装：

pip install git+https://github.com/yourusername/your_package.git

指定分支：

pip install git+https://github.com/yourusername/your_package.git@branch_name

指定版本（需要有release）：

pip install git+https://github.com/yourusername/your_package.git@v0.1.0

发布到PyPI（可选，允许标准pip安装）
- 安装工具：
```
pip install twine build
```
- 构建包：
```
python -m build
```
- 上传到PyPI：
```
twine upload dist/*
```
- 之后可使用：
```
pip install your_package_name
```

注意事项：

确保setup.py信息准确
设置清晰的GitHub仓库描述和topics
使用MIT或其他合适的许可证
编写详细的README.md，包含安装和使用说明
发布到PyPI需注册账号并配置API token

git-reset—hard-head-详解andgit-reset—soft-head-详解

git reset --hard HEAD

效果：

撤销所有未提交的更改（包括工作目录和暂存区）。 HEAD 指向的提交成为当前状态，之前的修改全部丢失（不可恢复，除非有其他备份）。

git reset --soft HEAD

功能：将当前分支的指针重置到 HEAD 指向的提交，但保留工作目录和暂存区的所有更改。效果：

撤销最近的提交（将 HEAD 指针移到当前提交），但修改的内容仍保留在工作目录或暂存区。可以重新调整或重新提交这些更改。

下面我将逐个参数解释这条命令的含义：

命令分解

git reset:
- git reset 是 Git 用来重置当前分支的 HEAD（当前分支指针）到指定状态的命令。
- 它可以影响 Git 的三个主要区域：
  - 工作目录（Working Directory）：你当前编辑的文件。
  - 暂存区（Staging Area/Index）：通过 git add 添加的文件。
  - 提交历史（Commit History）：Git 仓库中的提交记录。
--hard:
- --hard 是 git reset 的一个选项，指定重置的模式。
- 它表示完全重置，不仅会移动 HEAD 指针，还会：
  - 重置工作目录中的文件内容，使其与指定的提交状态一致。
  - 清空暂存区的内容。
  - 丢弃所有未提交的更改（包括工作目录和暂存区的修改）。
- 简单来说，--hard 会让你的工作目录、暂存区和提交历史完全恢复到指定的提交状态，不可恢复已丢弃的更改。
HEAD^:
- HEAD 是 Git 中的一个指针，指向当前分支的最新提交。
- ^ 是一个相对引用，表示"当前 HEAD 的上一个提交"（即父提交）。
- 因此，HEAD^ 表示当前分支最新提交的上一个提交。
- 如果当前分支的提交历史是 A <- B <- C（C 是 HEAD），那么 HEAD^ 指向 B。

整体含义 git reset --hard HEAD^ 的作用是：

将当前分支的 HEAD 指针移动到上一个提交（HEAD^）。
重置工作目录和暂存区，使其与 HEAD^ 指向的提交状态完全一致。
丢弃当前 HEAD 提交（最新提交）以及工作目录和暂存区的所有未提交更改。

示例场景假设你的提交历史如下：

A <- B <- C (HEAD)

githook脚本版本控制管理

在 Git 项目中，.githooks 目录中的钩子（hook）脚本默认是不会被 Git 版本控制系统自动纳入版本管理的，因为 .githooks 目录通常被视为本地配置的一部分。为了将 Git 钩子脚本保留到项目中并与团队共享，你需要采取一些额外的步骤。以下是具体的方法：

方法一：将钩子脚本纳入版本控制

将 .githooks 目录重命名或移动到项目中：
- 默认情况下，Git 钩子存储在 .git/hooks 目录中，这些文件不会被 Git 跟踪。你可以将钩子脚本移动到项目的一个自定义目录（例如 githooks 或 hooks），并纳入版本控制。
- 示例：
```
mkdir githooks
mv .git/hooks/pre-commit githooks/pre-commit
```
配置 Git 使用自定义钩子目录：
- 使用以下命令告诉 Git 使用项目中的自定义钩子目录：
```
git config core.hooksPath githooks

 cd githooks
# 查找所有文件 (f) 并赋予执行权限 
find . -type f -exec chmod +x {} \;
```
- 这会让 Git 使用 githooks 目录中的钩子脚本，而不是默认的 .git/hooks。
将钩子脚本提交到版本控制：
- 将 githooks 目录添加到 Git 版本控制：
```
git add githooks
git commit -m "Add git hooks to project"
git push
```
团队成员同步配置：
- 其他团队成员在克隆或拉取项目后，需要手动运行 git config core.hooksPath githooks 来启用自定义钩子路径。或者，你可以通过脚本自动设置。

方法二：使用脚本自动安装钩子为了让团队成员无需手动配置 core.hooksPath，你可以在项目中添加一个安装脚本，自动将钩子脚本复制到 .git/hooks 目录。

创建安装脚本：
- 在项目根目录创建一个脚本（例如 install-hooks.sh）：
```
#!/bin/bash
cp githooks/* .git/hooks/
chmod +x .git/hooks/*
echo "Git hooks installed successfully."
```
- 这个脚本会将 githooks 目录中的钩子复制到 .git/hooks 目录，并确保它们具有可执行权限。

添加到版本控制：

将 install-hooks.sh 和 githooks 目录提交到 Git：

git add githooks install-hooks.sh
git commit -m "Add git hooks and install script"
git push

运行安装脚本：
- 团队成员在克隆项目后，运行以下命令来安装钩子：
```
./install-hooks.sh
```

方法三：使用 Git 模板目录如果你希望钩子脚本在所有新项目中自动生效，可以配置 Git 的全局模板目录：

创建全局钩子模板：
- 复制默认的 Git 钩子模板到自定义目录：(如果你还没有自定义模板目录，可以通过下面的代码创建一个)
```
git init --template=/path/to/custom-template
```
- 在 /path/to/custom-template/hooks 中添加你的钩子脚本。
也可以配置全局模板路径就不用第一步了：
- 设置 Git 的全局模板路径：
```
git config --global init.templateDir /path/to/custom-template
```
- 之后，任何新初始化的 Git 仓库都会使用这个模板。
- 具体的使用和介绍可见shou 配置钩子脚本，请查看用git hooks解决github大文件报错，100M限制或50M限制|大文件|50M|git hooks|git。
注意事项：
- 这种方法适合个人开发环境，但不适合团队项目，因为模板目录是本地的，无法直接共享。

方法四：使用工具管理钩子可以使用一些工具来简化 Git 钩子的管理和共享，例如：

Husky（适用于 Node.js 项目）：
- 如果你的项目是 Node.js 项目，可以使用 Husky 来管理 Git 钩子。安装 Husky 后，它会自动管理 .git/hooks 目录，并在 package.json 中定义钩子脚本。
- 安装：
```
npm install husky --save-dev
```
- 配置（在 package.json 中）：
```
"husky": {
 "hooks": {
 "pre-commit": "echo 'Running pre-commit hook'"
 }
}
```
pre-commit（适用于 Python 项目）：
- 如果是 Python 项目，可以使用 pre-commit 框架来管理钩子。创建一个 .pre-commit-config.yaml 文件，定义钩子脚本，并提交到版本控制。
- 安装：
```
pip install pre-commit
pre-commit install
```

注意事项

权限问题：
- 确保钩子脚本具有可执行权限（chmod +x githooks/*）。
- 在 Windows 系统上，可能需要额外处理文件权限问题。
跨平台兼容性：
- 如果团队成员使用不同操作系统（例如 Windows 和 Linux），确保钩子脚本是跨平台的（例如，使用 Bash 脚本或 Python 脚本）。
文档说明：
- 在项目的 README.md 中添加说明，告诉团队成员如何启用钩子（例如运行 install-hooks.sh 或设置 core.hooksPath）。
避免覆盖本地钩子：
- 如果直接覆盖 .git/hooks，可能会覆盖团队成员的本地钩子配置。使用 core.hooksPath 或脚本复制的方式更安全。

总结最推荐的方式是将钩子脚本放入项目中的 githooks 目录，提交到版本控制，并通过脚本或 git config core.hooksPath 自动配置。结合工具如 Husky 或 pre-commit 可以进一步简化管理。根据项目类型和团队习惯选择合适的方法。

当前 HEAD 指向提交 C。
执行 git reset --hard HEAD^ 后：
- HEAD 移动到 B（HEAD^）。
- 提交 C 从当前分支的提交历史中移除（但可能仍存在于 Git 的对象数据库中，直到被垃圾回收）。
- 工作目录和暂存区的内容恢复到提交 B 的状态。
- 任何未提交的更改（工作目录或暂存区）都会被永久删除。

新的提交历史变为：

A <- B (HEAD)

注意事项

数据丢失风险：--hard 会永久删除未提交的更改和指定的提交（HEAD 到 HEAD^ 之间的提交）。在执行前，建议使用 git status 检查是否有未提交的更改，或者用 git log 确认提交历史。
备份建议：如果不确定是否需要丢弃更改，可以先用 git branch backup 创建一个备份分支，以保留当前 HEAD 的状态。
远程仓库影响：如果当前分支已经推送到远程仓库（如 GitHub），执行 git reset --hard HEAD^ 后需要用 git push --force 强制推送，这可能会影响其他协作者，需谨慎操作。

总结

git reset: 重置 HEAD 到指定状态。
--hard: 完全重置，丢弃工作目录和暂存区的更改。
HEAD^: 指向当前 HEAD 的上一个提交。

这条命令的总体效果是"撤销最近一次提交并恢复到上一个提交的状态，同时丢弃所有未提交的更改"。如果你只是想撤销提交但保留更改，可以考虑使用 git reset --soft HEAD^ 或其他命令（如 git revert）。

实战 – 使用

软件版本管理与热修复流程

这是一个非常经典的软件版本管理问题。在真实的开发场景中非常常见，通常被称为**“热修复”（Hotfix）或“补丁发布”（Patch Release）**。

为了在不影响 0.6.0 开发进度的情况下修复 0.5.0 的 bug，你需要基于 0.5.0 的代码拉取一个新分支，修复 bug 后发布 0.5.1，然后再把修复代码同步回 main 分支。

以下是标准的处理流程（假设你使用的是 Git）：

第一步：找到 0.5.0 的代码并拉取新分支

通常你在发布 0.5.0 时会打一个标签（Tag），或者你能找到发布 0.5.0 时的那个 Commit 记录。我们需要基于这个点创建一个专门用于修复和发布的分支（比如叫 hotfix-0.5.1 或 release-0.5.x）：

 # 假设你的 0.5.0 标签名为 v0.5.0
git checkout -b hotfix-0.5.1 v0.5.0

 # 如果你没有打标签，可以找到当时的 commit hash（比如 a1b2c3d）
git checkout -b hotfix-0.5.1 a1b2c3d

第二步：在新分支上修复 Bug 并修改版本号

现在你的代码状态已经完全回退到了 0.5.0 发布时的样子。在这里修复那个 bug，并将项目配置文件中的版本号从 0.5.0 修改为 0.5.1（如果你有 package.json、pom.xml 等文件的话）。提交你的代码：

git add .
git commit -m "fix: 修复了 0.5.0 版本的严重 bug"
git commit -m "chore: 升级版本号至 0.5.1"

第三步：发布 0.5.1

现在你可以基于这个 hotfix-0.5.1 分支去打包、测试并发布产品了。发布完成后，别忘了打上新标签：

git tag v0.5.1
git push origin v0.5.1
git push origin hotfix-0.5.1

到这一步，你的用户已经可以拿到没有 bug 的 0.5.1 版本了，而你的 main 分支毫无影响。

第四步：将修复代码同步回 main 分支（极其重要！）

这一步绝对不能忘！否则你以后发布 0.6.0 时，这个 bug 还会再次出现（也就是所谓的回归 bug）。你有两种常见的方式将修复同步回 main：

方式 A：合并分支（Merge）—— 适合 Git Flow 等标准工作流

git checkout main
git merge hotfix-0.5.1
 # 如果有冲突，解决冲突后提交
git push origin main

注意：这可能会把 0.5.1 的版本号更改也合并进来，你可能需要在 main 分支再次修改版本号回 0.6.0-dev。

方式 B：摘取提交（Cherry-pick）—— 很多团队更喜欢这种，因为它更干净

如果你在 hotfix-0.5.1 分支上只有一两个修复 bug 的 Commit，你可以只把修复 bug 的代码拿过来，而不拿修改版本号的代码：

 # 1. 先用 git log 看一下你修复 bug 的那个 commit 的 hash 值（比如 f8e9d0c）
 # 2. 切换回 main 分支
git checkout main
 # 3. 将修复代码“摘”过来
git cherry-pick f8e9d0c
git push origin main

总结流程图

 (0.5.0) -----------------------------------> (0.6.0) [main 分支]
 | ^
 | | (同步修复代码 Merge 或 Cherry-pick)
 +--->[修 bug] ---> (发布 0.5.1) --------------+ [hotfix 分支]

通过这种方式，既保证了 0.5.0 用户的可用性，又让 main 分支可以继续安心开发 0.6.0 的新功能。

关于 Main 分支的历史记录问题

这个问题非常关键！答案是：这取决于你用哪种方式（Merge 还是 Cherry-pick）把代码同步回 main。准确地说，你关心的“记录”分为两种：修复 Bug 的代码记录（比如提交信息：“fix: 修复了 xxx”）和 0.5.1 的发布记录（比如提交信息：“chore: 升级版本号至 0.5.1” 以及 v0.5.1 的标签 Tag）。

情况一：如果你使用的是 Cherry-pick（摘取）—— 推荐方式

如果你采用的是 cherry-pick，你只把“修复 Bug"的那个 commit 拿到了 main 分支。在 main 的历史中：

能看见： 修复 Bug 的记录（但 Git 会为它生成一个新的 Commit Hash）。
看不见： 任何关于"0.5.1"字眼的记录（包括改版本号的 commit 和 0.5.1 的 tag 都不会在 main 上出现）。

结果：main 分支的历史非常干净，看起来就像是在开发 0.6.0 的过程中顺手修了一个 bug，历史记录是一条直线向前。

Cherry-pick 后的 main 记录看起来像这样：

 * 9b8c7d6 (HEAD -> main) fix: 修复了导致崩溃的严重 bug <-- 这是 cherry-pick 过来的新 commit
 * 5a4b3c2 feat: 0.6.0 的新功能 B
 * 4z3y2x1 feat: 0.6.0 的新功能 A
 * a1b2c3d (tag: v0.5.0) release: 发布 0.5.0

情况二：如果你使用的是 Merge（合并）

如果你直接在 main 分支执行 git merge hotfix-0.5.1。在 main 的历史中：

能看见： 0.5.1 分支上的所有记录，原封不动地出现在了这里。
能看见： “chore: 升级版本号至 0.5.1” 的提交。
能看见： 一个额外的合并记录（比如 “Merge branch ‘hotfix-0.5.1’ into main”）。

结果：你的 main 分支历史里会混入 0.5.1 的发布痕迹。如果在合并时遇到了代码冲突（比如 main 的版本号已经改成了 0.6.0-dev，而 hotfix 改成了 0.5.1），你还需要手动解决冲突，保留 0.6.0-dev。

Merge 后的 main 记录看起来像这样：

 * d4e5f6g (HEAD -> main) Merge branch 'hotfix-0.5.1' into main <-- 合并节点
 |\
 | * f8e9d0c (tag: v0.5.1, hotfix-0.5.1) chore: 升级版本号至 0.5.1 <-- 0.5.1 的痕迹进来了
 | * e7d8c9b fix: 修复了导致崩溃的严重 bug
 * | 5a4b3c2 feat: 0.6.0 的新功能 B
 * | 4z3y2x1 feat: 0.6.0 的新功能 A
 |/
 * a1b2c3d (tag: v0.5.0) release: 发布 0.5.0

总结与建议

如果你不想在 main 分支里看到 0.5.1 这种历史版本号的“噪音”，只想要修复 bug 的代码，那么极其建议使用 cherry-pick。

这是大型开源项目（比如 Vue, React）和大多数商业公司的标准做法：

main 分支永远只看前方（0.6.0、0.7.0）。
旧版本（0.5.0）出了问题，在旧版本对应的分支（hotfix-0.5.x）上修补并发布 0.5.1。
把修补代码像“摘樱桃”一样（cherry-pick）摘回 main 分支。

这样 main 里就看不见 0.5.1 的版本发布记录，但 Bug 确实被修好了。

变基合并多个提交

# 例:变基合并最近2个提交
git rebase -i HEAD~2

这个命令会打开你的默认文本编辑器（通常是 Vim、VSCode 或 Nano），显示类似以下内容：

pick c2b3a4d 实现用户登录API
pick d3c4b5a 添加输入验证
pick e4d5c6b 移除调试日志
pick f5e6d7a 修复拼写错误

# 变基 b1a2b3c..f5e6d7a 到 b1a2b3c（4个提交）
#
# 命令:
# p, pick <提交> = 使用提交
# r, reword <提交> = 使用提交，但编辑提交信息
# e, edit <提交> = 使用提交，但停下来修改提交
# s, squash <提交> = 使用提交，但合并到前一个提交
# f, fixup <提交> = 类似于"squash"，但丢弃提交信息
# x, exec <命令> = 使用shell运行命令（其余行）
# b, break = 在此处停止（稍后用'git rebase --continue'继续）
# d, drop <提交> = 删除提交
# l, label <标签> = 用名称标记当前HEAD
# t, reset <标签> = 重置HEAD到标签
# m, merge [-C <提交> | -c <提交>] <标签> [# <单行信息>]
# . 创建合并提交，使用原合并提交的信息（如果没有原合并提交，则使用单行信息）

我们需要将后面的3个提交"压缩"（squash）到第一个提交中。编辑文件如下：

pick c2b3a4d 实现用户登录API
squash d3c4b5a 添加输入验证
squash e4d5c6b 移除调试日志
squash f5e6d7a 修复拼写错误

保存并关闭编辑器。Git 会开始处理这些提交，然后再次打开编辑器让你编辑合并后的提交信息。

第四步：编写合并后的提交信息

你会看到一个新的编辑器窗口，显示所有被合并提交的信息：

# 这是一个合并了4个提交的组合提交。
# 第一个提交信息：
实现用户登录API

# 这是第二个提交信息：
添加输入验证

# 这是第三个提交信息：
移除调试日志

# 这是第四个提交信息：
修复拼写错误

# 请输入新的提交信息，以说明此组合提交的更改。
# 以'#'开头的行将被忽略，空信息会中止提交。

删除所有内容，编写一个新的、更有意义的提交信息

保存并关闭编辑器，Git 就会完成变基操作。

多轮代码提交后才发现重大Bug？如何优雅地修改“上上个” Commit

这是一个为你整理好的博客笔记模板，标题和结构都优化过了，适合发布在 CSDN、掘金、Notion 或个人博客上。

📌 问题场景

我在开发中遇到了一个棘手的情况：

位置：倒数第三个 Commit (HEAD~2) 提交的代码有问题。
需求：我需要对这个 Commit 进行大规模的修改/重构。
工具：VS Code。

直接提交一个新的 Fix Commit 虽然简单，但会让 Git 历史变得脏乱。作为有追求的工程师，我希望历史记录干净整洁。本文记录了两种处理方案：“手术刀模式 (Rebase)” 和 “推土机模式 (Reset)”。

🛡️ 核心前提：建立安全沙盒

在修改 Git 历史前，永远不要直接在主分支（如 main/dev）上操作！ 一旦操作失误（如变基失败），很难恢复。

正确做法：新建一个临时分支进行"实验"。

git checkout -b fix-old-commit
# 所有的修改都在这个分支上进行，确认无误后再合并回主分支或强推。

方案一：手术刀模式 (Interactive Rebase)

适用场景：只想精准修复那个错误的 Commit，且必须保留它后面提交的 Commit 记录（例如后面的提交是别人写的，或者与当前修改无关）。

操作步骤

启动变基：在 VS Code 终端输入命令，回溯到前 3 个版本：

git rebase -i HEAD~3

标记要修改的 Commit： Git 会弹出一个编辑器（或 git-rebase-todo 文件），找到那个有问题的 Commit，将行首的 pick 修改为 edit。

pick -> edit

修改代码：保存并关闭文件后，Git 会暂停在那个 Commit 的时间点。此时在 VS Code 中进行大规模的代码修改。
提交修正：改完后，暂存文件并修补当前 Commit：

git add .
git commit --amend --no-edit

完成变基：应用后续的提交，回到现代：

git rebase --continue

(如果有冲突，在 VS Code 中解冲突 -> add -> continue 即可)

方案二：推土机模式 (Reset –soft)

适用场景：觉得最近这几次提交都很乱，或者逻辑强相关。不如把最近的 3 个 Commit 撤销掉，捏成一个完美的 Commit。

操作步骤

软重置：将指针回退 3 步，但保留文件修改在暂存区：

git reset --soft HEAD~3

状态变化：此时，过去 3 次提交的历史记录消失了，但所有的代码变动都还在，并且处于 Staged (暂存区/绿色) 状态。
修改与重构：直接在现在的代码基础上进行大规模修改、修复 Bug。
提交新版本：

git commit -m "refactor: 重构核心逻辑（合并了之前的多次尝试）"

⚖️ 方案对比总结

特性	方案一：Rebase -i (变基)	方案二：Reset –soft (重置)
形象比喻	精准手术 🔪	推土机 🚜
历史记录	保持原有提交数量，只修改其中一个	将多个历史提交合并为一个新提交
后续提交	保留后续 Commit 的独立性	后续 Commit 也会被合并掉
冲突风险	可能会遇到多次冲突（每个后续 Commit 都可能冲突）	无冲突（因为是一次性提交）
推荐指数	⭐⭐⭐⭐ (团队协作且需保留历史时)	⭐⭐⭐⭐⭐ (个人开发或整理烂代码时)

💡 VS Code 插件推荐

如果你不习惯命令行，推荐安装 Git Graph。

Rebase: 右键父节点 -> Rebase current branch on this commit -> 勾选 Interactive。
Reset: 右键目标节点 -> Reset current branch to this commit -> 选择 Soft。

最后提示：如果你修改的分支已经 Push 到了远程且有同事在协作，请务必与同事沟通，因为修改历史记录需要 git push -f (强制推送)，这可能会覆盖同事的代码！

如何彻底删除 Git 历史记录中的大文件

本教程旨在解决一个常见问题：当你在 git push 时，即使已经删除了某个大文件，GitHub 依然提示 GH001: Large files detected 错误，导致推送失败。

问题场景

你执行了 git rm a_large_file.pkl 并创建了一个新的 commit，但在推送时仍然看到类似下面的报错：

remote: error: File your_project/a_large_file.pkl is 107.01 MB; this exceeds GitHub's file size limit of 100.00 MB
remote: error: GH001: Large files detected.
! [remote rejected] main -> main (pre-receive hook declined)

原因是： Git 会保存每一次的提交记录。虽然你在最新的提交中删除了该文件，但它依然存在于仓库的过往历史中。推送时，GitHub 会检查所有历史记录，发现这个超大文件后便会拒绝接收。

要解决此问题，必须从 Git 的历史记录中将该文件彻底清除。

推荐方案：使用 git-filter-repo (更简单、更快速)

git-filter-repo 是 Git 官方现在推荐用来清理历史记录的工具，它比 Git 的原生命令更高效且易于使用。

1. 安装 git-filter-repo

如果尚未安装，请先执行安装。

macOS (使用 Homebrew):
```
brew install git-filter-repo
```
对于其他系统，请参考其官方安装文档。

2. 从历史记录中删除文件

在你的本地仓库根目录运行以下命令。此操作会重写历史记录。

# 将 "path/to/your/large_file.pkl" 替换为你的大文件实际路径
git filter-repo --path "path/to/your/large_file.pkl" --invert-paths

这条命令会自动处理所有分支和标签，从中移除对指定文件的所有引用。

3. 强制推送到远程仓库

由于本地历史已被重写，你需要强制推送来覆盖远程仓库的历史。

git push --force

备选方案：使用纯 Git 命令 git filter-branch

如果你不想安装任何新工具，可以使用 Git 内置的 filter-branch 命令。

警告： 此命令非常复杂且速度慢，操作前强烈建议备份你的整个项目文件夹。

1. 执行历史重写命令

# 将 "path/to/your/large_file.pkl" 替换为你的大文件实际路径
git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch "path/to/your/large_file.pkl"' \
--prune-empty --tag-name-filter cat -- --all

--ignore-unmatch: 确保在不包含该文件的历史 commit 上命令不会报错。
此命令执行速度可能很慢，请耐心等待。

2. 清理仓库并回收空间

filter-branch 会留下备份。运行以下命令以彻底清除旧数据并压缩仓库。

git reflog expire --expire=now --all
git gc --prune=now --aggressive

3. 强制推送

同样，你需要强制推送来更新远程仓库。

git push --force

未来建议：使用 Git LFS 管理大文件

为了从根源上避免此类问题，当项目中必须包含大文件时，应使用 Git Large File Storage (LFS)。

Git LFS 会将大文件存储在专门的服务器上，而在你的仓库中只保留一个轻量级的指针文件，从而使仓库保持小巧和快速。

LFS 快速上手

安装 LFS 客户端
```
# macOS
brew install git-lfs
```
在仓库中启用 LFS (每个项目只需执行一次)
```
git lfs install
```
追踪指定类型的文件 (例如，所有 .pkl 和 .onnx 文件)
```
git lfs track "*.pkl"
git lfs track "*.onnx"
```
提交 .gitattributes 文件 git lfs track 命令会创建一个 .gitattributes 文件，确保将它添加到版本控制中。
```
git add .gitattributes
git commit -m "Configure Git LFS to track large files"
```
之后，你就可以像平常一样 git add 和 git commit 大文件了，LFS 会自动处理它们。

如何优雅地处理不再使用的 GitHub 仓库

当一个项目长期不用，但又不想彻底删除时，你有以下三种方法可以将其"隐藏"起来，同时保留代码。

方案一：归档仓库 (Archive) - ⭐最推荐

这是 GitHub 官方设计的最佳方案，用于封存项目。

效果:

仓库从你的主页列表消失。
项目变为只读，无法再推送新代码。
完整保留所有代码、提交历史、Issues、PRs、Wiki 和 Star。
可以随时一键"取消归档"来恢复项目。

操作步骤:

进入仓库页面，点击 Settings (设置)。
在 General (常规) 标签页，拉到最下方的 Danger Zone (危险区域)。
点击 Archive this repository (归档这个仓库) 并确认。

方案二：设为私有仓库 (Make Private)

如果只是不想让公众看到，但自己还可能修改。

效果:

仓库从公开主页消失，只有你和协作者可见。
所有功能（推送、提交）完全正常。
注意： 仓库在你自己的仓库列表中依然可见。

操作步骤:

进入仓库 Settings -> General -> Danger Zone。
点击 Change repository visibility (更改仓库可见性)。
选择 Make private (设为私有) 并确认。

方案三：作为另一项目的分支 (不推荐)

将旧仓库的历史合并到另一个项目中，然后删除旧仓库。这是一种复杂且有损的操作。

效果:

代码和提交历史被合并到新项目的一个分支上。
警告： 将永久丢失旧仓库所有的 Issues、PRs、Wiki 等宝贵记录。
会使主项目的历史变得复杂。

操作步骤 (命令行):

# 1. 进入你的主项目目录
cd /path/to/main-project

# 2. 添加旧仓库为临时远程源
git remote add old_repo https://github.com/user/old-repo.git

# 3. 拉取旧仓库数据
git fetch old_repo

# 4. 基于旧仓库历史创建新分支 (假设其主分支为 main)
git switch -c archive/old-project old_repo/main

# 5. 推送新分支到主项目
git push -u origin archive/old-project

# 6. 删除临时远程源
git remote remove old_repo

# 7. 去 GitHub 网站上手动删除 old-repo 仓库

总结对比

方法	优点	缺点	推荐度
归档 (Archive)	保留所有记录、操作简单、可逆	项目只读	⭐⭐⭐⭐⭐
设为私有 (Private)	不公开、可继续编辑	仍在自己列表显示	⭐⭐⭐⭐
作为分支合并	物理上整合代码	丢失Issues/PRs等记录、操作复杂	⭐

结论： 对于"长期不用但想完整保留"的场景，请始终选择归档 (Archive)。

一个电脑想要同时使用两个github账号ssh登录

第一步，生成另一个账号专用的ssh密钥和公钥，然后把公钥复制到那个账号的github里面
配置客户端以使用正确账号

vim ~/.ssh/config

# zata-zhangtao 账号专用
Host github.com-zata
 HostName github.com
 User git
 IdentityFile ~/.ssh/id_ed25519_zata
 IdentitiesOnly yes

然后更新 remote URL ，使用自定义的Host

# 例如原本是： git@github.com:zata-zhangtao/ZataTree.git ，改成
git remote set-url zata git@github.com-zata:zata-zhangtao/ZataTree.git

恢复被 Git 合并覆盖的提交并防止未来覆盖

问题背景主分支（main）的修改在合并（如 zata_ssh/hugo）时被覆盖，可能是快速合并或 ort 策略自动选择远程分支内容导致。

恢复被覆盖的提交

查看历史：
```
git reflog main
```
找到合并前的提交（如 b510d7b）。

恢复提交：

git checkout main
git reset --hard b510d7b

备份分支：
```
git branch main-backup main
```
推送更改（谨慎）：如果已推送到远程，需强制推送：
```
git push --force
```
警告：提前通知团队，强制推送会影响远程历史。

重新合并（避免覆盖）

拉取远程分支：
```
git fetch zata_ssh
```

非快速合并：

git merge --no-ff zata_ssh/hugo

若有冲突，手动解决：

git add <file>
git commit

或使用变基：

git checkout zata_ssh/hugo
git rebase main
git checkout main
git merge zata_ssh/hugo

预防未来覆盖

禁用快速合并：

git config --global merge.ff false
git config --global pull.ff only

预览差异：
```
git diff main zata_ssh/hugo
```

测试合并：

git checkout -b temp-merge
git merge zata_ssh/hugo

注意事项

检查合并提交（61d17c8, 14e36c9）的文件变化：
```
git show 61d17c8
```
确认 main 跟踪分支：
```
git branch -vv
```

当前正在进行代码的开发，但是想要看历史commit的项目完整代码，而当前的工作区保证原样

# 临时保存当前工作目录中的未提交更改
git stash

# 切换到指定的 commit（替换 <commit id> 为实际的 commit 哈希值，例如 b2dfde96604dcce732aefccc4c7b4dc1fc8b161a）
git checkout <commit id>

# 返回到原始分支（替换 <branch name> 为实际的分支名，例如 main）
git checkout <branch name>

# 恢复之前保存的更改
git stash pop

在 Git 中，如果你想回退到上一个版本继续开发，同时保留已经提交到 `main` 分支的最新提交，可以通过创建新分支并回退的方式实现。

以下是一个推荐的方案和详细教程，基于 Git 的最佳实践，确保操作安全且保留所有历史记录。

方案一(推荐)：

基于当前代码创建一个新分支，在新分支上介绍功能修改情况
main分支回退到上一个版本
接着在main分支上进行开发

git branch <branchName> # 创建一个新分支
git log --oneline # 查看历史commit，方便下面的切换
git reset --hard <HEAD^ 或者 commitId>

方案二：

直接在main分支上使用revert方法进行回退

git revert HEAD

这会创建一个新的提交，撤销本次更改，恢复上一步状态，但保留所有提交历史。然后可以继续在 main 分支上开发。

假设你当前在`main`分支，暂存区有文件`file1.txt`和`file2.txt`，想保存到新分支`feature-branch`

git checkout -b feature-branch
git commit -m "Add file1 and file2 to feature branch"
git push origin feature-branch

排查 Git push失败问题

当 git push 失败并提示 Updates were rejected because the remote contains work that you do not have locally，可以按照以下步骤查看远程仓库中的更改并解决问题：

获取远程更改
运行 git fetch origin 下载远程仓库的最新状态，不影响本地工作目录。
比较本地与远程分支
- 查看提交历史：git log --oneline --graph --all
  显示本地 main 和远程 origin/main 的提交差异。
- 查看文件差异：git diff --name-only origin/main main
  列出远程和本地分支间更改的文件。
检查远程独有提交
使用 git log main..origin/main --oneline 查看远程 origin/main 中独有的提交。
查看具体提交内容：git show <commit-hash>。
合并远程更改
运行 git pull origin main 合并远程更改到本地。如有冲突，手动解决后提交。
然后推送：git push origin main。
谨慎使用强制推送
若确定覆盖远程更改，运行 git push origin main --force（注意：可能丢失他人工作，仅在确认安全时使用）。

建议：优先检查远程更改（git fetch 和 git log），根据需要合并（git pull）或强制推送。

推送当前分支到远程仓库并保持分支名

要将当前分支推送到远程仓库并保持当前分支的名字，可以按照以下步骤操作：

步骤

确认当前分支：确保你位于正确的分支。运行以下命令查看当前分支：
```
git branch
```
当前分支会有一个 * 标记，例如 * 0710display-prototype3。
推送当前分支到远程仓库：使用以下命令将当前分支推送到远程仓库（通常是 origin），并保持相同的分支名：
```
git push origin $(git branch --show-current)
```
- git branch --show-current 会返回当前分支的名称（例如 0710display-prototype3）。
- git push origin <branch-name> 将当前分支推送到远程仓库的同名分支。
设置上游分支（如果需要）：如果这是第一次推送当前分支到远程仓库，Git 可能会提示当前分支没有上游分支（no upstream branch）。你可以通过以下命令推送并同时设置上游分支：
```
git push --set-upstream origin $(git branch --show-current)
```
或者简写为：
```
git push -u origin $(git branch --show-current)
```
这会将当前分支推送到远程仓库，并将远程分支设置为当前分支的上游分支，方便后续直接使用 git push 或 git pull。

示例假设你的当前分支是 0710display-prototype3，你可以运行：

git push origin 0710display-prototype3

或者更通用地：

git push origin $(git branch --show-current)

如果需要设置上游分支：

git push --set-upstream origin 0710display-prototype3

注意事项

检查远程仓库：确保远程仓库（如 origin）已配置正确。运行 git remote -v 查看远程仓库的 URL。
工作区状态：确保你已提交所有更改（git commit），否则运行 git status 检查是否有未提交的更改。
分支名冲突：如果远程仓库已存在同名分支，推送可能会失败（例如，提示需要拉取或强制推送）。可以先运行 git fetch origin 检查远程分支状态，或者使用 git push --force（谨慎使用，仅当你确定要覆盖远程分支）。

验证推送推送完成后，运行以下命令确认远程分支已创建：

git fetch origin
git branch -r

你应该能看到 origin/0710display-prototype3 在远程分支列表中。

如果遇到任何错误（例如权限问题或冲突），请分享错误信息，我可以帮你进一步排查！

git pull 时出现 “cannot lock ref” 错误的解决方案

当执行 git pull 时出现类似以下错误：

error: cannot lock ref 'refs/remotes/zata/hugo': unable to resolve reference 'refs/remotes/zata/hugo': reference broken

这个错误通常是因为本地的 Git 引用缓存与远程仓库状态不一致导致的。

问题原因

远程分支被强制更新：远程仓库的分支可能被强制推送（git push --force），导致本地缓存的提交哈希值与远程最新的提交哈希值不匹配。
本地引用损坏或不一致：本地的 .git/refs/remotes/ 文件可能被锁定、损坏，或者由于网络中断等原因未正确更新。
Git 缓存问题：Git 的引用日志或跟踪分支信息可能出现了问题，导致无法正常同步。

解决方法以下是几种解决方法，建议按顺序尝试：

方法 1：清理并重新拉取

git fetch --prune
git pull

git fetch --prune 会更新本地对远程分支的跟踪信息，并删除远程已不存在的分支引用。

方法 2：强制更新本地引用 如果确认远程分支的最新状态是你需要的，可以强制更新本地的远程分支引用：

git fetch origin
git update-ref refs/remotes/zata/hugo origin/hugo
git pull

git update-ref 手动将本地的远程分支引用更新为远程分支的最新状态。

方法 3：删除并重置本地跟踪分支

rm .git/refs/remotes/zata/hugo
git fetch origin
git pull

手动删除本地引用文件，然后重新获取远程分支信息并拉取。

方法 4：检查锁文件 错误信息提到"cannot lock ref"，可能是因为存在锁文件导致引用无法更新：

rm .git/refs/remotes/zata/hugo.lock
git fetch
git pull

如果存在锁文件，删除它以解除锁定。

方法 5：彻底清理并重新克隆（最后手段） 如果以上方法都无效，且你不介意丢失本地未提交的更改：

cd ..
rm -rf ZataTree
git clone https://github.com/zata-zhangtao/ZataTree.git
cd ZataTree

注意：在执行此操作前，请备份所有本地未提交的更改（例如通过 git stash 或复制工作目录）。

预防措施

避免强制推送：如果多人协作，尽量避免对公共分支使用 git push --force，改用 git push --force-with-lease 以减少冲突。
定期清理：定期运行 git fetch --prune 清理无效的远程分支引用。
检查网络：确保网络连接稳定，避免 git pull 中断导致引用不一致。

Git 无法识别文件名大小写更改？一文彻底解决重命名难题

适用场景：你在 Windows 或 macOS 上将 readme.md 改为 Readme.md，但 git status 却毫无反应——别慌，这不是 Git 的 bug，而是文件系统的“锅”。本文教你如何正确处理 Git 中的大小写重命名。

你执行了如下操作：

mv readme.md Readme.md

然后运行：

git status

结果 Git 完全没反应，仿佛什么都没发生。即使你强制 git add Readme.md，Git 可能还会报错：“文件已存在”或“路径冲突”。

为什么？

Git 本身是支持文件名大小写的，但它会尊重底层操作系统的文件系统行为：

操作系统	文件系统	是否区分大小写
Linux	ext4, XFS 等	✅ 是
macOS	APFS / HFS+（默认）	❌ 否
Windows	NTFS	❌ 否

在 macOS 和 Windows 上，readme.md 和 Readme.md 被视为同一个文件。因此，当你重命名时，文件系统认为“文件没变”，Git 也就检测不到任何修改。

💡 这不是 Git 的缺陷，而是为了兼容性做出的设计选择。

✅ 正确解决方案：使用 git mv 分两步走

由于直接重命名会被文件系统“吞掉”，我们需要绕过文件系统的限制。最可靠的方法是：先改成一个临时名字，再改成目标名字。

步骤示例

假设你想把 login.js 改为 Login.js：

# 第一步：重命名为临时文件（名字不能和原名仅大小写不同）
git mv login.js temp_login.js

# 第二步：从临时文件重命名为目标文件
git mv temp_login.js Login.js

# 提交更改
git commit -m "Rename login.js to Login.js"

✅ 这样 Git 就会正确记录为一次 重命名操作，而不是“删除 + 新增”，保持历史连续性。

⚠️ 常见误区

❌ 直接在文件管理器中改名

在 Finder（macOS）或资源管理器（Windows）里右键重命名 → Git 无法感知。
结果：Git 认为原文件被删除，新文件未跟踪。

❌ 强行设置 core.ignorecase false

git config core.ignorecase false

虽然能让 Git “假装”区分大小写，但在不支持的系统上会导致状态混乱（比如误报文件丢失）。
不推荐，尤其在团队协作中可能引发更多问题。

🛠️ 高级技巧：批量重命名脚本（可选）

如果你有多个文件需要改名，可以写个小脚本：

#!/bin/bash
# rename_case.sh
old="myfile.txt"
new="MyFile.txt"

git mv "$old" "temp_$$.$old"
git mv "temp_$$.$old" "$new"
echo "Renamed $old → $new"

运行：

chmod +x rename_case.sh
./rename_case.sh

$$ 是进程 ID，确保临时文件名唯一。

🌐 跨平台协作建议

如果你的团队同时使用 Windows、macOS 和 Linux，请遵守以下规范：

避免仅靠大小写区分文件名 ❌ 不要同时存在 User.js 和 user.js
统一命名风格 ✅ 推荐全小写 + 下划线/短横线：user_profile.js 或 user-profile.js
重命名一律用 git mv 即使在 Linux 上，也养成好习惯

🔚 总结

问题	原因	解决方案
Git 不识别大小写重命名	文件系统不区分大小写（Win/macOS）	✅ 用 `git mv` 分两步重命名 ✅ 避免仅靠大小写区分文件

记住：Git 是忠实的记录者，但它的“眼睛”受限于操作系统。理解这一点，就能从容应对各种“诡异”行为。

📌 小贴士：下次遇到类似问题，先问自己——“我的文件系统真的支持这个操作吗？”

作者：你的名字标签：#Git #开发技巧 #跨平台开发 #版本控制 发布时间：2026年1月16日

如何将clone下来的项目推送到自己的新仓库并同步原始仓库更新

当你 clone 一个项目，你的本地仓库默认会有一个名为 origin 的远程连接，指向你克隆的那个仓库地址。现在你既想保留自己的修改，又想同步原始仓库的更新，并最终将所有代码推送到你自己的一个全新仓库。

下面是详细的步骤，分为两种情况：

方案一：简单直接，将推送目标"切换"到你的新仓库。
方案二：最佳实践，同时管理"原始仓库"和"你的仓库"两个远程地址。 (推荐)

前提：创建你自己的远程仓库

无论使用哪种方案，你都需要先在代码托管平台（如 GitHub、Gitee、GitLab）上创建一个空的新仓库。

非常重要： 创建仓库时，不要勾选"使用README文件初始化仓库"、“添加 .gitignore” 或 “选择许可证”，以避免产生不兼容的提交历史。

创建好之后，复制新仓库的 URL 地址（HTTPS 或 SSH 格式），比如 https://github.com/your-username/your-new-repo.git。

方案一：切换远程仓库地址 (简单直接)

这个方案直接把本地仓库的 origin 指向从原始仓库地址修改为你的新仓库地址。

第一步：提交你的本地更改

git status
git add .
git commit -m "这里写下你的提交信息，比如：添加了xx功能"

第二步：同步原始仓库的更新

git pull --rebase origin main # 如果你的分支不是 main，请替换为实际分支名

git pull --rebase 会先拉取原始仓库的新提交，再把你本地的提交"重新播放"在最前面，保持提交历史线性。
如果遇到冲突，解决后用 git add <文件名> 标记解决，然后 git rebase --continue。

第三步：更改远程仓库 origin 的 URL

git remote -v # 查看当前远程仓库地址
git remote set-url origin <你自己的新仓库URL>
git remote -v # 再次确认

第四步：推送到你自己的仓库

git push -u origin main # -u 建立本地分支与远程分支的追踪关系

方案二：添加新的远程仓库 (最佳实践)

这个方案保留了原始仓库的连接（通常命名为 upstream），同时添加你自己的仓库作为新的远程连接（通常还叫 origin）。这样做的好处是，未来你还可以随时方便地从原始仓库拉取更新。

第一步和第二步：同方案一

git add .
git commit -m "你的提交信息"
git pull --rebase origin main

第三步：重命名原始仓库并添加你自己的仓库

git remote rename origin upstream # 原始仓库重命名为 upstream
git remote add origin <你自己的新仓库URL> # 添加你自己的仓库为 origin
git remote -v # 检查远程仓库配置

此时你应该能看到：

origin 指向你的新仓库地址（可读写）。
upstream 指向你最初克隆的那个原始仓库地址（通常是只读的）。

第四步：推送到你自己的仓库

git push -u origin main

未来的工作流

推送自己的修改：git push origin main

同步原始项目的更新：

git fetch upstream
git rebase upstream/main

常见问题与注意事项

分支名不是 main？
- 如果你的分支名是 master 或其他，请将命令中的 main 替换为实际分支名。
遇到冲突怎么办？
- Git 会提示你解决冲突。解决后 git add <文件>，然后 git rebase --continue。
推送时遇到权限问题？
- 检查你是否有新仓库的写权限，或 SSH/Token 配置是否正确。
未来如何同步原始仓库的更新？
- 只需 git fetch upstream，然后 git rebase upstream/main。

Git 与 GitHub on 扎塔-Zata

gh使用教程

1. 常用命令速查

2. gh 是什么

3. 安装与初始化

安装

登录

4. 仓库操作

克隆仓库

创建仓库

查看仓库信息

Fork 与同步

5. Pull Request 工作流

创建 PR

查看 PR

切换到某个 PR

查看差异、检查、评审、合并

6. Issue 管理

创建与查看

评论、编辑、关闭

7. GitHub Actions 与 CI/CD

查看工作流和运行记录

观察运行状态

下载产物与重新运行

8. Release 管理

创建与查看 Release

上传构建产物

9. gh api：把 GitHub API 直接带进终端

基本调用

搭配 JSON 输出

10. 提效能力：别名、配置、扩展

alias

config

extension

11. 推荐的实际使用方式

12. 常见问题

gh 和 git 到底怎么分工？

为什么有些仓库命令要加 -R？

命令太多记不住怎么办？

13. 参考资料

Self-hosted Runner

实现从 Windows 开发机通过 CI/CD 部署到另一台 Windows 机器的方法

Self-hosted Runner 搭建教程

注册 Runner

Linux 安装示例

Windows 安装示例

在 Workflow 中使用

注意事项

github release

方法一：通过 GitHub 网页界面创建 Release

方法二：通过 Git 命令行和 GitHub CLI 创建 Release

总结

git-submodule-子模块

知识点总结

Git Submodule 记录的是子模块仓库中一个特定的提交

如何指定添加子模块时使用的分支或标签？

更新子模块时如何处理分支？

为什么使用 Git Submodule？

具体教程

准备工作：创建示例仓库

1. 添加子模块

2. 克隆包含子模块的仓库

3. 更新子模块

4. 在子模块中工作

5. 切换分支（包含子模块）

6. 删除子模块

总结常用命令

更高级的用法和注意事项

2-github action 使用

常用知识

基础概念

构建画爱心为可执行程序

快速入门教程

目标

步骤

进阶示例

运行测试并部署

常用配置

调试技巧

常见问题

2. `gh` 是什么

9. `gh api`：把 GitHub API 直接带进终端

`gh` 和 `git` 到底怎么分工？

为什么有些仓库命令要加 `-R`？

`on` 可填写的触发事件类型

1. `workflow_dispatch`（手动触发）

2. `push`（推送事件）

3. `pull_request`（拉取请求事件）

4. `schedule`（定时触发）

5. `release`（发布事件）

6. `issues`（问题事件）

7. `workflow_run`（工作流运行事件）

要将远程仓库的 `other` 分支设置为 `main` 分支，并删除原来的 `main` 分支，可以按照以下步骤操作：

`git 使用token登录github 并拉取项目` （如果电脑上已经登录过了，需要把账户信息清除掉。如果是用ssh密钥登录的也不行，清除token账户信息请看下面"清除电脑上已经登录的github账户信息”）

`git clone 出现以下问题：fatal: unable to access XXX: gnutls_handshake() failed: The TLS connection was non-properly terminated.`

`[git push] ssh: connect to host github.com port 22: Connection timed out fatal: Could not....`

`远程分支是v3版本，本地的v2版本，但是本地修改了文件还没有add也没有commit，应该怎么更新本地？`

在 Git 中，如果你想回退到上一个版本继续开发，同时保留已经提交到 `main` 分支的最新提交，可以通过创建新分支并回退的方式实现。

假设你当前在`main`分支，暂存区有文件`file1.txt`和`file2.txt`，想保存到新分支`feature-branch`