Help / Gitsi / Coding assistant

Your Gitsi forge with a coding assistant

For people who write their application with Claude Code or Codex and do not type Git commands themselves. In the examples, replace company.gitsi.dev/organization/my-app with the address of your repository.

1

What you need

An assistant that works on your computer, in the folder of your project: Claude Code or Codex from OpenAI. It runs Git for you. Git must therefore be installed on the computer. You do not need to know its commands.

On the forge, you need an account and an empty repository for the project. Create it with the + menu, New Repository, without ticking Initialize Repository. Write down its address, it ends with .git.

The forge only speaks Git over HTTPS, without SSH. If the assistant offers to create an SSH key or to use an address starting with git@, tell it to use the HTTPS address.
2

Give the token to Git, not to the assistant

Create a token as explained in step 3 of the getting started guide, with repository set to Read and Write.

The assistant does not need to see this token. Git keeps it in the credential manager of the computer and gives it to the forge itself. On a Mac, this is the Keychain, with the setting credential.helper osxkeychain. On Windows, this is Git Credential Manager, offered when you install Git: keep this choice. You can ask the assistant to check this setting, without giving it the token.

Never paste the token in the conversation with the assistant. The conversation is sent to the company behind the tool, and a shared conversation shows it to everyone who opens it. Do not let the assistant write it in a project file or in the repository address either: it would end up in the history, which Git keeps forever.

If the assistant wants to put the token in an environment variable or a .env file for a script, this is fine on your computer, as long as this file is excluded from the repository by .gitignore. In a pipeline, the token goes in the repository secrets, never in the pipeline file.

Only once, in a terminal, type the command below with the address of your repository. Git asks for a username: give your username. It then asks for a password: paste the token. Git remembers it, and the assistant can push without asking you again.

git ls-remote https://company.gitsi.dev/organization/my-app.git
3

Ask the assistant to push the project

Open the assistant in the project folder and give it an instruction like this one, with the address of your repository. It makes the assistant check what will be sent before sending anything.

If the project is already on GitHub, add: "The current origin remote points to GitHub. Rename it to github and add the forge as origin."

I want to put this project on my Gitsi forge. The empty repository exists:
https://company.gitsi.dev/organization/my-app.git
Add it as the origin remote, over HTTPS. The forge does not accept SSH.
Before the first push, check that .gitignore excludes .env, secret files
and local data, then show me the list of files that will be sent.
Do not write any token or password in the project.
When I have approved the list, push the main branch.
4

Have the pipeline written

The pipeline runs the tests again on each push. You can see in the forge, without running anything yourself, if a change breaks the application. It runs on the runner included with your forge.

Tell the assistant what the runner can do. It can reach the internet but not your private networks, and it has no Docker. Without this, the assistant may write a pipeline that builds an image, and this pipeline fails.

You can read the result in the Actions tab of the repository, as explained in step 6 of the getting started guide.

Write a Gitea Actions pipeline in .gitea/workflows/tests.yaml that runs
the project tests on each push and on each pull request.
It runs with runs-on: ubuntu-latest, without Docker and without access
to a private network. No secret in clear text in the file.
5

Publish the Docker image to the registry

The forge has an image registry (steps 7 and 8 of the getting started guide). The included runner has no Docker, so the image is built on your computer, where Docker must be installed.

Create a token for this with package set to Read and Write. Log Docker in to the forge yourself, once, in a terminal: docker login company.gitsi.dev, your username, then this token as the password. Docker keeps it, like Git in step 2. Then ask:

Build the Docker image of the application on this computer. Name it
company.gitsi.dev/organization/my-app with the version number as tag,
then push it to the forge registry.
I am already logged in with docker login.
6

Protect the main branch

The main branch is the reference version, the one you deploy. Once the project is pushed, close it to direct pushes: nobody can write to it any more without a request that you review. The assistant cannot either.

In the repository, open Settings, then Branches and Add New Rule. In Protected Branch Name Pattern, type main. Choose Disable Push, then Save Rule.

We tested it: a direct push to main is then refused, even from an administrator account. If you work alone, do not require approvals: the forge does not let you approve your own request, and you could not merge anything any more.

Then tell the assistant:

From now on, never push to main. For each change, create a branch with
a clear name, push it and give me the link the forge shows to open the
pull request.
7

Review, then merge

This is where you keep control. The assistant proposes, you approve.

Open the link given by the assistant. Describe in one sentence what the change should do, then click Create Pull Request. You will find it later in the Pull Requests tab of the repository.

The Files Changed tab shows each line added or removed. You do not have to understand everything. Check that the files changed match what you asked for, and that the pipeline passed. To ask for a fix, leave a comment and copy it to the assistant.

When you are happy with it, click Create merge commit. If your pipeline deploys the application, start it only from main: merging then becomes the go-ahead for the deployment. The runner cannot reach your private networks: an internal server must fetch the new version itself.

Claude Code, Codex and ChatGPT

To push to your forge, the assistant must work on your computer, where the project and Git are. The versions that run in the browser cannot do it with Gitsi.

With Gitsi
Claude Code in a terminal, in the Code tab of the Claude app, or in VS CodeYes
Claude Code on the web (claude.ai/code)No, it clones and pushes on GitHub only
Codex on the command line, in its app or in VS CodeYes
Codex in ChatGPT, on the webNo, it works on GitHub repositories
A ChatGPT conversationNo, it has no access to the forge

A ChatGPT conversation can explain an error or write a piece of code. But you are the one who copies it into the project, then sends it.

Both assistants ask for your approval before some commands, in different ways. Codex works without network access by default: when it needs a git push, it asks for your permission. Read the command before you accept. Claude Code has several modes. In Manual mode, it asks before each command. You change mode with Shift+Tab in the terminal, or with the selector under the input box in the app.

Whatever the tool, the protection of main in step 6 holds even if you accept a command too quickly.

If the token has leaked

Pasted in a conversation, sent in a repository file or shown on screen: consider it lost. In your Settings, Applications, delete it, then create a new one and do step 2 again. Removing the file from the project is not enough, the history keeps the old version.

Need help?

Our support team can walk you through the setup. Write to us at support@aleop.eu.