For those who aren't aware, Git is actually a fully decentralised system. It doesn't require a central server as such - though most teams use one, as it's a convenient setup for most projects.
Even if you are hosting on github/bitbucket/et. al. though, that repository is just one of many equals. You can push and pull from multiple peers as long as you have access set up appropriately.
I recommend the chapter on distributed workflows in Pro Git:
Gitlab also can be run in your own server. It actually has an enterprise and an open source version. We use the open source one for a couple of years and it is really great - I recommend it with all my heart.
It has great instructions for installing directly from source and you don't really need to be familiar with ruby to install it. It requires some standard components (web server, database) which should exist on all servers and then you follow the instructions and presto! You have your own gitlab!! It also has great upgrade instructions so you can always be up-to-date.
I know gitlab can also be used through the cloud version (and it even has free private repos) however some organizations feel better if the source code of their projects stay inside the organization.
Gitlab is massive though. I think it's a great solution for teams on dedicated hardware, but if you need something quick, low-maintenance and lightweight Gitlab might be a bit overkill.
This is a good setup if you are the only one accessing the repo.
If you need something a little bit more complex, I would highly recommend gitolite for managing repositories & users. Configuration is done via some INI/TOML-like files in a git repo. User public keys are stored in the same repo.
gitolite has amazingly powerful access control, not just per-repo but per-branch or per-directory within a repo. It has very flexible self-service features, if you are OK with remote commands over ssh. Lots of nice scripting hooks.
...meanwhile, if your access control needs are less sophisticated, you can create the common group for all your git users, and use "git init --bare --shared=group" to set repository permissions correctly.
(You'll have to create separate UNIX shell accounts for all your developers sharing a common group with this setup, and this may or may not be a good idea.)
Hehe, I just found out that I am using gitolite since about six and a half years by now. It exists primarily for my personal endeavors, but at the moment it hosts about (small) 50 projects and 10 users.
While the hardware below had some major failures (2 SSDs died during that period) the gitolite always survived. I like it :-)
Eh. The method described in this post (ie bare repositories on a filesystem and ssh transport) is perfectly sufficient for my personal use if I'm hosting. The minute there's a MySQL dependency I'm a hard pass...
I buy the need for the gitlabs of the world when multiple users show up, if only because managing credentials is a pain. But for single user use cases I wouldn't waste my time.
"Doing this is cheaper than paying GitHub, and it will give you the satisfaction of being a True Hacker."
Or I could work on problems that really matter and leave the sysadmin job to someone who gets paid to do it. ;)
More seriously, when I was in college, I spent a lot of time doing things like running my own mailserver, selfhosting various projects, etc. I learned a lot. But in the Real World, I don't want to be responsible for more than I have to be; off the shelf products are just better for me, most of the time.
The fact that Bitbucket and Github will pay a guy to run a git server for me is amazing (even if it is evidence of some sort of irrational enthusiasm on part of VC firms). Why would I not want to take advantage?
Except running a git server is little more than having a place to store a git repo and giving ssh access to it. There's really no maintenance if you already have the server. What github et al provide isn't repo hosting so much as fancy UI tools on top of that.
Edit: seriously, I wonder how many people who just automatically go to github have ever bothered to try the simple act of creating a git remote on a file server on their own network, or even just to a different host. It's really easy, and it really underscores how simple it is to have your repo distributed without any 3rd party infrastructure. Once you see that, you see that putting a copy on a shell account on your hosted VM is dirt simple and requires almost no administrative burden.
In the "real world" people like to keep their private source code private, and they run version control servers on their own LAN with tape backups or the like.
I personally set up a remote-access git repository on Windows, with Windows domain authentication (Apache+mod_ldap+mod_authnz_ldap), and it wasn't any more difficult than any other Apache installation; a more sensible platform would require a negligible effort.
Because you never know when one of these online services will suffer an outage, suffer a security breach that leasks your private repos or email & credentials, or even lose your data entirely. The fact that the service is free doesn't mean that it doesn't come without potential issues.
Not everything needs to be in the cloud, and using any online service run by someone else brings some degree of reliability, security, privacy and longevity risk. Some of us just prefer to avoid those risks, and usually will unless there's some compelling benefit that outweighs them.
If you don't need code review and don't mind a hosted solution, you can get by with the AWS free tier and use IAM for all your access control.
AWS CodeCommit:
5 active users per month
50 GB-month of storage per month
10,000 Git requests per month
Does not expire at the end of your 12 month AWS Free Tier term.
Security question. Can `git-shell` restrict users to their remote home directory? Or if you give me a git shell, can I still do things like `git clone [email protected]:/home/you/secret-sauce` ?
This is only an issue if you're sharing the box and/or remote repositories with other people. For shared remote repositories I've been using the following setup:
1. Create a bare, shared repository at `/var/git/foo`. Configure unix group permissions and the directory setuid bit on it.
2. Give alice access via a `/home/alice/foo -> /var/git/foo` symlink.
3. Set alice's shell to a patched version of the git shell I call `git-home-shell` that sanitizes the repository path argument and makes it relative to her home dir.
For multi-user use probably best solutions are scripts/systems that automate this whole thing like gitosis and gitolite. You get multiple users logging in as same system user which are authenticated by their SSH key and administration of the thing is mostly performed by commiting into special git repository.
Quick note: what this article doesn't explicitly says is that as long as you have a shell account somewhere with a decent amount of disk space, you can host or mirror all the repository you want.
If I may make a suggestion, I'd recommend the Super Dimensional Fortress Public Access UNIX System (https://sdf.org/).
They're NetBSD-based if I remember correctly, and for a low fee (36$/lifetime ARPA membership + 9$/quarter) you can host most of the things you would like to host.
Privacy isn't binary, and there's a large difference between "Amazon could potentially read this, but they'd be breaking their own ToS and some laws to do so" and "Public on the internet".
I do self-host a few repositories as well, but I do not set up a separate user: I just create a git/ dir in the home dir of the account I want to host the repositories on and put the repositories there.
To simplify the initial setup, I created a handy shell script, reposetup [1]. It makes to create repositories, push to them and remind me their urls.
If you’re using Google Cloud, you can already use Google Cloud Source Repositories. https://cloud.google.com/source-repositories/ It supports git and the Beta release of Cloud Source Repositories provides free hosting of up to 1GB of storage.
As others have already stated, this article is a great introduction for when you'll be the only one to access the repositories, as anyone able to authenticate for that account will have access to all repos.
There are some tools that restrict access with varying levels of granularity, but if you just want to restrict access on a per-repo-per-sshkey basis, one of my projects is a simple shell script that does just that:
It originally came to be because I've found gitolite too big to maintain for simply sharing some repositories with a few other people. It has since served me well and is used in some business applications, too.
http://gitblit.com/ is also worth looking into. It is more sophisticated then gitolite (which I also use) and less hairy then gitlab. It is Java based, but doesn't require a database.
Also, for backup, rather then tar up the ".git" directory, I use "git bundle <backupfilename> --all" which creates a flat file with all branches included. This file can then be uploaded to GCS or S3.
If you want something light weight and "run and done" then check out GitBucket [0]. You only need the JVM & git installed. When you run the program it sets everything up. Very easy, clean interface, and simple to back up (I just snapshot the entier folder).
[+] [-] peterkelly|9 years ago|reply
Even if you are hosting on github/bitbucket/et. al. though, that repository is just one of many equals. You can push and pull from multiple peers as long as you have access set up appropriately.
I recommend the chapter on distributed workflows in Pro Git:
https://git-scm.com/book/en/v2/Distributed-Git-Distributed-W...
There's also an explanation of the different supported protocols here:
https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...
[+] [-] maccard|9 years ago|reply
Normally if you're hosting on one of those sites, you're using other features (wiki/issues), which may _not_ be decentralised
[+] [-] Chattered|9 years ago|reply
[+] [-] spapas82|9 years ago|reply
It has great instructions for installing directly from source and you don't really need to be familiar with ruby to install it. It requires some standard components (web server, database) which should exist on all servers and then you follow the instructions and presto! You have your own gitlab!! It also has great upgrade instructions so you can always be up-to-date.
I know gitlab can also be used through the cloud version (and it even has free private repos) however some organizations feel better if the source code of their projects stay inside the organization.
[+] [-] treve|9 years ago|reply
[+] [-] uiri|9 years ago|reply
If you need something a little bit more complex, I would highly recommend gitolite for managing repositories & users. Configuration is done via some INI/TOML-like files in a git repo. User public keys are stored in the same repo.
[+] [-] fanf2|9 years ago|reply
Gitolite home page: http://gitolite.com/gitolite/
I run a multi-tenant gitolite setup for the University of Cambridge: https://git.csx.cam.ac.uk/
[+] [-] atemerev|9 years ago|reply
(You'll have to create separate UNIX shell accounts for all your developers sharing a common group with this setup, and this may or may not be a good idea.)
[+] [-] rcarmo|9 years ago|reply
[+] [-] JepZ|9 years ago|reply
While the hardware below had some major failures (2 SSDs died during that period) the gitolite always survived. I like it :-)
[+] [-] fizixer|9 years ago|reply
[+] [-] falava|9 years ago|reply
https://gogs.io/docs/installation
[+] [-] zzalpha|9 years ago|reply
I buy the need for the gitlabs of the world when multiple users show up, if only because managing credentials is a pain. But for single user use cases I wouldn't waste my time.
[+] [-] rcarmo|9 years ago|reply
[+] [-] Symbiote|9 years ago|reply
[+] [-] md_|9 years ago|reply
Or I could work on problems that really matter and leave the sysadmin job to someone who gets paid to do it. ;)
More seriously, when I was in college, I spent a lot of time doing things like running my own mailserver, selfhosting various projects, etc. I learned a lot. But in the Real World, I don't want to be responsible for more than I have to be; off the shelf products are just better for me, most of the time.
The fact that Bitbucket and Github will pay a guy to run a git server for me is amazing (even if it is evidence of some sort of irrational enthusiasm on part of VC firms). Why would I not want to take advantage?
[+] [-] hamburglar|9 years ago|reply
Edit: seriously, I wonder how many people who just automatically go to github have ever bothered to try the simple act of creating a git remote on a file server on their own network, or even just to a different host. It's really easy, and it really underscores how simple it is to have your repo distributed without any 3rd party infrastructure. Once you see that, you see that putting a copy on a shell account on your hosted VM is dirt simple and requires almost no administrative burden.
[+] [-] HelloNurse|9 years ago|reply
I personally set up a remote-access git repository on Windows, with Windows domain authentication (Apache+mod_ldap+mod_authnz_ldap), and it wasn't any more difficult than any other Apache installation; a more sensible platform would require a negligible effort.
[+] [-] midnitewarrior|9 years ago|reply
I use GitHib client using BitBucket for repo hosting with LFS and it works great, no need to host anything.
[+] [-] RandomOpinion|9 years ago|reply
Because you never know when one of these online services will suffer an outage, suffer a security breach that leasks your private repos or email & credentials, or even lose your data entirely. The fact that the service is free doesn't mean that it doesn't come without potential issues.
[+] [-] seangrogg|9 years ago|reply
[+] [-] newsat13|9 years ago|reply
[+] [-] Silhouette|9 years ago|reply
Not everything needs to be in the cloud, and using any online service run by someone else brings some degree of reliability, security, privacy and longevity risk. Some of us just prefer to avoid those risks, and usually will unless there's some compelling benefit that outweighs them.
[+] [-] 2bluesc|9 years ago|reply
[+] [-] peterkelly|9 years ago|reply
[+] [-] rocky1138|9 years ago|reply
[+] [-] philsnow|9 years ago|reply
[+] [-] sandGorgon|9 years ago|reply
https://gitbucket.github.io/gitbucket-news/gitbucket/2017/03...
[+] [-] sigil|9 years ago|reply
This is only an issue if you're sharing the box and/or remote repositories with other people. For shared remote repositories I've been using the following setup:
1. Create a bare, shared repository at `/var/git/foo`. Configure unix group permissions and the directory setuid bit on it.
2. Give alice access via a `/home/alice/foo -> /var/git/foo` symlink.
3. Set alice's shell to a patched version of the git shell I call `git-home-shell` that sanitizes the repository path argument and makes it relative to her home dir.
Is there a better way these days?
[+] [-] Symbiote|9 years ago|reply
You could create a group for each repository, and add and remove members as necessary.
[+] [-] dfox|9 years ago|reply
[+] [-] znpy|9 years ago|reply
If I may make a suggestion, I'd recommend the Super Dimensional Fortress Public Access UNIX System (https://sdf.org/).
They're NetBSD-based if I remember correctly, and for a low fee (36$/lifetime ARPA membership + 9$/quarter) you can host most of the things you would like to host.
And you don't have to do system maintenance.
[+] [-] voltagex_|9 years ago|reply
[+] [-] exceptione|9 years ago|reply
edit: thanks anyway for your version!
[+] [-] Filligree|9 years ago|reply
[+] [-] agateau|9 years ago|reply
To simplify the initial setup, I created a handy shell script, reposetup [1]. It makes to create repositories, push to them and remind me their urls.
[1]: https://github.com/agateau/reposetup
[+] [-] alpb|9 years ago|reply
[+] [-] amalag|9 years ago|reply
[+] [-] _cbdev|9 years ago|reply
There are some tools that restrict access with varying levels of granularity, but if you just want to restrict access on a per-repo-per-sshkey basis, one of my projects is a simple shell script that does just that:
https://github.com/cbdevnet/fugit
It originally came to be because I've found gitolite too big to maintain for simply sharing some repositories with a few other people. It has since served me well and is used in some business applications, too.
[+] [-] RangerScience|9 years ago|reply
(I know it doesn't look complicated, but if there's a decent "standard" already out there...)
[+] [-] Karunamon|9 years ago|reply
https://hub.docker.com/r/gitlab/gitlab-ce/
[+] [-] microtherion|9 years ago|reply
[+] [-] simplehuman|9 years ago|reply
[+] [-] jis|9 years ago|reply
Also, for backup, rather then tar up the ".git" directory, I use "git bundle <backupfilename> --all" which creates a flat file with all branches included. This file can then be uploaded to GCS or S3.
[+] [-] gravypod|9 years ago|reply
[0] - https://github.com/gitbucket/gitbucket
[+] [-] tlarkworthy|9 years ago|reply
https://stackoverflow.com/questions/1960799/using-git-and-dr...
[+] [-] RAWRfftfftfft|9 years ago|reply