Git itself is extremely versatile and can be as useful as you are want it to be if you put in the time to learn it.

I love how much spare time you have to learn and maintain your infrastructure unnecessarily instead of working on the code. It’s like being a bus driver by day, and mechanic all night.

It depends a lot on the setup you have, how many people, release flow etc. Issue tracking depends on the kind of software you do and whether you want a programmer-only flow or a full support flow.

Deploy pipelines will usually depend on the infrastructure, cloud solutions usually can integrate with several and there’s also common solutions and even FOSS ones, like Terraform vs OpenTofu.

Git frontends are a very mixed bag, generally speaking their main purpose is to hide Git as much as possible and allow programmers to contribute changes upstream without knowing much beyond the nebulous “PR” concept. Basically they’re mostly useless other than enabling people to remain dumb. A good Git tutorial and a good history visualization tool (git happens to include one called gitk out of the box) will do so much more to teach people Git, and there’s really no substitute for communication – using annotations to discuss pros and cons for a PR is badly inadequate.

Forgejo should work

But you don’t have to develop anything. There are plenty of ready-made excellent tools you can just drop-in. The main fallacy is that what Github does is actually useful, or that the pieces it integrates are useful. 90% of Github is subpar for any given purpose. Consider all the possible types of software being developed and all the different release flows and support/issue flows, how could they possibly be shoehorned into a one-size-fits-all? Yet people try their damnest to do exactly that.

To do software development you need (A) issue tracking, (B) a clear release flow, and © a deploy mechanism that’s easy to use. A is a drop-in tool with lots of alternatives, B is unrestricted since Git is very flexible in this regard, and C is typically included with any cloud infrastructure, unless you’re doing on premise in which case there are also drop-in tools.

A, B, C are three distinct, orthogonal topics that can and should be handled separately. There’s no logical reason to shape any of them after the other. They have to work together, sure, but the design considerations of one must not affect the others.

Installing a .deb is what I was thinking about.

Even a signed tarball is better than curl|sh.

If you have a pre-shared trusted signature to check against (like with your distro’s repos), yes. But… that’s obviously not the case since we are talking installing software from the developer’s website.

Whatever cryptografic signature you can get from the same potentially compromised website you get the software from would be worth as much as the usual md5/sha checksums (ie. it would only check against transmission errors).

Binary packages have scripts (IIRC for .deb they are preinst/postinst to be run before/after installation and prerm/postrm before/after removal) that are run as root.

BTW the “unzip” part is also run as root, and a binary package can typically place stuff anywhere in your system (that’s their job after all)… even if you used literal zip files they could still install a script in ways that would cause the OS to execute it.