Git Pull 工作流程与冲突解决指南 | 高效代码合并最佳实践

pull by odysseus0/symphony

161 周安装量

56 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/odysseus0/symphony --skill pull

开发开发运维版本控制

🇨🇳中文介绍

拉取

工作流程

在合并前，确认 git 状态是干净的，或者提交/储藏更改。
确保本地已启用 rerere：
- git config rerere.enabled true
- git config rerere.autoupdate true
确认远程仓库和分支：
- 确保 origin 远程仓库存在。
- 确保当前分支是接收合并的目标分支。
获取最新的引用：
- git fetch origin
首先同步远程功能分支：
- git pull --ff-only origin $(git branch --show-current)
- 这将在合并 origin/main 之前，拉取在远程进行的分支更新（例如，GitHub 的自动提交）。

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

冲突解决指南（最佳实践）

在编辑前检查上下文：
- 使用 git status 列出冲突文件。
- 使用 git diff 或 git diff --merge 查看冲突区块。
- 使用 git diff :1:path/to/file :2:path/to/file 和 git diff :1:path/to/file :3:path/to/file 来比较基础版本与我们的/他们的版本，以从意图层面查看文件。
- 使用 merge.conflictstyle=zdiff3 时，冲突标记包括：
  - <<<<<<< 我们的版本，||||||| 基础版本，======= 分隔线，>>>>>>> 他们的版本。
  - 冲突区域开头/结尾附近匹配的行会被修剪掉，因此请专注于不同的核心部分。
- 总结双方更改的意图，决定语义上正确的结果，然后进行编辑：
  - 说明每一方试图实现什么（错误修复、重构、重命名、行为变更）。
  - 识别共同目标（如果有的话），以及一方是否取代了另一方。
  - 首先决定最终行为；然后才编写符合该决定的代码。
  - 除非冲突明确表明是有意的更改，否则优先保留不变量、API 契约和用户可见的行为。
- 在选择解决方案之前，打开文件并理解双方的意图。
优先进行最小化、保留意图的编辑：
- 保持行为与分支目的一致。
- 避免意外删除或静默的行为更改。
一次解决一个文件，并在每完成一批逻辑操作后重新运行测试。
仅当您确定某一方应该完全胜出时，才使用 ours/theirs。
对于复杂的冲突，搜索相关文件或定义以与代码库的其余部分保持一致。
对于生成的文件，首先解决非生成的冲突，然后重新生成：
- 在接触生成产物之前，优先解决源文件和手写逻辑。
- 运行生成该文件的 CLI/工具命令以干净地重新创建它，然后暂存重新生成的输出。
对于意图不明确的导入冲突，首先接受双方：
- 暂时保留所有候选导入，完成合并，然后运行 lint/类型检查以安全地删除未使用或不正确的导入。
解决冲突后，确保没有冲突标记残留：
- git diff --check
如果不确定，请注明假设并在最终确定合并前请求确认。

何时询问用户（尽量减少）

除非没有安全、可逆的替代方案，否则不要请求输入。优先做出最佳努力的决定，记录理由，然后继续。

仅在以下情况下询问用户：

正确的解决方案取决于无法从代码、测试或附近文档推断出的产品意图或行为。
冲突涉及用户可见的契约、API 表面或迁移，选择错误可能会破坏外部消费者。
冲突需要在两个技术上等效且没有明确本地信号的设计之间做出选择。
合并引入了数据丢失、模式变更或不可逆的副作用，而没有明显安全的默认选项。
分支不是预期的目标，或者远程/分支名称不存在且无法在本地确定。

否则，继续合并，在注释中简要解释决定，并留下清晰、可审查的提交历史。

🇺🇸English

Pull

Workflow

Verify git status is clean or commit/stash changes before merging.
Ensure rerere is enabled locally:
- git config rerere.enabled true
- git config rerere.autoupdate true
Confirm remotes and branches:
- Ensure the origin remote exists.
- Ensure the current branch is the one to receive the merge.
Fetch latest refs:
- git fetch origin
Sync the remote feature branch first:
- git pull --ff-only origin $(git branch --show-current)
- This pulls branch updates made remotely (for example, a GitHub auto-commit) before merging origin/main.
Merge in order:
- Prefer git -c merge.conflictstyle=zdiff3 merge origin/main for clearer conflict context.
If conflicts appear, resolve them (see conflict guidance below), then:
- git add <files>
- git commit (or git merge --continue if the merge is paused)
Verify with project checks (follow repo policy in AGENTS.md).
Summarize the merge:
- Call out the most challenging conflicts/files and how they were resolved.
- Note any assumptions or follow-ups.

Conflict Resolution Guidance (Best Practices)

Inspect context before editing:
- Use git status to list conflicted files.
- Use git diff or git diff --merge to see conflict hunks.
- Use git diff :1:path/to/file :2:path/to/file and git diff :1:path/to/file :3:path/to/file to compare base vs ours/theirs for a file-level view of intent.
- With merge.conflictstyle=zdiff3, conflict markers include:
  - <<<<<<< ours, ||||||| base, ======= split, theirs.

When To Ask The User (Keep To A Minimum)

Do not ask for input unless there is no safe, reversible alternative. Prefer making a best-effort decision, documenting the rationale, and proceeding.

Ask the user only when:

The correct resolution depends on product intent or behavior not inferable from code, tests, or nearby documentation.
The conflict crosses a user-visible contract, API surface, or migration where choosing incorrectly could break external consumers.
A conflict requires selecting between two mutually exclusive designs with equivalent technical merit and no clear local signal.
The merge introduces data loss, schema changes, or irreversible side effects without an obvious safe default.
The branch is not the intended target, or the remote/branch names do not exist and cannot be determined locally.

Otherwise, proceed with the merge, explain the decision briefly in notes, and leave a clear, reviewable commit history.

Weekly Installs

130

Repository

odysseus0/symphony

GitHub Stars

First Seen

14 days ago

Security Audits

Gen Agent Trust HubPass SocketPass SnykWarn

Installed on

codex129

claude-code10

opencode9

github-copilot9

amp9

cline9

Azure Data Explorer (Kusto) 查询技能：KQL数据分析、日志遥测与时间序列处理

133,300 周安装

Matching lines near the start/end are trimmed out of the conflict region, so focus on the differing core.

Summarize the intent of both changes, decide the semantically correct outcome, then edit:

State what each side is trying to achieve (bug fix, refactor, rename, behavior change).
Identify the shared goal, if any, and whether one side supersedes the other.
Decide the final behavior first; only then craft the code to match that decision.
Prefer preserving invariants, API contracts, and user-visible behavior unless the conflict clearly indicates a deliberate change.

Open files and understand intent on both sides before choosing a resolution.

Prefer minimal, intention-preserving edits:

Keep behavior consistent with the branch’s purpose.
Avoid accidental deletions or silent behavior changes.

Resolve one file at a time and rerun tests after each logical batch.

Use ours/theirs only when you are certain one side should win entirely.

For complex conflicts, search for related files or definitions to align with the rest of the codebase.

For generated files, resolve non-generated conflicts first, then regenerate:

Prefer resolving source files and handwritten logic before touching generated artifacts.
Run the CLI/tooling command that produced the generated file to recreate it cleanly, then stage the regenerated output.

For import conflicts where intent is unclear, accept both sides first:

Keep all candidate imports temporarily, finish the merge, then run lint/type checks to remove unused or incorrect imports safely.

After resolving, ensure no conflict markers remain:

git diff --check

When unsure, note assumptions and ask for confirmation before finalizing the merge.