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.

  • Is it possible to edit source files while push is in progress?
  • What's the difference between git stash save and git stash push?
  • Commit from a github issue
  • git svn rebase always requires force push
  • git automatic revert set of commits
  • Git Bash to Create Repository in Network Places?
  • How to properly use git with local remote
  • show only one history by commit SHA-1 key
  • git merge two branch from one commit up to HEAD
  • Using NodeGit CloneOptions to clone a branch
  • Why does git-pull manpage say “You never do your own development on branches that appear on the right hand side of a <refspec> colon on Pull: lines”?
  • git diff between staged changed and HEAD repository
  • 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.