git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Konstantin Khomoutov <kostix@bswap.ru>
To: Simon Phai <simonphaikm@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Git Server
Date: Fri, 5 Apr 2024 12:11:38 +0300	[thread overview]
Message-ID: <20240405091138.youg4wfk3r3lw2k2@carbon> (raw)
In-Reply-To: <CACArJ23dNONx-Fk5VwZZ+A64aEYW0nhn+X6q50W5hKLN=VbEng@mail.gmail.com>

(Reformatted to have inline style [1].)

On Thu, Apr 04, 2024 at 06:26:31PM +0800, Simon Phai wrote:

> > > I want to host my own git server, may I understand the server OS can
> > > it be windows?
> >
> > Yes.
> >
> > But note that there exist quite many ways to "host a Git server", so you
> > should maybe explore what's already there and specify your requirements
> > more precisely.
> >
> > In the simplest form (if we forget about just running git-daemon in a
> > console window - providing unprotected R/O access to a given repository),
> > you either set up Git to be accessible via an SSH server or via a web
> > server (IIS works).
> >
> actually I'm quite new to this but I would like to setup my own git
> server so that my fellows can develop our own repository, I find
> online there isn't much guide on using windows server to do it.

Unfortunately, this added not too much information to the original question.
I mean, now we know that you want to host a Git server on a Windows system,
there is a single repository to make access to and that there is going to be
more than a single person to have access to that repository.

OK, let us try to maybe move a bit further.

The first thing to know, is that Git does not provide any "high-level" -
Github-like or GitLab-like, is you want - solution out of the box.
It basically provides three ways to access Git repositories remotely:

 - A thing called "git-daemon" which provides an unprotected and
   unauthenticated access to a Git repository. Because of these properties,
   by default the access it read-only, and even though you can convince it
   to be read-write, it's a bad idea unless you really understand what you're
   doing, and, based on what you described about your prospective setup,
   this is certainly not what you want to do.

 - Two low-level programs (whose names do not matter) which are supposed to be
   used in conjunction with an SSH client and server. This means you need to
   have an SSH server running on the host with a Git repository (or multiple
   repositories), and the clients are to use SSH clients to access those
   repositories. For clients, this happens almost transparently - they do not
   need to manually run SSH clients, it's done by "git push/fetch/pull"
   commands automatically when the URL of a remote repo has the "ssh://"
   scheme, - but the server-side setup has to be rather explicit.

 - More low-level commands intended to serve access to Git repos with the help
   of an HTTP server. This works in a manner quite similar to that of SSH,
   just HTTP (these days, HTTPS is more common) transport is used instead.
   Again, clients handle this automatically if the URL of a remote repository
   to work with has the "http://" or "https://" schemes.

Note that neither of the described solutions provide any user management and
access control facilities, and this is arguably the most complex part of
setting server-side Git up: making an SSH or HTTP server start Git is not too
complex, but putting up user management and access control is harder, and is
different for SSH and HTTP.

To research, you could start with [2] and [3]. These do not present the whole
solutions but at least it's something you can probably start with.

Also note that having an SSH+Git and/or HTTP+Git combo only allows you to
maintain a so-called "rendez-vouz" repository (or a set of them) basically
used by a team to share their developments. Such a solution won't provide you
with a web-browsable access to repositories, code review, issue tracker and so
on and so forth. There will also be quite limited, if any, access to
fine-grained access control - basically to who can push where. If you need
anything of the above, you might have better luck trying a "turn-key" solution
such as [4] or [5].

 1. https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
 2. https://github.com/PowerShell/Win32-OpenSSH/wiki/Setting-up-a-Git-server-on-Windows-using-Git-for-Windows-and-Win32_OpenSSH
 3. https://smalltech.com.au/blog/how-to-run-a-git-server-on-windows-with-iis
 4. https://about.gitea.com/products/gitea/
 5. https://gogs.io



      parent reply	other threads:[~2024-04-05  9:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-04  9:54 Git Server Simon Phai
2024-04-04 10:08 ` Konstantin Khomoutov
2024-04-04 10:26   ` Simon Phai
2024-04-04 21:14     ` brian m. carlson
2024-04-05  9:11     ` Konstantin Khomoutov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240405091138.youg4wfk3r3lw2k2@carbon \
    --to=kostix@bswap.ru \
    --cc=git@vger.kernel.org \
    --cc=simonphaikm@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).