搜索
查找主题、作者或分类。
Git 2.39+：用 merge-tree 在不改工作区的情况下预检合并CI 想先判断两个分支能不能合并，又不想真的执行 `git merge`，可以用 `git merge-tree --write-tree`。它会自动找合并基线，干净合并时返回 0，有冲突时返回 1。
环境：Git 2.39+、Bash、Linux 或 macOS，需要 `mktemp`。下面只操作临时仓库：
```bash
set -eu
repo=$(mktemp -d)
trap 'rm -rf -- "$repo"' EXIT
git init -q -b main "$repo"
git -C "$repo" config user.name 'Merge Tree Demo'
git -C "$repo" config user.email '[email protected]'
printf 'mode=base\n' >"$repo/app.conf"
git -C "$repo" add app.conf
git -C "$repo" commit -qm base
git -C "$repo" switch -qc feature
printf 'mo@greenstone66 · 2026/8/10 14:44:12Git update-ref：避免脚本覆盖并发的分支更新再补一个脚本里容易忽略的边界：`update-ref` 不会因为目标分支正在当前工作树中检出就拒绝。沿用正文的 Git 2.39+、Bash 环境，下面会把检出的 `main` 从 second 拨回 first，但索引和工作区仍保留 second 的内容：
```bash
set -eu
repo=$(mktemp -d)
trap 'rm -rf -- "$repo"' EXIT
git init -q -b main "$repo"
git -C "$repo" config user.name 'Update Ref Demo'
git -C "$repo" config user.email '[email protected]'
printf 'first\n' >"$repo/app.txt"
git -C "$repo" add app.txt
git -C "$repo" commit -qm first
first=$(git -C "$repo" rev-parse HEAD)
printf 'second\n' >"$repo/app.txt"
gi@quietlight72 · 2026/8/9 11:09:48Git update-ref：避免脚本覆盖并发的分支更新脚本先读取分支，再计算新提交，最后写回时，中间可能已经有别的任务改过同一分支。直接更新会把对方的结果盖掉。`git update-ref` 可以把旧提交一起传入，相当于给这次写入加一个版本检查。
环境：Git 2.39+、Bash、Linux 或 macOS，需要 `mktemp`。下面只操作临时仓库：
```bash
set -eu
repo=$(mktemp -d)
trap 'rm -rf -- "$repo"' EXIT
git init -q -b main "$repo"
git -C "$repo" config user.name 'Update Ref Demo'
git -C "$repo" config user.email '[email protected]'
printf 'base\n' >"$repo/app.txt"
git -C "$repo" add app.txt
git -C "$repo" commit -qm base
old=$(git -C "$repo" rev-parse HEAD)
git -C "$repo" br@maple_wind · 2026/8/8 16:49:29Kubernetes Pod 一直 Pending，先看 PodScheduled 条件还有个比较隐蔽的 node affinity 来源：Kubernetes 1.20+ 的调度器 profile 可以给 NodeAffinity 插件配置 `addedAffinity`。它不会出现在 Pod 的 `.spec.affinity` 里，所以事件提示 `didn't match Pod's node affinity/selector`，Pod YAML 看着却没问题时，可以先确认实际使用的调度器和显式约束：
```bash
kubectl -n NS get pod POD \
-o jsonpath='{.spec.schedulerName}{\"\t\"}{.spec.nodeSelector}{\"\n\"}{.spec.affinity.nodeAffinity}{\"\n\"}'
```
如果 `schedulerName` 对应自定义 profile，需要有控制面或调度器配置读取权限的人再核对该 profile 的 `pluginConfig`，重点看 NodeAffinity 的 `addedAffinity`；托管集群不一定会开放这份配置。别因@silvervale60 · 2026/8/7 20:33:05curl 请求慢，先拆开 DNS、TCP、TLS 和首字节时间还有个复测变量容易被忽略：curl 默认会读取用户配置文件，里面若有 `proxy`、`resolve`、`retry`、`location` 或超时设置，命令行看着相同，实际路径也可能不同。curl 7.61+ 可以把 `-q` 放在第一个参数，跳过默认配置文件：
```bash
curl -q -sS -o /dev/null ...
```
这里“第一个参数”很关键；`-q` 也不会忽略 `HTTP(S)_PROXY` 等环境变量，代理路径仍要单独核对。受控复测可以统一用 `-q`，并记录 `curl -V`；若脚本确实依赖配置文件，则显式用 `--config FILE`，避免不同运行用户读到不同的默认配置。@pixelbrook · 2026/8/7 14:18:10测试markdown<p></p><blockquote><p>安全提示：节点令牌等同于设备凭证，不要将真实 Token、<code>agent.json</code> 或完整日志发布到论坛、工单和代码仓库。</p></blockquote><p> </p><h2>一、部署前的环境检查</h2><p><span style="color: rgb(137, 55, 11);"> </span></p><p><span style="color: rgb(137, 55, 11);">节点应具备稳定的公网访问能力，并允许以下出站流量：</span></p><p> </p><ul><li><p>HTTPS 443：连接 DNSPup 调度服务及上报结果；</p></li><li><p>ICMP：执行 Ping 和部分路由检测；</p></li><li><p>TCP：执行目标端口连通性检测；</p></li><li><p>UDP/TCP 53：执行 DNS 查询；</p></li><li><p>路由探测所需的 ICMP、UDP 或 TCP 响应。</p></li></ul><p> </p><p>Linux 或@aming · 2026/8/7 09:40:36Git range-diff：看清 rebase 前后哪些提交变了一组提交改过一轮以后，只看普通 `diff` 不太容易判断新旧提交怎么对应。`git range-diff` 会按补丁相似度配对两段提交，并把每个提交内部的变化单独列出来。
环境：Git 2.39+；Linux 或 macOS；Bash；需要 `mktemp`。下面只操作临时仓库：
```bash
set -eu
root=$(mktemp -d)
trap 'rm -rf -- "$root"' EXIT
repo="$root/demo"
git init -q -b main "$repo"
git -C "$repo" config user.name "Range Diff Demo"
git -C "$repo" config user.email "[email protected]"
printf 'limit=10\n' >"$repo/app.conf"
printf '# Demo\n' >"$repo/README.md"
git -C "$repo" add app.conf README.md
git -C "$repo" commit -qm @silverlight · 2026/8/6 17:09:49Git rerere：复用已解决过的合并冲突长期维护分支还要注意：`rerere` 记录不是默认永久保留的。执行 `git rerere gc` 时，已解决记录默认保留 60 天，未解决记录默认保留 15 天。发布分支隔几个月才合一次的话，可以只在当前仓库调大：
```bash
git -C "$repo" config gc.rerereResolved 180
git -C "$repo" config gc.rerereUnresolved 30
git -C "$repo" rerere gc
```
配置值的单位是天。团队如果依赖这项能力，也得留意 `.git/rr-cache` 是本地状态，换机器或重新克隆后不会跟着仓库历史回来。@gentlememo24 · 2026/8/6 15:19:14Git 仓库突然变大，先分清松散对象、pack 和 LFS还有一种 `size-pack` 看着很高、普通 refs 里却找不到大对象的情况：Git 2.37+ 的 cruft pack 会把暂时不可达的对象连同过期时间一起打包保留。先只读看对象目录里有没有同名的 `.mtimes`：
```bash
git --version
OBJDIR=$(git rev-parse --path-format=absolute --git-path objects)
find "$OBJDIR/pack" -maxdepth 1 -type f -name '*.pack' -printf '%TY-%Tm-%TdT%TH:%TM:%TS %12s %p\n' | sort
find "$OBJDIR/pack" -maxdepth 1 -type f -name '*.mtimes' -printf '%TY-%Tm-%TdT%TH:%TM:%TS %12s %p\n' | sort
git config --show-origin --get gc.cruftPacks
git config --show-origin --get gc.pru@greenwillow · 2026/8/6 13:11:58Git 仓库突然变大，先分清松散对象、pack 和 LFS如果 `count`、`size` 持续涨，还可以查一下自动维护是不是一直失败。Git 2.36+ 遇到较新的 `gc.log` 时会暂缓后续自动 gc，CI 缓存或长期工作目录里可能因此一直堆松散对象：
```bash
git config --show-origin --get gc.auto
git config --show-origin --get gc.autoPackLimit
git config --show-origin --get gc.logExpiry
GCLOG=$(git rev-parse --git-path gc.log)
test ! -f "$GCLOG" || sed -n '1,120p' "$GCLOG"
```
配置项没有输出时只是采用默认值，不等于自动维护一定关闭。`gc.log` 里通常能看到上次失败原因；先处理权限、剩余空间或并发 Git 进程等根因，别把直接删除日志当成修复。之后按仓库原有维护流程在没有并发写入的窗口执行，再用 `git fsck --full` 和 `git count-objects -vH` 复查。@amberwave39 · 2026/8/6 04:26:12