update-from-upstream-main

从上游主分支更新

从规范的 remotion-dev/remotion 仓库更新，同时保留本地工作和已发布的分支历史。

工作流

1. 更改仓库前先检查：

   git status --short --branch
   git branch --show-current
   git remote -v
   

   如果合并或变基等操作已在进行中，请停止并报告当前状态。支持分离检出，不应因此阻止更新。

   如果工作树中有已暂存、未暂存或未跟踪的更改，请自动暂存这些更改并继续：

   git stash push --include-untracked --message "update-from-upstream-main: preserve local changes"
   git rev-parse stash@{0}
   

   记录创建的暂存项的提交 ID，以便稍后恢复同一项。不要因为存在未提交的更改而停止。除非用户明确要求，否则不要包含已忽略的文件。

2. 选择 URL 指向 remotion-dev/remotion 的规范远程仓库。如果 upstream 存在，优先使用；否则使用 origin。如果没有远程仓库指向规范仓库，请停止并在添加或更改远程仓库前询问。

3. 获取最新的 main 分支，但不要更改工作树：

   git fetch <canonical-remote> main
   

4. 更新当前检出的分支：

   • 如果当前分支是 main，则必须快进：

     git merge --ff-only <canonical-remote>/main
     

   • 如果当前分支是功能分支或处于分离检出状态，则在不打开编辑器的情况下合并 main：

     git merge --no-edit <canonical-remote>/main
     

   不要变基、重置或强制推送。合并可以保留已发布的分支历史，并且可以正常推送；如果处于分离检出状态，请报告生成的提交仍处于分离状态。

5. 如果合并出现冲突，请谨慎解决每个文件中的冲突，并同时保留功能意图和上游更改。不要在整个合并中都接受 ours 或 theirs。暂存前检查每个已解决的文件，确保没有遗留冲突标记：

   rg -n '^(<{7}|={7}|>{7})' -- <resolved-files>
   

   检查并删除所有匹配项中的冲突标记。然后只暂存已解决的文件，并通过以下命令完成合并：

   git commit --no-edit
   

6. 如果第 1 步创建了暂存项，请在上游更新完成后重新应用：

   git stash apply --index <recorded-stash-commit>
   

   在报告成功前，或在获取或合并失败后停止前，必须重新应用暂存项，前提是没有 Git 操作仍在进行。如果应用暂存项时发生冲突，请谨慎解决，且不要重新运行 git stash apply。暂存项会保留为恢复副本。确认所有暂存更改（包括未跟踪文件及其暂存状态）都已恢复后，在 git stash list --format='%gd %H' 中查找具有已记录提交 ID 的条目，并且只删除该条目。绝不要弹出或删除预先存在的暂存项。

7. 验证结果。始终运行 git diff --check 和 git diff --cached --check。如果解决了冲突，或合并后的更改可能影响行为，请运行相关的软件包测试。对于较大范围的更改，请运行：

   bun run build
   bun run stylecheck
   

8. 仅当用户要求更新已发布的分支或拉取请求时才推送。使用普通推送；如果被拒绝，则停止：

   git push <canonical-remote> HEAD
   

   绝不要强制推送。

9. 报告更新前后的提交、检出是否处于分离状态、更新是快进还是合并、本地更改是否已暂存并成功重新应用、解决的任何冲突、执行的验证，以及是否已推送分支。