Git – is git required on server?

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.

  • Undo a particular commit in Git that's been pushed to remote repos
  • How to incorporate version control (Git) in a large Lotus Notes project
  • MacOS: Using Bitbucket and Github, SSH Key?
  • How do I add a submodule to a sub-directory?
  • SLOC in a git commit
  • Git pull fails with bad pack header error
  • Projects within projects using Git
  • How can I diff two branches with fugitive?
  • How to update git version on centOS? 403 fatal: HTTP request failed
  • Gitlab workflow and configuration for users
  • How can I get the Git build number and embed it in a file?
  • git checkout does not reset file
  • 3 Solutions collect form web for “Git – is git required on server?”

    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.

    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.

    Git is distributed version control. You don’t need to have server. You and your friend can work on yours 2 machines with git pull and git push without server (advantage of distributed version control).

    You can always use free (for small teams) server like

    Git Baby is a git and github fan, let's start git clone.