Git: Why use a hook for setting up repo on your server?

Tutorial after tutorial on setting up a git repo on your server are essentially all the same — and they go like this:

  1. Install git on your server
  2. Create git/project.git off your root directory of your server
  3. Initialize git/project.git using git init --bare
  4. In git/project.git/hooks then touch post-receive
  5. Add to post-receive: #!/bin/bash\n 2 GIT_WORK_TREE=/path/to/your/vc'd/project git checkout -f
  6. Then make post-recieve executable: chmod +x post-receive
  7. Back on your local machine, git clone ssh://user@host.com/git/project.git
  8. And add files, commit and push

This is all fine, and I can indeed push to the git/project.git and end up with those files in the path/to/your/vc'd/project but I’m looking to understand…

  • shell_exec configuration for git pull Godaddy vs Bluehost
  • Push to bluehost using Tower.app
  • Simple code to install a subversion repository on a linux server
  • How to avoid ssh passphrase while using git on bluehost
  • Mercurial between server and local?
  • How to install git repository on Bluehost
  • Why use the hook at all?

    It leaves you without the ability to pull your path/to/your/vc'd/project/ on your local machine.
    Why not just git init the path/to/your/vc'd/project and clone it on your local machine?

    Further, if anyone could explain how to get git pull functionality on the local side for the path/to/your/vc'd/project with this hooking method, it would be much appreciated

    Thanks 🙂

  • Trigger Jenkins tests after commits in git submodules
  • gitworkflows - how exactly to graduate a branch?
  • Using Git for Angular App
  • Error when syncing with Github for Mac app
  • How to amend the second newest commit
  • How to clone GIT repository with private key
  • One Solution collect form web for “Git: Why use a hook for setting up repo on your server?”

    It is best practice to push to a bare repo rather than a repo with a working tree.

    That way, the user cannot be surprise to see the file pushed not be displayed, because the target repo would have one branch checked out and the user is pushing another branch.

    Making the target repo update automatically a working tree based on what the user is pushing could be too dangerous: if you push the wrong branch, you replace your working tree content immediately.
    This is different from pushing to a bare repo and updating an external working tree through a hook: you can do some control in said hook.

    For more, see “all about “bare” repos — what, why, and how to fix a non-bare push”.

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