git init --bare /path/to/repo.git
on the server. Then locally you git clone that repo with a ssh url.It does not have any visual MR or enterprisey features, but it works.
git init --bare /path/to/repo.git
on the server. Then locally you git clone that repo with a ssh url.It does not have any visual MR or enterprisey features, but it works.
The features are basic and managed by editing text files and git-pushing them to a control repository: create repositories, add users and their keys, readonly or readwrite. There is no GUI but once you have a copy of the repo on your machine you can use one of the several git GUIs available for any OS.
Bare repo on a server is exposed to people exactly like Github: a remote URL you put in once and forget about it.
How people use their local git repository is their business, command-line, Sourcetree, GitKraken, what have you, but any of those work with any remotes.
(Sure, git by itself does not provide the other features from the hosting services like issue tracking and pull requests, but not every workflow requires those to be linked directly to the SCM)
Heck I think even the Github Desktop application also works with non-Github repositories, and they would be the only ones that would have any interest in locking people in.
Unless you mean specifically the UX of having a URL you can copy to a specific line of a specific commit in a repository, which indeed is not possible without a standard URI scheme (which does not exist) or a web client.
It is not a personal criticism to you. I find it interesting git gave us all this efficiency and the enterprise removes it by adding complexity back because employees supposedly cannot be bothered to learn their tools (or cannot be mandated) or plainly prefer a nicer ui. Not a crime, but I can see how big corporations become inefficient with this type of thinking, when appliend to hundreds of tools and processes.