Re: Question re. git remote repository

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 16 Jan 2013 17:49:09 +0000
"Lang, David" <David.Lang@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]