Using #git is not the whole picture on #modernhw version control landscape. Git is great when one decides to locally follow changes, take diffs, create branches and so on. When it comes to collaboration with other people or to create a community around a common project, the need for extra tooling arises, and it becomes evident that git alone is not enough. A #gitforge fills this gap.
Git bare repositories are a means of sharing the local git history remotely. Bares doesn’t show the worktree, as they are used solely as a common exchange place. This might be a remote server accessible through ssh, for example. Several different users may collaborate this way, provided they agree on a common workflow. Bares are more than enough for some needs. A front end on top of it may help to get an overview of what is going on and to take a look at branches, users and the like. All it takes to make this workflow useful is a little management, as git was designed with a fully distributed architecture in mind. Check the docs for more details.
Now, this approach is a bit too bare bones for most people. On top of bare git repositories, some decided to add extra functionality to ease using git remotely, calling for contributors attracted by buttons, colors, menus and most generally, being used to web frontends. Web forges include all usual suspects (project creation and configutation, markup rendering, user account and authorizations, project overview, etc.), as well as more advanced features (continuous integration, #ci, for testing and deployment with git hooks, wikis, code linters, built in actions, issue tracking, etc.). They abstract the use of git showing diffs, logs, issues threads, etc. As any other web gui tool, they come with its own set of inconvenients in what concern user freedom.
Popular examples are all around. #Gitlab may be deployed as a custom (not federated) instance, and is commonly found in research and public institutions; codeberg, based on forgejo, is a great example of how to deploy a lightweight #freesoftware instance of a collaborative forge (and the promise to federate on the fediverse). Many others exist, which more or less features, bells and whistles. You always have the choice.

sourcehut

#Sourcehut, as a collaborative platform, deserves special attention. It departs from mainstream forges, following a different paradigm based on the most robust, distributed and flexible technology at our hands since decades, plain text #email. Git, since its origins, includes a close integration with email, as they both share a distributed philosophy, avoiding central point of failure silos (surprising how mosft git forges tend to concentrate in silos). Sourcehut core architecture is based on mail exchange, patches and #maillists, which turns out to be a much more flexible approach than that of what most forges propose. Their concept of project goes well beyond that of usual workflows, integrating nicely git with email, wikis, bug trackers and build features. They’re still in an alpha stage, so expect the best still to come.