Photo by Ray Hennessy on Unsplash

Migrate your Git repositories to Gitea

Exodus

Article from ADMIN 84/2024

By Thomas Reuß

Nothing is forever, not even a Git server. After the purchase of GitHub by Microsoft, I found a new home in Gitea for version control.

Anyone who uses Git will quickly see the true value of version management. I have set up my own Git server with all kinds of features on a Raspberry Pi with the Gogs self-hosted Git service software, but as of now, the Gogs repository has had very little activity, with releases only appearing every six months and offering very little in terms of new features. This situation led me to believe that the software will probably not survive much longer.

Unfortunately, I didn't realize the unhealthy state of Gogs until I was already dealing with versions that have no easy migration path to Gitea, a fork of Gogs and the new home I chose for my code. The two projects have drifted apart since the fork. In this article, I show how to migrate your repositories to Gitea.

Git Origin

Unlike veterans such as CVS or Subversion, Git is not a client-server application, but a distributed system, which means that no node is favored or disadvantaged compared with others. Git allows each repository to act as a server, making migration easier. You just have to make sure that the working copies contain all the branches and tags of the origin.

In the Git world, the origin is a local alias of a specific remote repository. It removes the need for you to enter the full URL for every fetch, pull, or push operation. In fact, you could even rename the origin alias to, say, source by typing:

git remote rename origin source

What is far more serious than these names in the context of a server migration is that all data from the previous origin is only available locally. If the previous server is deleted, development branches could be lost.