Git - is git required on server?

Question

I've read a lot of information but still can't understand. Let's suppose we have server machine and client machine. The client connects to server via ssh. There is no any authentication on server for git. I consider the simplest configuration- there are three clients and one server. On server git repo is stored

Do we need to install git on server this case? I am confused as git push and git clone commands are executed using git on client side.

Answer 1

As others pointed out, you don't need a "server" in the sense "one big machine somewhere on the internet", but if you use git push, the machine on which you run git push is technically the client machine, and the one you push to is the server during this operation.

When you run git push, Git essentially runs ssh user@server 'git-receive-pack /path/to/repo', i.e. it runs git-receive-pack on the server. Then, the local git push talks to the remote git-receive-pack via the SSH connection.

In short: you need Git on the server when pushing through SSH. Not necessarily a full installation, but at least the executable git-receive-pack to push and git-upload-pack to fetch/pull.

It's also possible to push to a remote machine without Git installed there using other protocols (eg. webdav), but I wouldn't recommend it.

Answer 2

just to add to the very good answers already here.

the notion of a 'server' when it comes to git is confusing. We like to think of there being some central point where everything 'lives', in our technical lives we think server for this. We find this idea comfortable (rightly or wrongly)

Being a distributed system, every cloned copy of the git-ball is technically the repository.

That being said, its still a very good idea to have some 'central' point of control for your repository.

Bitbucket or github, or even your own box sitting somewhere can act as a 'master' repository.

Professional uses of git are commonly organised with a 'master' repo, on bitbucket say, which is writable only by pull requests. Team members will fork the repository, do their work, then after committing to their own repository, issue a pull request to the 'master' repo. Then peer code review can take place and successful pull requests merged into the main repository.

This promotes a lot of good practice and also means that you have a nice clean repository backed up on someones elses service.

We (in my organisation) have probably over 100 projects run in this way, in many languages and it works extremely well.

there are a couple of workflows using this as a basis. Have a look here for a reasonably good explanation.