alt Hacker NewsBecause of so many GitHub problems, I'm adding GitLab.com and Codeberg.org.
Setup is simply 3 steps:
1. Sign up on each service, ideally with the same username.
2. For each repo you want to share, create the same repo name as a blank repo; do not automatically create a README.
3. Edit your local file .git/config to add push URLs, then push as usual.
Example:
[remote "origin"]
url = [email protected]:foo/bar.git
pushurl = [email protected]:foo/bar.git
pushurl = [email protected]:foo/bar.git
pushurl = [email protected]:foo/bar.git
fetch = +refs/heads/*:refs/remotes/origin/*Replies
I switched my personal projects to Codeberg recently and couldn't be happier. After spending lord knows how many hours wading through cluttered buggy interfaces in Github it's a pleasure to use a clean intuitive platform.
Years ago I was a big fan of Gitlab and always talked them up as a better Github. At this point though they've spent years trying to become just as convoluted and "enterprisey" as Github, but with much less success.
At this point why not just host your own gitea or something.
I'd also add tangled.org and radicle.dev. I've been looking into these new decentralized forges recently.
Somehow I never knew that you can have multiple push URLs for a single remote. Thank you for sharing this, I've been manually pushing to two remotes with a script for years!
And for fun, just spin up a VPS and initialize some bare repos there.
Hey, that's my workflow!
I also built a convenient CLI tool to switch identities on a per-repository basis. [1] [2] ...which makes working in enterprise environments much easier, as I can just have separate identities/keypairs for each customer.
[1] https://github.com/cookiengineer/git-identity
[2] https://cookie.engineer/projects/development/git-identity.ht...
yes let's fix the lack of capacity by 3x'ing the demand to take down all of these other volunteer services , too
Where do you keep Issues, Pull Requests, Wikis, Discussions, project boards, and everything else? (rhetorical question.)
These days, the problem with cloud-hosted Git platforms is not where to push your code. Replicating repositories across multiple providers is relatively easy, and Git has always been good at that. The harder problem is that successful teams end up accumulating a lot more than source code around their repositories, and much of that information becomes just as important as the code itself.
Bug reports, feature requests, documentation, design discussions, code reviews, project planning, CI/CD configuration, and years of historical context all tend to live inside platforms such as GitHub. While the Git repository itself is portable, all of that surrounding data is often much harder to migrate cleanly, especially if a team has built workflows and integrations around a particular provider.
That, in my view, is one of the main reasons so many companies are heavily dependent on GitHub. Moving the code elsewhere is usually straightforward; moving the entire development process, with all of its history, metadata, and institutional knowledge, is not. When GitHub goes down, the question is often less about where you can push your next commit and more about how easily you can recreate the rest of the environment that your team relies on every day.