On Wed, 16 Jan 2013 17:49:09 +0000 "Lang, David" <david.l...@uhn.ca> wrote:
> We're just in the process of investigating a versioning tool and are > very interesting in git. We have one question we're hoping someone > can answer. In regards to the repositories, I think I understand > correctly that each developer will have a local repository that they > will work from, and that there will also be a remote repository > (origin) that will hold the original version of the project. The name "origin" is purely arbitrary: any local repository might have > It appears from the limited reading I've done that the remote > repository must be hosted at github.com. Is this the case? Of course not. github is just a Git hosting provider. There are plenty of them -- both commercial and not-for-profit (a well-known service bitbucket.org is one example). > Ideally we'd prefer to simply create our remote repository on a drive > of one of our local network servers. Is this possible? Yes, this is possible, but it's not advised to keep such a "reference" repository on an exported networked drive for a number of reasons (both performance and bug-free operation). Instead, the canonical way to host "reference" repositories is to make them accessible via SSH or via HTTP[S]. To do this, a server running some POSIX OS (Linux- or *BSD-based) is the best bet. Both kinds of access require Git itself installed on the server. Obviously, SSH access requires an SSH server software (such as OpenSSH) as well and HTTP[S] access requires a web server (such as Apache). Of course, everything mentioned is available on any sensible OS you might install on your server. Read-only access might be provided by a special tool named "Git daemon" which is a part of Git. If you have more than a couple of developers you might want to install certain front-end Git software on the server which provides for "virtualized" Git users and fine-grained control over who can do what. Using gitolite [3] for this is the current trend. Web-browsing for your repositories, if needed, is usually provided by the tool named gitweb [4]. Everything I've just summarised is well explained in [5] and [6] (as an addendum). Another approach is to set up a "turn-key" solution such as GitLab [1] or gitblit [2]. 1. http://gitlabhq.com/ 2. http://gitblit.com/ 3. https://github.com/sitaramc/gitolite 4. https://git.wiki.kernel.org/index.php/Gitweb 5. http://git-scm.com/book/en/Git-on-the-Server 6. http://git-scm.com/2010/03/04/smart-http.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
