I’ve recently set up my own Gitea instance and I figured I’d share a simple guide on how to do it yourself. Hopefully this will be helpful to anyone looking to get started.
If you have any feedback please feel free to comment it bellow.
Try its fork forgejo instead.
Why?
In 2022, maintainers (…) founded the company Gitea Limited with the goal of offering hosting services using (proprietary) versions of Gitea. (…). The shift away from a community ownership model received some resistance from some contributors, which led to the formation of a software fork called Forgejo. From Wikipedia.
But check that it has all the features you need because it lags behind gitea in some aspects (like ci).
It’s also ahead of gitea in some aspects: https://forgejo.org/faq/#is-there-a-roadmap-for-forgejo
Doesn’t matter if those features are doomed to be locked behind a paywall shortly
I started running my own Gitea instance because I wanted a private place to host my Obsidian notes.
I don’t have the time to read the article now, but permit a question: what do you use Gitea for?
I’m holding my dotfiles on a SSH server, clone/push over SSH, and it’s enough to do Git. I don’t need a ticket system, or wiki or anything (I use plaintext notes).
$ cat ~/.ssh/config Host srv Hostname srv.mywhatever.com $ git clone srv:/path/to/repo $ cd repo $ git pushGreat question
I always found setting up a git server from scratch to be quite confusing and I also like the webui that gitea offers.
But recently I have also started moving some of my github projects there so having a link (with a readme and everything) that I can share with others is important.
If you have a place to host Forgejo/Gitea, you have a place to store a Git server. Set it up like this:
$ git clone --bare myrepo myrepo.bare $ scp -r myrepo.bare srv: $ cd myrepo $ git remote add origin srv:myrepo.bare # or $ git remote set-url origin srv:myrepo.bareNow
git pushetc work similar to GitHub, but you’re using your server (namedsrvin SSH config, as shown in my previous post) as the remote storage.Selfhosted Gitea is a way to get a wiki, bug tracker or whatnot - collaborate, for example, but it’s not necessary to have a Git server for your personal use.
Selfhosted Gitea is a way to get a wiki, bug tracker or whatnot - collaborate, for example, but it’s not necessary to have a Git server for your personal use.
No, but it is amazing for browsing your repos and visually seeing what you did in a past commit or a branch, while your IDE is open to your latest code. Or copying and pasting something that you need from a different repo.
For Git experts, sure they can probably do all that better inside their IDE or CLI, but for us plebs, having your own Forgejo is incredible 😍
I have mine configured to disable the wiki and issues, etc, it’s just the repo browser.
Sidenote: If you just want a nice web frontend for others to view your Git repositories, you can use cgit instead.
cool guide love stuff like this
I spent a decade as a full time Tcl developer and even I don’t use fossil.
After dealing with tcl errors trying to test sqlite, I feel I’ve never seen a more scathing criticism of fossil.
I made a honest effort, but in the end went back to Git for my personal projects. The advantages Fossil has over Git (wiki, bug tracker) are trivial to emulate with versioned plaintext files, and everything about Git’s version control system just clicks with my head. Having years of experience breaking and unbreaking things helps too.
Tho one thing Fossil taught me is to merge by default, not rebase. Rebase when there’s good justification for it, and the rest of the time, have an alias for
git log --oneline --graph --first-parent(or whatever that was). --first-parent collapses a horrible branchy-mergy history into a linear overview thereof, with details available when needed.I love love love that Fossil is a single executable.
All in all, the version control wars have ended and git has won. Mercurial is another one I sort of wanna try just to see what it’s like.
Re: rebasing, I think squashing / rebasing (in place of merging) is bad but I am also one of the few people I know who tries to make a good history with good commit messages prior to opening a pull request by using interactive rebasing. (This topic is confusing to talk about because I have to say “I don’t rebase, instead o rebase” which can be confusing.)
