docs(git-sync): 补充生成物目录(nexus translation_tasks)被 add -A 卷入的坑
This commit is contained in:
@@ -78,4 +78,5 @@ metadata:
|
||||
- **`pull.rebase=true` 的仓库**(本机 nexus 即如此):有未暂存改动时 ff-only pull 必失败报 "cannot pull with rebase",哪怕与远端无文件重叠——先用 `git diff --name-only HEAD origin/main` 确认无重叠,再 `git -c pull.rebase=false pull --ff-only`,不必惊动用户。脚本遇此会自动打印 hint
|
||||
- **push 报 `could not read Username for 'http://<host>'`**:远端是 HTTP 且本机无该 host 凭据(keychain 里存的端口对不上也照样失败)。同主机若跑了 Gitea SSH,改 `git remote set-url origin ssh://git@<host>:2222/<owner>/<repo>.git` 即可直推;改前先 `git ls-remote <ssh-url>` 验证有权限,改后 `git push` 并用 `git ls-remote origin refs/heads/main` 核对远端 hash
|
||||
- **`add -A` 会把未跟踪的大目录一并提交**(实测 node_modules 56MB / 5606 文件):`status` 里出现这类目录时先补 `.gitignore`(`node_modules/`、`.DS_Store`)再 sync,否则仓库历史被永久撑大
|
||||
- **生成物目录会被 `add -A` 一并提交**(实测 nexus 的 `sreweekly/translation_tasks/`:767 个 `task_XXXX.txt`/`meta.json` 流水线中间产物,且流水线跑完会自己删掉这批文件,导致「先提交、后全量删除」两个巨量提交):同步前先判断 status 里的新目录是成果还是中间产物,后者不要入库
|
||||
- 脚本由其他技能/agent 复用时同样适用,别只当本技能专用
|
||||
Reference in New Issue
Block a user