What is self hosted version control system and how is it different from github? I mean if I use self-hosted VCS then where does my code go? I mean: does it get uploaded to the server, or it is saved on my local machine? If it is uploaded to the server, then if I reset the computer, will I able to access my code again?
Let's take it word by word:
- Self: You or your organisation owns this thing. By contrast, a cloud-based offering by GitHub.com, Azure, GitLab.com, etc. (see this list on Wikipedia for a more comprehensive list) is not owned by you, but rather the service provider in question. Do not confuse ownership of the code (dictated by it's license – typically owned by you), with ownership of the service for performing version control on the code.
- Hosted: You or your organisation are responsible for operating and maintaining this thing. In some cases, this is exactly the same software (e.g. one can self-host GitLab or run GitHub Enterprise “on premise” in your own datacentre). This means keeping it secure, making any changes to it, serving user requests for change, etc. You are also responsible for some part of the infrastructure necessary to provide this service. This may vary, depending on who you have service provision agreements with, from everything down to the power and networking, or only the last layer of the service (here, the version control system itself), or anything in between.
- "version control system" (or VCS): anything (software or otherwise, but most likely software) which provides the functionality necessary to control versions. Note there is a subtle difference between Version Control and Version Control Software, although the meaning is often conflated.
The term VCS can refer to any version control system, even when it is not applied to software, however in our context, it can be assumed that you are referring to a version control system applied to software.
In other words, a “self-hosted VCS” can be thought of as:
A service and all of its components which is under your own ownership and control, acting as a version control system for software.
Often, this can take the form of:
- base infrastructure (network/power/server),
- operating system,
- authentication and authorisation mechanism, and
- the VCS server itself (Git, SVN, etc.).
The second part of your question is about how it is different from GitHub. The following contrast can be made:
- Functionally there may be differences between what you can do with GitHub an what you can do with your self-hosted VCS. GitHub, as is the case for almost all VCS hosted by third parties (i.e., not hosted by you) goes a few steps further than simply doing version control. There are collaboration tools, identity management, issue tracking, etc. built into their service. While this is strictly speaking not part of VCS, it greatly improves the experience of using one, almost to the point where doing version control without them feels impossible.
- GitHub owns and operates the service. You may make suggestions to change their service, API, etc., and perhaps even contributions to their open source products, but you do not own the service. It is provided to you based on the SLA for the offering that you choose. You cannot make your own changes to it. This is overall a very good thing, unless you are in the business of providing the VCS itself – but chances are that you just want to use the service, not compete with it.
Update to answer the edited question:
does it get uploaded to the server, or it is saved on my local machine? If it is uploaded to the server, then if I reset the computer, will I able to access my code again?
You are conflating two issues here: self-hosting and distributed version control. Of course, if you self-host on your own computer, your run the risk of losing everything if the machine dies. However, of someone else hosts your code in only one place, then you still risk losing everything if their machine goes down.
To address this (and several other issues related to centralisation of source control), distributed version control was invented. A good discussion is in the git book.
2I think this is a great answer, maybe a good addition would be to start from the contrary but well known examples: public services "in the cloud" github.com and gitlab.com are NOT self hosted services.– Ta MuOct 30, 2019 at 9:09
1Thank you for the suggestion I'll update it Oct 30, 2019 at 9:10
I feel slightly confused by this answer. Does this mean that I cannot self-host GitLab because I don't own it or I am not responsible to mantain it? I know it is possible to self-host GitLab, but this answer could imply it is not.– bracco23Oct 30, 2019 at 14:51
Yes, you have a point. The same argument could be made for GitHub Enterprise. I will update the answer to make it explicit that I am referring to GitLab/GitHub.com vs GitLab/GitHub product Oct 30, 2019 at 14:54
You've made the world "self" and "hosted" more complicated than they need to be! Self = Yours; Host = server.– jpaughOct 31, 2019 at 18:35
Assume you have your own IT infrastructure, eg a Linux server or a good old mainframe, on which you are running (hosting) your VCS software of choice, e.g GIT or ChangeMan ZMF. In such case you have a self hosted hosted VCS. As compared to GitHub, which is a web-based hosting service for software development projects using Git.
1Nothing wrong with this answer, but I think a more verbose and explicit one may also have a place here :) Oct 30, 2019 at 8:35
An example will be maybe worth a thousand words:
$ sudo apt install git $ ssh 192.168.0.110 kub@host:~$ git init --bare repo1 Initialized empty Git repository in /home/kub/repo1/ kub@host:~$ logout Connection to 192.168.0.110 closed.
Voila, We already posses a self-hosted version control system. Let's use it as an example client:
$ git clone 192.168.0.110:repo1 /tmp/r Cloning into '/tmp/r'...
I fail to see how this is 'self' hosted. This or something very similar has to be done on any git server self hosted or otherwise Oct 30, 2019 at 19:54
This is self hosted in so far, that the code is stored on a different machine in a local network. Oct 31, 2019 at 8:49
2Yes, this is an example, but what does it teach the OP and later visitors? Is this how you properly set up a self-hosted Git server? What is the meaning of
192.168.0.110? What if that machine's hard drive crashes? This may be a little helpful if you know what you're doing, but obviously the OP is not, and this does not help them. Oct 31, 2019 at 10:15
What is self hosted version control system
A version control system hosted in a location you control and administer yourself.
Git is designed as a "distributed version control system", this means that by default every user has a complete copy of the history. It's not strictly necessary to even have a central server at all, though it is generally very inconvenient not to.
At a minimum a shared git repo can simply be a shared directory that you all have access to on a unix-like system you can all ssh into.
Most people however would like something a bit fancier than that, they may want the ability to let people perform some write actions on the repo without giving them full access to do anything they like to it. They may want a web interface to browse the code. They may want issue-tracking that integrates with the repo, they may want a pull-request system.
and how is it different from github?
Github mostly operates as a cloud-service*, your code is stored on servers owned and controlled by github. They provide hosting for git repos, along with a bunch of related services like issue tracking and pull-requests. Initially their model was that public repos were free and private ones cost money. Since the microsoft takeover they have started offering limited private repos for free, but if you want to do serious private collaboration you are going to have to pay them.
The advantage of cloud-services is that you don't have to expend any effort on maintaining the service. The downside is the operator of the cloud service can screw you over at any time and there is little you can do about it.
With git the risk is somewhat less than with other cloud services because as I mentioned earlier the actual version control history is kept by every client, so you can set up a new git server, switch your clients over and as far as the code itself is concerned things can continue as before. However you still risk losing the other stuff like the issue tracker, pull requests, permission setups etc.
If you want to self-host a git service with integrated web interface, issue-tracking and pull-requests then the main option i'm aware of seems to be gitlab.
* They do offer a self-hosted option for "Github Enterprise", but their website says nothing about how much it costs.....
A "self hosted version control system" is one that is used for tracking its own source code.
When a new version control system is developed, initially no version control is used for it, or some existing version control.
Eventually, a major milestone is reached when the version control system is good enough for handling its own source code. At that point, the developers are motivated to actually switch to it; and thereby it has become self-hosted.
This is a similar concept to a self-boostrapping compiler: a compiler written in its own language. You need that compiler to compile that compiler, just like you need a running version of a self-hosting version control system in order to check out its own sources.
Every serious version control system is self-hosted, because if it isn't, it shows that the authors don't have confidence in it; would you use Git if the development of Git relied on something else, like Mercurial?
This is not to be confused with a "self-hosted repository" which is just a version control repository that you host yourself on a machine that you control instead of using someone else's hosting service like gitlab.
Sorry, I believe you have the premise entirely wrong. It's not about who "owns" the version control tool. It's about who owns the hosting infrastructure and if that's the same as who owns the IP being placed under version control.you got the first statement correct.– Ian WAug 24, 2020 at 10:36
.svnsubdirectories for everything under version control and that's where each version of your code goes