Local Git, Git servers and attaching remotes

tl;dr Use git local repositories for throwaway projects when coding with AI agents. If you really want to keep them down the line you can attach them to a remote repository like GitHub or BitBucket later

I’ve started using LLMs and various AI coding tools (MCP servers, AI first IDEs, etc.) to get a handle on what they can do and how I can use them. It’s been a very rewarding process as I have learned so much about how they work, and to my surprise, new coding techniques too. The AI agents are able to bring fresh knowledge to the table and use libraries I wasn’t aware of, or use advanced features I knew about but never got around to implementing. After spending about two weeks in this deep dive I can’t see myself going back to my ‘solo coder’ mode.

So why say all this on a blog post about installing a git server?

If you spend any time using AI agents. a few things come clear early on

1. Limit the scope of their codebase to the task at hand – if you have a sprawling codebase with many different components it will get confused.
2. Commit early and often – the context will fill up at some point, or the agent will start getting confused so you’ll need to kill/reset it regularly. Every time you take a step forward you should commit the changes so you have a checkpoint to revert to
3. Limit the agent to make one specific change during its lifetime, and when its done, restart the agent. I’ve been working where I complete feature A and move on to feature B but the Agent keeps reverting to thinking about feature A, or it cannot delineate the tasks and it begins to merge them.

The result of all this? Well I found myself creating projects in bare folders to skip the overhead of going to GitHub or Bitbucket. After a week or so my system was littered with code in unversioned folders. I also had to be inventive with keeping backups of code (the working copies). At some point I realized what I needed was a version control system – something like GitHub, but without the tedium of having to log on, create a project, delete the project etc …

Git is a very powerful tool, and has features that I didn’t really know existed because I always used it in a certain way. One of the features that I wasn’t aware of was local repositories.

mkdir webui
cd webui 
git init

That generated the following output

hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: 	git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: 	git branch -m <name>
Initialized empty Git repository in /Users/john/projs/webui/.git/

On Pycharm, I can now open this repository and start committing changes

To open – I just open the folder

And thats it!

Once the project opens up you can add the main.py file to git by calling “git commit” from the UI as per normal

At this point everything runs like it would with GitHub execept for one big difference – there is no “remote” server to push to. So you can commit but not push.

In the tools window at the bottom, you can click on the “Git” window and see all the changes you have committed.

Benefits

• Running a local git project allows for the traditional project workflows but without the overhead of managing lots of small projects on a server
• Version control and commit notes are great for fast cycles of development with AI agents. You will need to revert to previous commits often.
• Restarting agents with a ‘fresh’ codebase is great – each iteration lacks the baggage of a cluttered context and confused objectives

However

• Using Git locally loses one crucial benefit: backup. The files aren’t backed up or replicated off my laptop. If I delete the directory they are gone.

I cannot stress the last point enough. This workflow can only ever be used for microprojects that you are happy to loose, in its entirety, forever.

Say you’ve been prompting for a morning and you’ve actually make some progress (!GASP!). The code is starting to look presentable and does something you actually want it to do. At this point you need to decide how to preserve the code for future you. Options include:

• Option 1: Integrate into an Existing Repository.
  • Copy the code from its current local location and integrate it into your ‘main’ project repository. 
  • An example of this was work I did on processing a data feed. The data was in a horrible format so I use an AI agent unpick the data and flatten it into a more usable format for my needs. At that point I lifted the file and put it into my ‘main’ project. The micro project had served its purpose and was no longer needed.
  • This is the simplest option, and for most cases I’d stop here
• Option 2: ‘Upgrading’ the project to having a remote
  • This happens when you think the project could actually be useful long term. What started as a simple “I wonder if I can …” has now developed into a “this is pretty cool… “
  • This is like saying the test project is being upgraded into a ‘proper’ project.
  • There are two options here
    • 2(A) running a git server locally that you can connect to
    • 2(B) using an established provider like GitHub or BitBucket

As Option 1 is straight forward, Option 2 is what I will focus on here. For 99.9% of the time option 2B is the way to go – you get a secure and reliable way to manage your code. For completeness though I’ll look at setting up a git server on my network.

If you are happy to use Bitbucket of GitHub for your projects then you don’t need to do this. This approach falls into the category of “I did it because I can, not because I should’. I decided to set up a git server so that I could see how it works – it’s a learning experience. I doubt I’ll ever use it.

The good folks over at git have a great guide in how to setup a simple git server using SSH. I’m not going to go through it here as it ‘just works’.

https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server

I put the main git directory in /var/git/ and gave ownership of it to the git user created in the guide

$sudo chown -R git:git git

To continue with the example above, I created the webui project on the server. This was very similar to setting up the local project. After connecting to the server over ssh and changing to the git user

$ cd /var/git
$ mkdir webui.git
$ cd webui.git
$ git init --bare
Initialized empty Git repository in /var/git/webui.git/

So now I have two repositories – one on the server and one on the client. At this point I need to update the client repository to point to the server

On Pycharm I went to the Git menu and selected “Manage Remotes … “

I then added the server details

git@newpiggy:/var/git/webui.git

where

• newpiggy is my home server
• /var/git/webui.git is the directory I setup for the project

When you select OK pycharm will verify the details are correct. It will then be possible to push the updates to the server

11:02:34.322: [/Users/john/projs/webui] git -c credential.helper= -c core.quotepath=false -c log.showSignature=false push --progress --porcelain origin refs/heads/master:master
Enumerating objects: 5, done.
...
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
To newpiggy:/var/git/webui.git
 	refs/heads/master:refs/heads/master	0fb2944..030a1e3
Done

Stage 2B – Keeping the Code with bitbucket

This is what you should do 99% of the time. I struggle to think of why you’d prefer to host locally unless there are specific reasons (large files, security concerns …)

When managing the Git remotes in Stage 2A, I specified a git server running on my home network. However, there is no reason to only use a home server – you can use an established git provider like GitHub or BitBucket instead

To test this out I deleted the local project, created a new one with the same name (just for consistency) and performed a local commit like before. Then I created a new repository on BitBucket called webui.

Like before I select the “Git Remotes…” menu option, but this time I put in the URL of my BitBucket repository. That was it.

As before you will now be able to push updates to the remote, but it will be on the BitBucket server. At this point there is no difference between this project and any other that you created on BitBucket first.

I learned a lot about git in the course of a morning experimenting. In fact, by the end of the morning I was embarrassed that I didn’t know this already. I should have been using local git repositories for years.

For me, the sweet spot will be using a local repository and then copying the code into my ‘main’ projects. If a little tester project becomes a ‘main’ project in its own right then I think I’ll go on using BitBucket or GitHub and attach a remote that way. I don’t want to have to worry about loosing code on a home server and having code living on multiple servers is guarenteed to lead to trouble down the line.

To create the project on a home git server or GitHub is pretty much the same effort so it seems obvious to me to continuing using BitBucket or GitHub