Back to Details

move-files

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Move Files Command

移动文件命令

Overview

概述

A two-phase approach for moving files that preserves git history and makes changes trackable in diffs.
一种分两阶段的文件移动方法，可保留Git历史记录并让变更在差异对比中可追踪。

The Problem

问题

When moving files, if you copy content and write new files, git treats them as deletions + additions rather than moves. This makes it impossible to track what actually changed versus what just moved.
当移动文件时，如果复制内容并写入新文件，Git会将其视为删除+新增操作，而非移动。这会导致无法区分哪些是真正的内容变更，哪些只是文件移动。

The Solution: Two-Phase Move

解决方案：两阶段移动法

Phase 1: Move Files with 
mv
Commands

第一阶段：使用
mv
命令移动文件

CRITICAL RULE: Use terminal 
mv
commands ONLY. Never copy content and write files.
bash
mv source/path destination/path
After moving files, STOP.
Tell the user:
"Phase 1 complete. Files have been moved using 
mv
commands. Please stage these moves in git, then let me know when ready for Phase 2."
关键规则： 仅使用终端
mv
命令。切勿复制内容并写入文件。
bash
mv source/path destination/path
移动文件后，请停止操作。
告知用户：
"第一阶段完成。已使用
mv
命令移动文件。请在Git中暂存这些移动操作，准备好后告知我以进入第二阶段。"

Phase 2: Make Content Changes (Only After User Stages)

第二阶段：进行内容修改（仅在用户暂存后）

Only proceed after user explicitly confirms moves are staged.
Now make any necessary content changes to the moved files:
  • Update path references
  • Fix import statements
  • Update documentation links
  • Adjust configuration values
  • Modify file content as needed
仅在用户明确确认已暂存移动操作后再继续。
现在对已移动的文件进行必要的内容修改：
  • 更新路径引用
  • 修复导入语句
  • 更新文档链接
  • 调整配置值
  • 根据需要修改文件内容

Why This Works

为何此方法有效

Git tracking: When you use 
mv
and stage the move, git recognizes it as a rename/move operation. This preserves file history.
Clean diffs:
  • Phase 1 diff shows: file moved from A to B (no content changes)
  • Phase 2 diff shows: only the actual content modifications
Easy review: The user can verify moves are correct before any content changes happen. This makes it clear what moved versus what actually changed.
Git追踪： 当你使用
mv
命令并暂存移动操作时，Git会将其识别为重命名/移动操作，从而保留文件历史记录。
清晰的差异对比：
  • 第一阶段的差异记录显示：文件从A移动到B（无内容变更）
  • 第二阶段的差异记录显示：仅包含真正的内容修改
易于审核： 用户可在进行任何内容修改前验证移动操作是否正确。这能清晰区分哪些是文件移动，哪些是真正的内容变更。

When to Use This

适用场景

Use this pattern whenever:
  • Moving files between directories
  • Reorganizing documentation
  • Refactoring code structure
  • Consolidating scattered files
  • Any scenario where files need to move AND have content updated
在以下场景中使用此模式：
  • 在目录间移动文件
  • 整理文档结构
  • 重构代码结构
  • 整合分散的文件
  • 任何需要移动文件并同时更新内容的场景

Example Usage

使用示例

User says: "Move all the guides from backend/docs/ to project/guides/backend/"
Your response:
  1. Use 
    mv backend/docs/guides project/guides/backend
  2. Verify the move succeeded
  3. Tell user to stage the moves
  4. WAIT for user confirmation
  5. Only then make content changes to the moved files
用户说："将所有指南从backend/docs/移动到project/guides/backend/"
你的响应：
  1. 执行
    mv backend/docs/guides project/guides/backend
  2. 验证移动操作是否成功
  3. 告知用户暂存移动操作
  4. 等待用户确认
  5. 仅在确认后对已移动的文件进行内容修改

Key Principles

核心原则

  • Use 
    mv
    commands only     - Never copy and write
  • Stop after moves - Wait for staging
  • Make content changes separately - Only after user confirms staging
  • One phase at a time - Never combine moves with content changes
  • 仅使用
    mv
    命令     - 切勿复制并写入文件
  • 移动后停止 - 等待暂存操作
  • 单独进行内容修改 - 仅在用户确认暂存后
  • 分阶段操作 - 切勿将文件移动与内容修改合并进行