How to Create and Use an AI Git Agent

In our past experiments, we started our work from the assumption that we had a project ready to work

In our past experiments, we started our work from the assumption that we had a project ready to work on. That means someone like a UI tech writer would need to understand Git operations in order to use the tools we built for them. Naturally, because we have been touching on Git so frequently, we wanted to try getting a Git agent started. Then, we want to use this Git agent to understand PR branches for a variety of user personas — without anyone needing to know the ins and outs of Git. We are exploring the idea that tools are agents. So, what would a Git agent do?  Let’s tackle our UI use case prompt.  Previously: A drawback that isn’t shown here, is that there is no authentication. So, if you haven’t fetched that branch or pulled commits already, this prompt at best will be unreliable and more than likely will fail (Figure 1): Now: This time around, you can see that we are being less explicit about the Git operations, we have the ability to export outputs to the conversation thread and, most importantly, we have authentication with a new prompt! These prompts should be easily adaptable to other Git providers, but we use GitHub at Docker. Before we can do anything with GitHub, we have to authenticate. There are several ways to do this, but for this post we’ll focus on SSH-based auth rather than using HTTPS through the CLI. Without getting too deep into the Git world, we will be authenticating with keys on our machine that are associated with our account. These keys and configurations are commonly located at on Linux/Mac. Furthermore, users commonly maintain Git config at .  The file is particularly useful because it lets us specify carriage return rules — something that can easily cause Git to fail when running in a Linux container. We will also need to modify our SSH config to remove UseKeychain. We found these changes are enough to authenticate using SSH in Alpine/Git. But we, of course, don’t want to modify any host configuration. We came up with a fairly simple flow that lets us prepare to use Git in a container without messing with any host SSH configs. All of this is baked in a prompt you can find and run . Simply replace with your system username (Figure 2). If you’re using the default behavior in our extension for VSCode, then the volume is ephemeral, so you would need to make sure your agent runs it before any Git tools. However, if you use the command in VSCode, you can keep the volume around under your own tag (Figure 3).  Tagging the thread persists everything after the prompt completes, so you would only need to run the prompt once before going on to develop your Git tools. If you opt to persist the thread, then this prompt would only need to be run once and the Git credentials will stick around (Figure 4). Now that we have our credentials ready, we need our Git tool to pick up on them. Our container definition copies the SSH credentials and files to the correct directory before running Git commands. With the new Git agent, we have enabled our assistant to fetch new information from upstream, switch branches, and pull in new code to review. If we provide our agent with credentials that are limited to read-only access, this agent could be used by someone that does not have a local git install. For more on what we’re doing at Docker, subscribe to our .