Paper deep dive
Git-Assistant: Planning-Based Support for Updating Git Repositories
Alfredo GarrachĂłn Ruiz, TomĂĄs de la Rosa, Daniel Borrajo
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 94%
Last extracted: 7/13/2026, 3:29:42 AM
Summary
This paper introduces Git-Assistant, an AI-powered command-line assistant that integrates Large Language Models (LLMs) with automated planning (PDDL) to translate natural language requests into safe, correct git command sequences. The system comprises three core modules: an Observer for repository context extraction, an Engine with LLM-only and hybrid planning variants, and an Executor for command execution and conflict handling. Evaluation on synthetic and randomized environments demonstrates that planning-augmented approaches significantly improve reliability and reduce errors compared to LLM-only methods.
Entities (10)
Relation Signals (10)
Git-Assistant â uses â Large Language Models (LLMs)
confidence 97% ¡ This work introduces Git-Assistant, an AI-based assistant that combines LLMs with automated planning to support developers in executing non-trivial git operations.
Git-Assistant â uses â Automated Planning
confidence 96% ¡ This work introduces Git-Assistant, an AI-based assistant that combines LLMs with automated planning to support developers in executing non-trivial git operations.
Git-Assistant â consistsof â Observer Module
confidence 95% ¡ Git-Assistant can be abstracted as the composition of three modules... The Observer performs the sensing of the environment
Git-Assistant â consistsof â Engine Module
confidence 95% ¡ Git-Assistant can be abstracted as the composition of three modules... the Engine carries out the reasoning for achieving goals
Git-Assistant â consistsof â Executor Module
confidence 95% ¡ Git-Assistant can be abstracted as the composition of three modules... And the Executor is responsible for the execution of the plan
Engine Module â hasvariant â Hybrid-planner
confidence 94% ¡ The second variant is a planning-based assistant (see Figure 3 right), named Hybrid-planner.
Git-Assistant â improves â Reliability
confidence 94% ¡ Experimental results demonstrate that integrating formal reasoning with LLMs improves reliability and reduces errors in repository management
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Version control systems are essential for collaborative software development, yet tools like git remain challenging for many practitioners. Recent advances in Large Language Models (LLMs) offer promising capabilities for interpreting developer intent, but their effectiveness in repository management tasks is limited by the need for formal reasoning. This work introduces Git-Assistant, an AI-based assistant that combines LLMs with automated planning to support developers in executing non-trivial git operations. The assistant analyzes repository context, translates natural language requests into actionable command sequences, and incorporates planning techniques to ensure correctness and safety. We present a systematic evaluation methodology using synthetic and randomized git environments, comparing the performance of LLM-only and planning-augmented variants across multiple metrics. Experimental results demonstrate that integrating formal reasoning with LLMs improves reliability and reduces errors in repository management, highlighting the potential of hybrid AI approaches for intelligent developer assistance.
Tags
Links
- Source: https://arxiv.org/abs/2607.09224v1
- Canonical: https://arxiv.org/abs/2607.09224v1
Trouble viewing inline? Open PDF directly â
Full Text
47,236 characters extracted from source content.
Expand or collapse full text
Git-Assistant: Planning-Based Support for Updating Git Repositories Alfredo Garrach Ě on Ruiz , Tom Ě as de la Rosa , Daniel Borrajo AI Research, JPMorganChase Abstract Version control systems are essential for collabo- rative software development, yet tools like git re- main challenging for many practitioners. Recent advances in Large Language Models (LLMs) of- fer promising capabilities for interpreting devel- oper intent, but their effectiveness in repository management tasks is limited by the need for formal reasoning. This work introduces Git-Assistant, an AI-based assistant that combines LLMs with auto- mated planning to support developers in executing non-trivial git operations. The assistant analyzes repository context, translates natural language re- quests into actionable command sequences, and in- corporates planning techniques to ensure correct- ness and safety. We present a systematic evalua- tion methodology using synthetic and randomized git environments, comparing the performance of LLM-only and planning-augmented variants across multiple metrics. Experimental results demonstrate that integrating formal reasoning with LLMs im- proves reliability and reduces errors in repository management, highlighting the potential of hybrid AI approaches for intelligent developer assistance. 1 Introduction Version control systems are fundamental to modern soft- ware development, with git standing out as the most widely adopted tool for managing collaborative workflows, code in- tegration, and project history. However, despite its central role, git is often perceived as difficult to master. Both new and experienced developers encounter significant challenges, especially when dealing with complex operations such as branching, merging, and resolving conflicts [ Perez De Rosso and Jackson, 2013 ] . Empirical studies and analyses of de- veloper activity on platforms like GitHub and Stack Over- flow [ Yang et al., 2022; Milliken et al., 2021 ] consistently show that misunderstandings and mistakes are common in ev- eryday git usage. Developers frequently make errors in repos- itory management and pull request workflows, highlighting the cognitive demands and error-prone nature of manual git operations [ Kinsman et al., 2021 ] . These difficulties are further compounded by gitâs complex command-line inter- face and distributed model, which require users to memo- rize sequences of commands and understand subtle reposi- tory states [ De Rosso and Jackson, 2016 ] . Modern git clients and IDE plugins offer some support through the git graph (i.e., visual representations of repository history) and simpli- fied menus of git commands, but they often fall short when it comes to constructing the full sequence of commands needed to achieve a specific repository state. Recent advances in Large Language Models (LLMs) have demonstrated that these models are highly effective at un- derstanding and generating natural language [ Minaee et al., 2024 ] . This makes LLMs a promising foundation for build- ing AI-based assistants that can interpret developer intent and provide contextual guidance for git operations. By bridg- ing the gap between natural language requests and precise git command sequences, LLMs have the potential to lower the barrier to effective git usage and reduce the likelihood of mistakes. Nevertheless, while LLMs are good at language under- standing, the complexity of repository management tasks suggests that additional formal reasoning techniques, such as automated planning, may be needed to ensure the correct- ness and safety of generated command sequences. There is a growing need for intelligent, context-aware assistants that can analyze the current repository state, recommend opera- tions, and help prevent users from reaching undesirable or inconsistent git states. In this work, we present Git-Assistant, a CLI assistant that receives developersâ git-related requests and provides a se- quence of git commands to address those requests. To un- derstand the benefits that Git-Assistant can provide, we ad- dress the following research questions: (1) Does incorpo- rating repository context improve the accuracy of LLMs an- swers to natural language requests for git command prepara- tion? (2) Can formal reasoning methods, such as automated planning, enhance the reliability and safety of generated git command sequences? (3) To what extent does reasoning- based assistance help prevent users from reaching problem- atic or unintended git states? In the following sections, we discuss related work, de- scribe the design of various assistant versions, and present the methodological procedures used to evaluate them, along with the results of our evaluation. arXiv:2607.09224v1 [cs.SE] 10 Jul 2026 2 Related Work A git workflow is a structured set of guidelines that governs how developers collaborate using git. Popular workflows, such as Gitflow [ Driessen, 2010 ] and Trunk-based develop- ment, are widely adopted by development teams, and sev- eral analyses compare these workflows based on their fea- tures [ R Ě Äąos et al., 2022 ] . Although workflows establish a team agreement that restricts the universe of applicable commands, the developer is still responsible for devising the sequence of these commands. Current automation efforts mainly enhance continuous in- tegration and deployment (CI/CD) processes [ Wessel et al., 2023 ] on collaborative platforms, such as triggering pipelines after commits. These solutions focus on software delivery rather than automating complex version control management tasks. Some methods train models on Stack Overflow posts to suggest git commands [ Jia et al., 2023 ] or propose sim- ilar scenarios [ Shen et al., 2024 ] by matching user queries in natural language with existing examples. While these ap- proaches provide relevant commands and examples, they do not generate custom command sequences tailored to the spe- cific repository the developer is working on. A notable prior approach [ Bachmann, 2021 ] modeled the complete git commit graph using the Planning Domain Def- inition Language (PDDL) [ Ghallab et al., 1998 ] , where ac- tions are defined as graph mutations and the objective is to reach a specified target graph state. While this formulation enables planning for repository management, it assumes that developer intent can be precisely captured as a target graph. However, this does not align with the more flexible and ab- stract goals typically expressed by practitioners. Further- more, this work primarily addresses local graph transforma- tions and does not account for operations involving the syn- chronization of remote repositories, such as pull or push com- mands. In contrast, our work focuses on representing only the essential repository information required to support a broad set of git commands and mapping natural language requests to goals, thereby enhancing practical applicability. 3 Background Git organizes project files and their history within a repos- itory, where changes are recorded as commits. Developers work on branches to isolate features or fixes, and synchro- nize their work through a remote server, typically referred to as origin. The local environment consists of the working tree (i.e., the directory of editable files) and the index (or stag- ing area), which holds changes ready to be committed. Files are categorized as tracked, untracked, modified or deleted, which determine the behavior of some command parameters. Core operations such as commit, pull, push, and merge are essential for managing changes and collaborating with oth- ers. The rebase operation allows developers to move or com- bine a sequence of commits, re-writing the history of existing branches. The reset command enables rolling back the repos- itory to a previous commit, either discarding or preserving changes in the working tree. A developer can also squash multiple commits into a single one, helping to simplify the commit history. Intent: add my modified files to the latest version of fea- ture1 and push them to the repo Git commands: 1. git fetch origin 2. git stash 3. git checkout feature 1 4. git pull origin feature1 5. git stash pop(Alice intervention in case of conflicts) 6. git add -u 7. git commit -m âCommitting changesâ 8. git push origin feature 1 Figure 1: (Top) Git graph example shown from local (Alice) perspec- tive. feature 2 is ahead of origin, feature1 is behind and master is in sync. (Bottom) Commands that Alice applies to achieve her goal. Git updates files at a granular level, comparing them line by line to identify differences. When changes from different sources overlap, merge conflicts are detected. These conflicts may require manual intervention, but git also supports auto- mated resolution strategies, such as preferring local changes or already committed versions. Features like stash (temporal storage of local changes) and tag (marking a significant point in the projectâs history) offer additional management capabil- ities. Internally, git represents repository history as a directed acyclic graph, such as in Figure 1 (top). Both local and origin branches are pointers to commits, but local branches exist on the userâs machine while origin branches represent the state of branches on the remote repository. Origin branches are updated when the user fetches from the remote, allowing lo- cal branches to track changes made by others. Local branches can be pushed to or pulled from origin, enabling collaboration and synchronization between individual contributors and the shared repository. As a result, local branches may be ahead of, behind, synchronized with, or diverged from their origin branch, which impacts workflow and requires careful man- agement. Gitâs rich set of commands and parameters, along with its internal checks and preconditions, can make certain opera- tions complex, particularly for users with limited experience. Consider, for example, the scenario depicted in Figure 1 (top), and suppose that uncommitted changes have modified files that are shared across multiple branches. A seemingly sim- ple request such as âadd my modified files to the latest ver- sion of feature 1 and push them to the repositoryâ will re- quire a sequence of eight commands, as illustrated in Figure 1 (bottom). Other basic functionalities, such as squashing two commits or rebasing a branch, involve rewriting the history in origin and necessarily require pushing with the âforce op- tion. For inexperienced users, this can lead to the intimidating feeling of potentially breaking the repository. 4 Architecture Git-Assistant can be abstracted as the composition of three modules, each fulfilling a necessary function to operate as an agent (see Figure 2 for representation and flow orchestration). The Observer performs the sensing of the environment, the Engine carries out the reasoning for achieving goals as well as the interaction with the user. And the Executor is respon- sible for the execution of the plan (git commands). When a user requests to solve a git task, the Engine first identifies whether the userâs input is a request in natural lan- guage or a git command. If it is a git command, the module executes it and returns the information to the user for trans- parent interaction. If it is a task in natural language, it first gets the context provided by the Observer, which extracts all the relevant information from the target git repository. This includes the git graph, branch states and working tree thereby obtaining a comprehensive representation of the repository. Then, the Engine reasons about the user intent and the avail- able context, to obtain the set of commands necessary to sat- isfy the request. This module has two variants: (1) using a standalone LLM, or (2) using a hybrid approach, an LLM to- gether with an automated planner used as a solver. Once the commands to be executed are obtained, they are passed to the Executor, which confirms with the user the pro- posed commands. On confirmation, it executes each com- mand within the operating system, changing the state of local and remote repositories. Next, we delve into each of the components. Figure 2: Architecture of the Git-Assistant agent 4.1 Observer The decision regarding which sequence of commands is ap- propriate for a user request largely depends on the current state of the local repository. Therefore, the Observer uses native git commands and the gitpython library to extract the information that allows us to build the context of the current state. The state S for a repository includes: ⢠Local status: the current branch and the list of modified or untracked files. ⢠Branch locations: for each branch, its presence in local or remote repositories. ⢠Branch relations: the synchronization status of local branches with their remote counterparts (ahead, behind, synchronized, or diverged). ⢠Last commit info: the hash identifiers and authors of the latest commit for each branch. ⢠Git graph: the text representation of the repository graph provided by the git log command. 4.2 LLM-based Engine In the first version of the Engine, referred to as LLM-based (see Figure 3, left), the request is processed exclusively by an LLM. To facilitate this, an Instruction Template Prompt (T 1 ) has been designed, outlining the task, specifying rele- vant constraints, and including few-shot examples. This T 1 is nested with the repository state S from the Observer to create a complete context to the LLM, thus generating the base prompt (P ). The base prompt P , together with the user request R, is fed to the LLM, which outputs the set of git commands (C) to be executed. See Appendix A.1 for prompt template details. 4.3 Hybrid Planner The second variant is a planning-based assistant (see Figure 3 right), named Hybrid-planner. In this approach, the userâs re- quest is formulated as an automated planning task with the help of an LLM. This approach guarantees that, if a solution exists, the planner will identify a valid sequence of opera- tions. The planning task is defined by the tuple (D, I, G), where D denotes the Git domain specified in PDDL, I is the initial state, and G represents the desired goals. The domain encodes actions that modify the repositoryâs state space. These actions correspond both to individual git commands and to phase transition actions, which enable the execution of operations in distinct phases. Table 1 presents the list of actions, organized by high-level git functionalities. See Appendix A.2 for additional details. The initial state I is a PDDL translation of the repository state S. Local status, branch locations and relations, as well as last commit information, have a straightforward represen- tation in predicate logic, which is generated programmati- cally. Instead of explicitly encoding the git graph, we rep- resent commits that can be safely squashed and/or reverted as additional facts in the initial state. For Hybrid-planner, the LLM is responsible for in- terpreting the userâs request and producing the set of goals G.We argue that identifying goals, such as (merged master feature 1), is much simpler than deriving the steps required to achieve them. On one hand, goals are directly related to what developers typically want; on the Figure 3: Diagram of the two variants of the Engine module GroupActionsPurpose/Transition SummaryPhase(s) Phase Managementgitfetch, movetooperate, movetopushing Transition between flow phases (startâ updatingâ operatingâ pushing Branch Operationscreatebranch, checkoutbranch, checkoutremotebranch Create or switch branches, including remote branches any Down Synchronizationgitpullbehind, gitpulldivergedUpdate local branch from remoteupdating Content Stagingaddmodifiedcontent, addspecificcontent, adduntrackedcontent Add different classes of content to staging area operating Commit Operationsgitcommit, gitcommitcontentCreate commits with staged contentoperating Merge & Rebase Operationsgitmerge, gitmergelocal, gitrebaseMerge branches, re-apply commits on top of branches operating History Editingsquashcommits, gitresetcountsquash commits, reset branch historyoperating TagginggittagTag significant commitsoperating Up Synchronizationgitpush, gitpushnewbranch, gitforcepush, gitdivergedpush Push local changes to remote, create or force update remote pushing Stash Managementgitstash, gitpopstashSave changes to stash (start), restore from stash (pushing) start, pushing Table 1: Functional grouping of PDDL actions for git-tasks domain, with associated phases. other hand, the LLM does not need to reason about pre- conditions, such as being on the target branch. To imple- ment this, we developed an additional Instruction Template Prompt (T 2 ), which instructs the LLM to obtain the goals G and a new objects mapping M . The prompt includes expla- nations and examples on how to interpret requests and the corresponding PDDL representations of the goals for high- level git functionalities. The mapping M is used to identify elements that are not named at the time of creating the ini- tial state. For instance, consider the request âcreate a branch feature-ui from my current branchâ, with master as the cur- rent branch. The branch to be created does not exist in I , but ânew branchâ is a PDDL object intentionally included in it. Here, G = [(created from newbranch master)]. The map- ping (newbranchâ âfeature-uiâ), provided in the LLM out- put, is then used to fill in the branch creation parameter. The pair (I, G) is typically specified in a PDDL problem. Thus, the task (D, I, G), comprising a fixed git domain and a per-request problem, is passed to a PDDL-compatible au- tomated planner to obtain a plan containing the sequence of actions required to achieve the goals. This plan is determinis- tically translated into the corresponding sequence of git com- mands C, thereby providing the necessary commands to ful- fill the userâs request. 4.4 Executor Lastly, this module is the one in charge of executing the git commands C obtained by means of the Enginge using either its variants. This module incorporates two extra capabilities: (1) an âinteractive capabilityâ that detects whenever there is a need for the user input (like resolving conflicts), returning the control of the execution to the user to resolve those, and then continue with the rest of the execution. (2) the âauto-message commit capabilityâ that detects whenever a commit appears during the commands execution and automatically generates a proper commit message based on the differences between the last commit and the current state. 5 Material and Methods Evaluating the effectiveness of a git assistant presents several challenges. First, the diversity of git command sequences ca- pable of achieving the same set of goals and the implicit side effects complicate the establishment of standardized evalua- tion criteria. Consider, for instance, that the running exam- ple in Figure 1 would have an alternative solution: commit- ting contents to current feature 2 and then merging into fea- ture 1. This intermediate commit (side effect) depends on how the assistant interprets the userâs request. On the other hand, conflict resolution within git workflows frequently re- quires human judgment, as decisions regarding the handling of merge conflicts or rebase issues are context-dependent and often subjective. To our knowledge, the literature lacks suit- able benchmarks specifically designed for our task, further hindering objective comparison and progress in this domain. In response, we have developed a methodology to automate the continuous evaluation of such tasks, enabling systematic and reproducible assessment. This methodology comprises the following sequential steps: 1. Generation of synthetic git environments 2. Generation of evaluation requests for each environment 3. Construction of the ground truth state for each request 4. Evaluation of the assistant against the ground truth states The generation of synthetic environments follows two al- ternatives: 1.a Base Environment: This consists of a pair of hand- crafted local and remote repositories, designed to encompass all relevant features necessary for diverse testing. The envi- ronment includes: ⢠Paired branches: Branches present in both local and re- mote repositories. The main branch is synchronized, while three additional branches represent cases where local branches are behind, ahead of, or have diverged from their remote counterparts. ⢠Special branches: One branch that only exists in the re- mote repository, and another branch that only exists in the local repository. Text files are included in the commits of these branches. Additionally, untracked files and modifications to existing files are introduced in the working directory, which prevents direct checkout on three branches. Functionality test tem- plates are prepared to cover various scenarios (e.g., merg- ing âaheadâ into âbehind,â rebasing âonly-remoteâ onto âin- syncâ). Functionalities are grouped into categories such as updating/moving, committing, merging, rebasing, squashing, reverting, and tagging. These templates may also include complementary intents for pulling and pushing changes. 1.b Random Environments: These environments are gener- ated by a stochastic state machine that simulates collaborative git workflows, producing random local and remote reposito- ries. It emulates scenarios where multiple developers inter- act with both local and remote branches, often resulting in divergent or outdated histories. The system alternates be- tween two perspectives: âmineâ (the userâs local copy) and âothersâ (other developersâ copies). Over 20â30 iterations, the algorithm randomly switches perspectives and performs various git operations according to configurable probabilities (e.g., branch creation p=0.2, commit p=0.8, merge p=0.3, re- base p=0.1, pull p=0.8, push p=0.8, stash p=0.1, dirty index p=0.1). This probabilistic approach ensures the generation of diverse repository states and branch structures, reflecting typ- ical workflows where local branches may lag behind remote changes or contain uncommitted modifications. Then, we proceed to generate the requests for evaluation. For the base environment case, we use functionality templates to create 25 requests that cover a range of typical reposi- tory management tasks. Then, for each request, we gener- ate four additional versions with the assistance of a language model. Specifically, we use GPT-4o with a tailored prompt to paraphrase the userâs request while preserving its original intent. This process yields a total of 100 requests to be ad- dressed which were manually checked, facilitating the subse- quent construction of the ground truth. For the random environment case, our aim is to evaluate more complex tasks or those that combine multiple function- alities. Here, we manually generate 25 cases (e.g., retrieving updated copies of branches not present in the local reposi- tory). As in the previous group, we then produce four equiv- alent versions for each case using the language model and manually verify them, resulting in a total of 100 requests. To construct the ground truth data, we manually curate git command sequence that solve each of the requests. For every request, we apply each sequence to either the base or random environment, resulting in a reference state that serves as the ground truth. Notably, this final environment state is shared among all paraphrased versions of a given request, ensuring consistency in evaluation. For the evaluation, each request is submitted to Git- Assistant, which operates on the corresponding environment copy and transitions it to a new final state. The evaluation focuses on comparing the resulting environment states rather than the specific command sequences executed. The compar- ison encompasses: 1. verifying file hashes of local branches and remote branches 2. verifying file hashes of the working copy 3. checking the existence of tags in each branch Intermediate effects on the path to the target state are not considered. For example, committing two files in separate commits is treated as equivalent to combining them in a single commit. Additionally, the stash stack is not considered, as its resulting state (i.e., applying or popping existing stashes) may depend on general user preferences that are not typically specified in individual requests. Nevertheless, by analyzing final state elements, we can provide several levels of matching metrics, which are discussed in the next section. 6 Evaluation In this section we evaluate the effectiveness of the two as- sistant versions, compared to a direct LLM request, named LLM-Vanilla, that we set as our benchmark. The LLM- Vanilla is equal to the LLM-based Engine, but without in- cluding the repository state. Since the human intervention for conflict resolution is not practical in an automated evalua- tion, we turn off the interactive mode in all configurations. In this no-interaction mode, conflicts are resolved prefer- ring the newest commit from the history. For instance, the git merge command has the option to provide this strategy (âX[ours| theirs]). For this evaluation, we used GPT-4o [ Hurst et al., 2024 ] for all interactions with the LLM. We carried out additional experiments using the o4-mini model [ OpenAI, 2025 ] , that AssistantAccuracy Plan Time Errors Remote Local Working-tree (%)(secs)(%)(%)(%)(%) LLM-Vanilla12.03.997.037.029.017.0 LLM-based19.016.278.046.053.024.0 Hybrid-Planner81.031.33.086.085.086.0 Table 2: Experiment results summary on the base environment dataset we report on Appendix A.3. To run the planning compo- nent of Hybrid-planner, we used the Fast-Downward Plan- ner [ Helmert, 2006 ] , configured with A* search and the LM- cut heuristic, as provided in the Unified Planning Framework (UPF) Python package [ Micheli et al., 2025 ] . This config- uration generates plans that are guaranteed to be valid and optimal. We set a time limit of 60 seconds for the planner. Although some instances may require additional time to be solved, we aim to enable a meaningful comparison with an alternative pure LLM-based solution, which can be generated in a few seconds. For each configuration, we assess the following metrics: ⢠Accuracy: The percentage of cases where the executed plan reaches a final state that fully matches the ground truth. ⢠Total Time: Total time refers to the duration required to generate a git plan, depending on the technique used. It includes the sensing and reasoning capabilities. ⢠Errors: The percentage of tasks in which any error was registered, whether due to git command failure or other execution issues. ⢠State Matches: This metric evaluates the goal state sepa- rately as follows: (a) Remote: Whether remote branches and their file hashes coincide with the expected state. (b) Local: Whether local branches and file hashes match with the expected state (c) Working Tree: Whether the working tree matches the expected state. Table 2 presents the results for the Base environments. The Hybrid-planner clearly outperforms the two other configura- tions with a 81% of accuracy. Notably, it also produced the fewest number of errors (3%), all attributed to the planner not finding a plan for the given goals generated by the LLM. Re- garding the LLM-based, we observe how including the repos- itory state in the context provides some improvements, more remarkably in the increase of the local branches state match- ing, as can be seen in the difference of performance between LLM-Vanilla and LLM-based. In LLM-Vanilla, the vast ma- jority of errors (around 92%) come from failing to checkout to branches without recognizing that git will prevent to do that due to a conflicting working tree with the target branch or pulling without committing or stashing current changes. In LLM-based, the pull errors are mostly solved as the LLM has context of the current state of the working tree, but still most of the errors (around 90%) come from failing to checkout. The Hybrid-planner handle both of these effectively includ- ing (git stash) in the plan before trying to switch branches on a dirty working tree. Regarding response time, LLM-Vanilla is the fastest, as its input prompt is smaller due to not including the repository state in the context. The LLM-based engine has an average response time of 16.2 seconds.The Hybrid-planner incurs an additional overhead of approximately 15 seconds compared to the LLM-based engine, primarily due to the time required by the solver to generate the plan. Nevertheless, the total time remains under one minute, which is considered manageable. Developers will still benefit, as after confirmation, the bulk of commands are executed in an average of 10.5 seconds. We also analyzed performance across different functionalities or operation classes. Results are shown in Table 4. Considering the distribution of tasks, for classes where the hybrid-planner did not achieve perfect accuracy, there was a single failure per class. These errors were due to the LLMâs interpretation of one rephrased request, while the other three were handled correctly. We also evaluated the performance on the random environ- ment dataset. Table 3 shows the results for this experiment. In this case, the Hybrid-planner again obtained the best per- formance with a 59% of accuracy. The rate is lower as the type of tasks are more complex than in the base environment. In these results we see that the comparison of the working tree state tends to be the limiting factor in terms of overall accuracy. Analyzing the errors, we observe that the Hybrid- planner may still fail due to the inability to find a valid plan for the set of goals generated by the LLM. In contrast, the LLM-based and LLM-Vanilla approaches predominantly en- counter previously mentioned errors, such as attempting to perform a pull, checkout, or merge in a modified (dirty) work- ing tree. Both approaches also exhibit errors related to hallu- cinating command options that do not exist (e.g., using ââno- editâ during a rebase). Since the working tree metric generally yields the poorest results, it could be inferred that its final state is often obscured in the userâs request. Under this assumption, we may focus on the remote metric, as developers explicitly specify what they intend to share with others. Nevertheless, in this case, the conclusion is still similar: LLM-Vanilla and LLM-based approaches show comparable performance, while the Hybrid- planner achieves superior results that exceed both by at least 30 percentage points. 7 Discussion and Limitations Although Hybrid-planner covers the typical functionalities of git, the universe of Git commands and parameters extends far beyond, enabling the handling of much more complex sce- narios. Among the functionalities we have excluded, it is im- portant to highlight the following: AssistantAccuracy Plan Time Errors Remote Local Working-tree (%)(secs)(%)(%)(%)(%) LLM-Vanilla12.05.589.057.048.021.0 LLM-based16.020.276.053.041.025.0 Hybrid-planner59.038.410.081.074.060.0 Table 3: Experiment results summary on the random environment dataset AssistantNumVanillaLLMHybrid operationbasedplanner branch creation128.333.3100.0 commit16050.0100.0 merge160.00.0100.0 rebase2010.015.095.0 reset80.037.587.5 squash80.00.0100.0 tagging120.033.391.7 update and move80.00.0100.0 Table 4: Accuracy per git operation class obtained in the base envi- ronment dataset ⢠Cloning and Configuration: We assume the repository already exists, as these operations are infrequent and provide limited value to the assistant. ⢠File Restoration: The git restore command, which al- lows recovery of a fileâs version from a previous commit, is typically performed individually per file and is often accessible with a single click in IDE plugins. It does not require to be handled as part of a multi-command plan. ⢠Difference Analysis: The git diff command does not al- ter the repository state, and its potential is best exploited through visual comparison in the IDE. Furthermore, we have not addressed the management of deleted files across branches, unlike our treatment of modi- fied and untracked files. This functionality is reserved for fu- ture work. Another relevant point is that the assistant assumes atomic operations; however, developers sometimes seek as- sistance to recover from unstable states, such as continuing an interrupted or corrupted merge. Representing such scenar- ios as initial states requires more detailed analysis. The advantage of the Hybrid-planner lies in its reliability, as none of its failures comes from incorrect git command exe- cution. This allows developers to trust that the proposed com- mands are safe to apply and that the resulting states will be stable throughout the process. Finally, the reported times correspond to the git environ- ments used in the evaluation. Larger repositories imply that the Observer will require more time, as most information is extracted using native git commands whose performance scales with repository size. We expect the planning time to be less affected, since most of the relevant data comes from the latest commit and branches, while typical projects tend to grow more rapidly in terms of files and commits. 8 Conclusion This work introduces Git-Assistant, a hybrid AI tool that in- tegrates LLMs with automated planning to support develop- ers in executing complex git operations. Through systematic evaluation in both synthetic and randomized environments, our results demonstrate that combining formal reasoning with LLMs significantly improves reliability and reduces errors in repository management tasks. The hybrid planning approach, in particular, offers robust handling of non-trivial scenarios and enhances user trust by ensuring safe and correct com- mand sequences. While some advanced git functionalities remain outside the current scope, our findings highlight the potential of hybrid AI assistants to lower the barrier to effec- tive version control. Disclaimer This paper was prepared for informational purposes by the Artificial Intelligence Research group of JPMorgan Chase & Co. and its affiliates (âJP Morganâ) and is not a product of the Research Department of JP Morgan. JP Morgan makes no representation and warranty whatsoever and disclaims all liability, for the completeness, accuracy or reliability of the information contained herein. This document is not intended as investment research or investment advice, or a recommen- dation, offer or solicitation for the purchase or sale of any security, financial instrument, financial product or service, or to be used in any way for evaluating the merits of participat- ing in any transaction, and shall not constitute a solicitation under any jurisdiction or to any person, if such solicitation under such jurisdiction or to such person would be unlawful. Š 2026 JPMorgan Chase & Co. All rights reserved References [ Bachmann, 2021 ] Tim Bachmann. Modelling git operations as planning problems, 2021. (Bachelor Thesis) Faculty of Science of the University of Basel. [ De Rosso and Jackson, 2016 ] Santiago Perez De Rosso and Daniel Jackson. Purposes, concepts, misfits, and a re- design of git. ACM SIGPLAN Notices, 51(10):292â310, 2016. [ Driessen, 2010 ] Vincent Driessen. A successful git branch- ing model, 2010. [ Ghallab et al., 1998 ] M. Ghallab, A. Howe, C. Knoblock, D. McDermott, A. Ram, M. Veloso, D. Weld, and D. Wilkins. PDDL - the planning domain definition lan- guage. Technical Report CVC TR-98-003/DCS TR-1165, Yale Center for Computational Vision and Control, 1998. [ Helmert, 2006 ] Malte Helmert. The fast downward plan- ning system. Journal of Artificial Intelligence Research, 26:191â246, 2006. [ Hurst et al., 2024 ] Aaron Hurst, Adam Lerer, Adam P Goucher, Adam Perelman, Aditya Ramesh, Aidan Clark, AJ Ostrow, Akila Welihinda, Alan Hayes, Alec Rad- ford, et al.Gpt-4o system card.arXiv preprint arXiv:2410.21276, 2024. [ Jia et al., 2023 ] Haitao Jia, Wenhua Yang, Chaochao Shen, Minxue Pan, and Yu Zhou. Git command recommenda- tions using crowd-sourced knowledge. Information and Software Technology, 159:107199, 2023. [ Kinsman et al., 2021 ] Timothy Kinsman, Mairieli Wessel, Marco A Gerosa, and Christoph Treude. How do soft- ware developers use github actions to automate their work- flows? In 2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR), pages 420â431. IEEE, 2021. [ Micheli et al., 2025 ] Andrea Micheli, Arthur Bit-Monnot, Gabriele R Ě oger, Enrico Scala, Alessandro Valentini, Luca Framba, Alberto Rovetta, Alessandro Trapasso, Luigi Bonassi, Alfonso Emilio Gerevini, Luca Iocchi, Felix In- grand, Uwe K Ě ockemann, Fabio Patrizi, Alessandro Saetti, Ivan Serina, and Sebastian Stock. Unified planning: Mod- eling, manipulating and solving ai planning problems in python. SoftwareX, 29:102012, 2025. [ Milliken et al., 2021 ] Genevieve Milliken, Sarah Nguyen, and Vicky Steeves. A behavioral approach to understand- ing the git experience. In Proceedings of the 54th Hawaii International Conference on System Sciences, 2021. [ Minaee et al., 2024 ] Shervin Minaee, Tomas Mikolov, Nar- jes Nikzad, Meysam Chenaghlu, Richard Socher, Xavier Amatriain, and Jianfeng Gao. Large language models: A survey. arXiv preprint arXiv:2402.06196, 2024. [ OpenAI, 2025 ] OpenAI. Introducing o3 and o4-mini, 2025. [ Perez De Rosso and Jackson, 2013 ] SantiagoPerez De Rosso and Daniel Jackson.Whatâs wrong with git? a conceptual design analysis. In Proceedings of the 2013 ACM international symposium on New ideas, new paradigms, and reflections on programming & software, pages 37â52, 2013. [ R Ě Äąos et al., 2022 ] Julio C Ě esar Cort Ě es R Ě Äąos, Suzanne M Em- bury, and Sukru Eraslan. A unifying framework for the systematic analysis of git workflows. Information and Software Technology, 145:106811, 2022. [ Shen et al., 2024 ] Chaochao Shen, Wenhua Yang, Haitao Jia, Minxue Pan, and Yu Zhou. Richen: Automated en- richment of git documentation with usage examples and scenarios. Journal of Software: Evolution and Process, 36(8):e2662, 2024. [ Wessel et al., 2023 ] Mairieli Wessel, Tom Mens, Alexan- dre Decan, and Pooya Rostami Mazrae. The github de- velopment workflow automation ecosystems.In Soft- ware Ecosystems: Tooling and Analytics, pages 183â214. Springer, 2023. [ Yang et al., 2022 ] Wenhua Yang, Chong Zhang, Minxue Pan, Chang Xu, Yu Zhou, and Zhiqiu Huang. Do devel- opers really know how to use git commands? a large-scale study using stack overflow. ACM Transactions on Soft- ware Engineering and Methodology (TOSEM), 31(3):1â 29, 2022. A Appendix A.1 Prompts LLM-based Engine Template Prompt (T 1 ) You are an expert git assistant. The user has requested: **USER INPUT ** Your task is to generate a sequence of git commands to ful- fill the userâs objective. INSTRUCTIONS: 1. Analyze the current repository state 2. Plan the necessary command sequence 3. Show the sequence in python format (a list of commands) 4. Briefly explain the purpose of each command NOTES: - Do not include comments in the python code, just the com- mands to be executed - local files as groups by untracked, modified, staged, etc. for adding/commiting - only add modified files unless the request specifies to add âallâ or âuntrackedâ files - when pushing or pulling, assume the remote is named âori- ginâ - Everytime the request refers to branches that are not the one you are currently in, syncronize with remote (git fetch + merge or pull) those banches unless otherwise stated. This mean those branches are from other developer (in remote) and are required to be sync with latests changes prior of us- ing them. For the one you are currently in, it depends on the action to be done. For example, if specified âcurrentâ or âlocalâ, you should not syncronize. Only syncronize the re- quired branches. The ones that are not used or not required, keep it state as it is. - Before doing a push or similar, think always if a prior pull or similar is required to avoid errors. - All commands are going to be executed from the repo root path. ** REPOSITORY CONTEXT ** ** LAST COMMITS INFO ** ** GIT GRAPH INFO ** ** INTERACTIVE INSTRUCTIONS ** ** FEW SHOT EXAMPLES ** Return only the code block with the list of commands and the explanation. Hybrid-Planner Instruction Template Prompt (T 2 ) You are a git assistant. But instead of you providing a se- quence of git commands, I will use an external PDDL plan- ner to create the plan that contains the actions to execute. Your task is to understand the user request and match the intent to the PDDL goals that will achieve them. **PPDL PREDICATE DEF REFERENCE ** TASK: Your task is to produce a python snippet containing a dictionary containing: goal: a list of strings with single pddl atoms representing the needed goals mapping: another dictionary to match pddl objects to real items, such as branch names, specific files, tag names, etc. To help reasoning about the goals you need to write first your interpretation of the user intent. NOTES: - The interpretation is a list of each recognizable sub-goals - The goals must be achievable using only git commands - The mapping is only needed when the request refers to tag names, new branches, or specific file names - When including goals remember to follow the order of types in the PDDL predicate. For example, in (sync ?lb - local branch ?rb - remote), the relevant localbranch comes first and then the corresponding remote branch. - If you explicitly recognize that the request cannot be done or it is a bad practice, respond with an empty goal list and an empty mapping. However, itâs preferred to handle this with the planner, so the problem would be unsolvable as a proof. - If there are ambiguities in the request regarding local or origin branches, prefer the that branches are in sync and updated. - for operations with local branch X, when it is behind or has diverged, include updated goals (update X) unless in- structed not to do it. However, a request for fetching from origin does not mean to update all branches, only the ones required for the task. - When branches are sync or ahead with origin, they have the latest changes, so no need to include updated goals for them. - if the working copy has modified files and changes are not mentioned to be committed or merged, include a goal to keep the working copy (modified) state to prevent forgetting intermediate stashes. Do not include working copy goal if something is committed in the task. Do not include this goal is the working copy is clean. **FUNCTIONALITY INSTRUCTIONS** **FORMAT INSTRUCTIONS ** Suppose for the example these facts are in the initial state **INITIAL STATE EXAMPLE** Now I provide examples of user request in the form INPUT: user request OUTPUT: interpretation + python snippet ** FEW SHOT EXAMPLES** Now from this point this is REAL DATA. The PDDL rep- resentation of the git repo as a PDDL partial problem is ** INIT STATE IN PDDL** THE USER REQUEST IS: **REQUEST** REMEMBER TO ONLY OUTPUT THE INTERPRETA- TION AND PYTHON SNIPPET AS IN THE EXAMPLES Additionally, the following snippet show an example in- cluded in the **FEW EXAMPLE** placeholder above. INPUT: âAdd âfileA.txtâ and âfileB.txtâ, commit and push to originâ OUTPUT: Interpretation: - commit files (fileA.txt, fileB.txt) as a specific content - last commit on current branch feat1 is pushed to ori- gin/feat1 ââpython âgoalâ: [ â(commited content cnew0 feat1 specific)â, â(lastcommit origin/feat1 cnew0)â ], âmappingâ: âspecificâ: [âfileA.txtâ, âfileB.txtâ] ââ A.2 Git Domain The PDDL Git Domain represents the repository mechanics required to track git operations in local and remote environ- ments. Each action listed in Table 1 includes: (1) a list of parameters (objects involved in the operation), (2) precondi- tions (facts that must be true in the state for the action to be applicable), and (3) effects (the changes in the state after the action is applied). Below is an example of a complete PDDL action. (:action createbranch :parameters (?newb - localbranch ?b - localbranch ?c - commit) :precondition (and (current branch ?b) (lastcommit ?b ?c) (not (inrepo ?newb)) (unusedbranch ?newb)) :effect (and (in repo ?newb) (last commit ?newb ?c) (created from ?newb ?b) (currentbranch ?newb) (not (currentbranch ?b))) ) A.3 Reasoning model experimentation We have also carried out the experiments on bot base and ran- dom environment using a so called âreasoningâ LLM, in this scenario the model âo4-miniâ from OpenAI [ OpenAI, 2025 ] which is comparable to the GPT-4o used in terms or released date a capabilities. Taking a look at the results in Tables 5 and 6, we can observe how in this scenario the LLM-Vanilla and LLM-based results tend to have a better accuracy com- pared to the results using GPT-4o. In contrast, the accuracy of for the Hybrid-Planner gets a significant decrease in ac- curacy but still it beats the other two assistants. Overall, the plan time suffers an increase in all scenarios due to the nature of the reason models that need more time to do so. Moreover, the distribution of types of errors is very similar to the error analysis done with GPT-4o Trying to extract some insights, we can hypothesize that these results are related to the nature of the task to be carried out and the nature of the models. The o4-mini is a âreason- ingâ model that tends to do better in tasks that require some thinking and steps, like maths, code, planning and so on. On the other hand, the GPT-4o is a base model that tends to do better in general tasks like semantic understanding, knowl- edge, chat and so on. In our experimentation, the task to be carried out in the assistants LLM-Vanilla and LLM-based is related to the rea- soning and planning field where the LLM has to develop a sequential plan formed by git commands to satisfy the user request. Here we observe that the âreasoningâ model o4-mini tends to obtain better results. On the other hand, the task to be carried out in the assistant Hybrid-planner is related to seman- tic understanding, where the LLM has to understand the user intention and represent it as goals. Here, we observe that the base model GPT-4o excels, surpassing by a significant margin its counterpart using o4-mini. Many of the mismatches arise from failing to match the working tree with the ground truth. In these cases, no execution errors are generated, but the o4- mini takes liberties in interpreting how to leave the working tree, especially regarding the handling of stashes. AssistantAccuracy Plan Time Errors Remote Local Working-tree (%)(secs)(%)(%)(%)(%) LLM-Vanilla19.012.991.050.048.020.0 LLM-based24.031.965.062.058.026.0 Hybrid-Planner34.044.51.076.071.046.0 Table 5: Experiment results summary on the base environment dataset using o4-mini AssistantAccuracy Plan Time Errors Remote Local Working-tree (%)(secs)(%)(%)(%)(%) LLM-Vanilla9.016.188.059.041.021.0 LLM-based26.032.850.068.049.035.0 Hybrid-planner42.048.217.079.071.044.0 Table 6: Experiment results summary on the random environment dataset using o4-mini