alt Hacker NewsWhere 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.
Replies
This isn't a direct answer, because I agree it is difficult to move away from Github's familiarities amongst developers - so it doesn't necessarily solve the problem for a collaborative codebase involving a handful or more developers (complete with Issues, PRs, etc) but if you are working with a less technical/developer oriented team ie- regardless of org size it's just you or maybe one other teammate who are the only ones involved directly in code/PRs then you can fairly trivially roll your own issue tracker or wiki.
Particularly if your work and the employer/client/org is primarily based on a web project (extra points, you already are managing their auth) then you could simply add a new subdomain or route to your existing web project that serves said self-hosted issue tracker or wiki.
Of course these things can get into the weeds but I do think that given the dramatically reduced turnaround times for a competent dev to spin up and customize in-house/self-hosted solutions for basic things like issues and wikis the strategy is more relevant and prudent than ever.
> Where do you keep Issues, Pull Requests, Wikis, Discussions, project boards, and everything else? (rhetorical question.)
I think it's worthy of a non-rhetorical answer anyways: https://docs.gitlab.com/user/project/import/github/#imported...
None of those might be perfect, but at least people are trying. Even something like Gitea and other forges that you can host yourself have support for most of the basic functionality you'd expect.
However, If we ever wanted a setup where it's easy to mirror rather than import stuff, we'd probably want to look in the direction of storing everything in folders within the repo, e.g. a file/folder for every issue, for every Wiki page etc. Most of the mirroring seems to only concern the repo itself, not the stuff around it, for example: https://docs.gitlab.com/user/project/repository/mirror/
This is the real issue. We’re currently migrating from GitLab+Jira to GitHub. I did most of the migration, including our CI/CD with a self-hosted runner, and it was… fine.
The straw that broke the camel’s back was that Claude managed cloud agents are awkward to use with anything other than GitHub. In general, we realized that the whole world was on GitHub and we were swimming upstream.
But the original mistake was separating issue tracking and source control when we didn’t need all that power. Everything is so much simpler if you don’t have to maintain those integrations.
Maybe they’ll really enshittify GitHub in the future. We’ll cross that bridge when we come to it.
(I upvoted you, for asking the real questions, but to answer)
> Where do you keep Issues,
Youtrack
> Pull Requests,
Gerrit, it's way better for code review
> Wikis,
Also Youtrack, but other software exists that's specific for this, I have seen Confluence used a lot and while I don't recommend: that's usually the case.
> Discussions,
As far away from code as possible, right now it's Zulip
> project boards,
Youtrack, though usually in companies they use Jira for this.
> and everything else? (rhetorical question.)
In proper tools that are designed to solve a specific need, not try to do everything: badly.
--
Now, a sane person will respond to me with the fact that I haven't removed any single points of failure, I've actually just added more of them. They'd be right! The differences is that it makes the stack a bit more flexible and composable. Migration of, say, the Wiki, doesn't make major issues because it's already somewhat decoupled.