Git-Assistant: 基于规划的 Git 仓库更新支持

# Git-Assistant：基于规划的Git仓库更新支持
来源：https://arxiv.org/html/2607.09224

###### 摘要

版本控制系统对于协作软件开发至关重要，但像git这样的工具对许多实践者来说仍然具有挑战性。大型语言模型（LLM）的最新进展为解释开发者意图提供了有前景的能力，但由于缺乏形式化推理，它们在仓库管理任务中的有效性受到限制。本文介绍了Git-Assistant，一个结合LLM与自动规划的AI助手，以支持开发者执行非简单的git操作。该助手分析仓库上下文，将自然语言请求转化为可执行的命令序列，并利用规划技术确保正确性和安全性。我们提出了一种使用合成和随机化git环境的系统性评估方法，在多个指标上比较了仅LLM和规划增强变体的性能。实验结果表明，将形式化推理与LLM相结合提高了仓库管理的可靠性并减少了错误，突显了混合AI方法在智能开发者辅助方面的潜力。

## 1 引言

版本控制系统是现代软件开发的基础，git作为管理协作工作流、代码集成和项目历史的最广泛采用工具脱颖而出。然而，尽管git扮演着核心角色，它常被认为难以掌握。无论是新手还是经验丰富的开发者都会遇到重大挑战，尤其是在处理分支、合并和解决冲突等复杂操作时Perez De Rosso and Jackson (2013 (https://arxiv.org/html/2607.09224#bib.bib13))。对GitHub和Stack Overflow等平台上开发者活动的实证研究和分析 Yanget al. (2022 (https://arxiv.org/html/2607.09224#bib.bib17)); Millikenet al. (2021 (https://arxiv.org/html/2607.09224#bib.bib10)) 一致表明，误解和错误在日常git使用中很常见。开发者在仓库管理和拉取请求工作流中经常出错，突显了手动git操作的认知需求和易错性 Kinsmanet al. (2021 (https://arxiv.org/html/2607.09224#bib.bib8))。这些困难因git复杂的命令行界面和分布式模型而加剧，要求用户记忆命令序列并理解微妙的仓库状态 De Rosso and Jackson (2016 (https://arxiv.org/html/2607.09224#bib.bib2))。现代git客户端和IDE插件通过git图（即仓库历史的可视化表示）和简化的git命令菜单提供了一些支持，但在构建实现特定仓库状态所需的完整命令序列方面往往不足。

大型语言模型（LLM）的最新进展表明，这些模型在理解和生成自然语言方面非常高效 Minaeeet al. (2024 (https://arxiv.org/html/2607.09224#bib.bib11))。这使得LLM成为构建基于AI的助手的理想基础，能够解释开发者意图并为git操作提供上下文指导。通过弥合自然语言请求与精确git命令序列之间的差距，LLM有可能降低有效使用git的门槛并减少出错的可能性。

然而，尽管LLM擅长语言理解，但仓库管理任务的复杂性表明，可能需要额外的形式化推理技术（如自动规划）来确保生成的命令序列的正确性和安全性。对于能够分析当前仓库状态、推荐操作并帮助防止用户达到不良或不一致git状态的智能端到端助手的需求日益增长。

在这项工作中，我们介绍了Git-Assistant，一个CLI助手，它接收开发者的git相关请求并提供一系列git命令以满足这些请求。为了理解Git-Assistant能够提供的好处，我们解决了以下研究问题：（1）融入仓库上下文是否能提高LLM对自然语言git命令准备请求回答的准确性？（2）形式化推理方法（如自动规划）是否能增强生成的git命令序列的可靠性和安全性？（3）基于推理的辅助能在多大程度上帮助防止用户达到有问题或非预期的git状态？

在接下来的章节中，我们讨论相关工作，描述各种助手版本的设计，介绍用于评估它们的方法学程序，以及评估结果。

## 2 相关工作

git工作流是一套规范开发者如何使用git进行协作的结构化指导原则。流行的git工作流，如Gitflow Driessen (2010 (https://arxiv.org/html/2607.09224#bib.bib3)) 和基于主干的开发，被开发团队广泛采用，已有几项分析根据这些工作流的特性进行了比较 Ríoset al. (2022 (https://arxiv.org/html/2607.09224#bib.bib14))。尽管工作流建立了团队协定，限制了可应用命令的范围，但开发者仍需负责设计这些命令的序列。

当前的自动化工作主要增强了协作平台上的持续集成和持续部署（CI/CD）流程 Wesselet al. (2023 (https://arxiv.org/html/2607.09224#bib.bib16))，例如在提交后触发流水线。这些解决方案侧重于软件交付，而不是自动化复杂的版本控制管理任务。有些方法在Stack Overflow帖子上的训练模型以建议git命令 Jiaet al. (2023 (https://arxiv.org/html/2607.09224#bib.bib7))，或通过将自然语言中的用户查询与现有示例匹配来提出类似场景 Shenet al. (2024 (https://arxiv.org/html/2607.09224#bib.bib15))。虽然这些方法提供了相关的命令和示例，但不会生成针对开发者正在处理的特定仓库定制的自定义命令序列。

一个值得注意的先前方法 Bachmann (2021 (https://arxiv.org/html/2607.09224#bib.bib1)) 使用规划领域定义语言（PDDL）Ghallabet al. (1998 (https://arxiv.org/html/2607.09224#bib.bib4)) 对完整的git提交图进行了建模，其中动作被定义为图的突变，目标是达到指定的目标图状态。尽管这种形式化实现了仓库管理的规划，但它假设开发者意图可以被精确地捕获为目标图。然而，这与从业者通常表达的更灵活和抽象的目标不一致。此外，这项工作主要处理局部图变换，并未涉及涉及远程仓库同步的操作，如拉取或推送命令。相比之下，我们的工作侧重于仅表示支持广泛git命令所需的必要仓库信息，并将自然语言请求映射到目标，从而增强实际适用性。

## 3 背景

参见图例

意图：将我的修改文件添加到最新版本的feature_1，并推送到仓库
Git命令：
1. git fetch origin
2. git stash
3. git checkout feature_1
4. git pull origin feature_1
5. git stash pop (如果冲突，Alice介入)
6. git add -u
7. git commit -m "提交更改"
8. git push origin feature_1

图1：(上) 从本地(Alice)视角显示的git图示例。feature_2领先于origin，feature_1落后于origin，master与origin同步。(下) Alice为实现其目标应用的命令。

Git在仓库中组织项目文件及其历史，更改记录为提交。开发者在分支上工作，以隔离功能或修复，并通过远程服务器（通常称为origin）同步其工作。本地环境包括工作树（即可编辑文件的目录）和索引（或暂存区），其中保存了准备提交的更改。文件被分类为已追踪、未追踪、已修改或已删除，这些决定了某些命令参数的行为。核心操作如commit、pull、push和merge对于管理更改和与他人协作至关重要。rebase操作允许开发者移动或组合一系列提交，重写现有分支的历史。reset命令允许将仓库回滚到之前的提交，同时丢弃或保留工作树中的更改。开发者还可以将多个提交压缩成一个，有助于简化提交历史。

Git在粒度级别更新文件，逐行比较以识别差异。当来自不同源的更改重叠时，会检测到合并冲突。这些冲突可能需要手动干预，但git也支持自动解决策略，例如优先选择本地更改或已提交的版本。stash（临时存储本地更改）和tag（标记项目历史中的重要点）等功能提供了额外的管理能力。

在内部，git将仓库历史表示为有向无环图，如图1 (https://arxiv.org/html/2607.09224#S3.F1) (上)所示。本地分支和origin分支都是指向提交的指针，但本地分支存在于用户机器上，而origin分支表示远程仓库中分支的状态。当用户从远程获取时，origin分支会更新，使本地分支能够跟踪其他人所做的更改。本地分支可以从origin推送或拉取，实现个人贡献者与共享仓库之间的协作和同步。因此，本地分支可能领先于、落后于、与origin分支同步或分叉，这会影响工作流并且需要谨慎管理。

git丰富的命令和参数集及其内部检查和前置条件，可能使某些操作变得复杂，尤其是对于经验有限的用户。例如，考虑图1 (https://arxiv.org/html/2607.09224#S3.F1) (上) 描绘的场景，并假设未提交的更改修改了多个分支共享的文件。一个看似简单的请求“将我的修改文件添加到最新版本的feature_1并推送到仓库”将需要一系列八个命令，如图1 (https://arxiv.org/html/2607.09224#S3.F1) (下)所示。其他基本功能，如压缩两个提交或rebase分支，涉及重写origin中的历史，并且必须使用--force选项推送。对于缺乏经验的用户来说，这可能导致一种可怕的 feeling，即有可能破坏仓库。

## 4 架构

Git-Assistant可以抽象为三个模块的组合，每个模块都实现作为代理运行所需的功能（见图2 (https://arxiv.org/html/2607.09224#S4.F2)的表示和流程编排）。Observer执行环境的感知，Engine执行实现目标的推理以及与用户的交互。Executor负责执行计划（git命令）。

当用户请求解决git任务时，Engine首先识别用户的输入是自然语言请求还是git命令。如果是git命令，模块执行它并将信息返回给用户以实现透明交互。如果是自然语言任务，它首先获取Observer提供的上下文，Observer提取目标git仓库中的所有相关信息。这包括git图、分支状态和工作树，从而获得仓库的全面表示。然后，Engine对用户意图和可用上下文进行推理，以获得满足请求所需的命令集。此模块有两个变体：（1）使用独立的LLM，或（2）使用混合方法，即LLM与自动规划器一起作为求解器使用。

一旦获得要执行的命令，它们被传递给Executor，Executor与用户确认提议的命令。确认后，它在操作系统内执行每个命令，更改本地和远程仓库的状态。

接下来，我们深入探讨每个组件。

参见图例
图2：Git-Assistant代理的架构

### 4.1 Observer

用户请求的适当命令序列在很大程度上取决于本地仓库的当前状态。因此，Observer使用原生git命令和gitpython库提取信息，使我们能够构建当前状态的上下文。仓库的状态SS包括：

- 本地状态：当前分支以及已修改或未追踪文件的列表。
- 分支位置：每个分支在本地或远程仓库中的存在情况。
- 分支关系：本地分支与其远程对应分支的同步状态（领先、落后、同步或分叉）。
- 上次提交信息：每个分支最新提交的哈希标识符和作者。
- Git图：由git log命令提供的仓库图的文本表示。

### 4.2 基于LLM的引擎

在引擎的第一个版本中，称为基于LLM（见图3 (https://arxiv.org/html/2607.09224#S4.F3)左），请求完全由LLM处理。为了促进这一点，设计了一个指令模板提示 T1，概述了任务，指定了相关约束，并包含了少样本示例。此 T1 与来自Observer的仓库状态SS嵌套，以为LLM创建完整的上下文，从而生成基础提示 P。基础提示P与用户请求R一起输入LLM，LLM输出要执行的git命令集C。有关提示模板的详细信息，请参见附录A.1 (https://arxiv.org/html/2607.09224#A1.SS1)。

参见图例
图3：引擎模块的两种变体示意图

### 4.3 混合规划器

第二个变体是基于规划的助手（见图3 (https://arxiv.org/html/2607.09224#S4.F3)右），称为混合规划器。在这种方法中，用户的请求在LLM的帮助下被制定为自动规划任务。这种方法保证，如果存在解决方案，规划器将找到有效的操作序列。规划任务由元组 (D, I, G) 定义，其中D表示以PDDL指定的Git领域，I是初始状态，G表示期望的目标。

表1：git任务领域PDDL动作的功能分组，以及相关阶段。

该领域编码了修改仓库状态空间的动作。这些动作既对应于单个git命令，也对应于阶段转换动作，使得可以在不同阶段执行操作。表1 (https://arxiv.org/html/2607.09224#S4.T1) 列出了所有动作，按高级git功能组织。有关更多详细信息，请参见附录A.2 (https://arxiv.org/html/2607.09224#A1.SS2)。

初始状态I是仓库状态SS的PDDL翻译。本地状态、分支位置和关系以及上次提交信息在谓词逻辑中有直接的表示，这些表示是通过编程生成的。我们没有显式编码git图，而是表示可以安全压缩和/或回退的提交为...