Use git with just a shared network drive. No git server required!

Want to use git for a small team of developers, but can’t (or don’t want to) use a git server? No problem! All you need is a shared network drive (like a dev server) that all of your developers can access. You’ll set up a repository for each developer, a central bare repository for them to push files to, and a git hook to auto-deploy files to a folder of your choice. This workflow works great for projects like websites and web applications.

In the end we’ll expect to have a structure that looks something like this.

├── app/
│   └── index.html
├── app.git/
│   ├── hooks/
│   │    └── post-receive
│   ├── info/
│   ├── objects/
│   ├── refs/
│   ├── config
│   ├── description
│   ├── HEAD
│   └── index
├── app-developerOne
│   ├── .git/
│   └── index.html
└── app-developerTwo/
    ├── .git/
    └── index.html

Let’s begin!

  1. Ensure you have git installed.
  2. Open up git bash. We’ll be using the bash command line for most of this guide.
  3. Set up a bare repository. Conventionally, the folder that is used for your bare repo should end in .git. For this example, we’ll pretend the name of our application is app and call the bare repo’s folder app.git accordingly.
    (The next few commands are based on this stack overflow answer.)

    mkdir app.git
    cd app.git
    git init --bare

    Why a bare repo? A bare repo acts sort of like your team’s “GitHub”. Developers pull latest changes from this repo into their personal repositories, then later push their changes back into this repo. No one will ever directly edit the files in the bare repo. In fact, they can’t. Bare repos don’t even show the source-controlled files–they have no working or checked out copy of these files. You can read more about bare git repos here.

  4. Next, back out of the app.git folder, then set up a repo for your first developer. Normally I’d name the developer repos after my developers, but for this example I’ll just call our first developer “developerOne”
    cd ..
    mkdir app-developerOne
    cd app-developerOne
    git init
  5. Add any of your app’s existing files to this newly created repo (the app-developerOne folder). In my example I simply added an index.html file.
  6. Stage all files (can be done on command line or with GUI.)
    git add .
  7. Commit all files (can be done on command line or with GUI.)
    git commit -m "Initial commit."
  8. Add the app.git bare repo as this repo’s “origin”.
    git remote add origin ../app.git
  9. Before pushing for the first time, let’s set up a git hook to automatically copy pushed changes to a folder. Go ahead and navigate to the hooks folder, and use touch to create an empty file named post-receive. Note, the post-receive file won’t have any extension.
    cd ..
    cd app.git/hooks
    touch post-receive
  10. Edit the post-receive script to add the following code. You could use a command line editor like nano or vim, or simply open the file in a text editor such as Notepad++ or Atom.
    You must change ../app (near DEPLOYDIR) to be the actual name of the folder you wish to push to. You shouldn’t have to change anything else.
    (This post-receive script was based on this one.)

    echo "Executing post-receive script. (Located in the --bare repo's hooks folder.)"
    # Instructions:
    # Put this file into your .git/hooks folder and set as executable 
    #- for Windows (attrib +x pre-commit)
    #- for ubuntu (chmod +x pre-commit)
    DEPLOYDIR=../app # The place to deploy to.
    read oldrev newrev ref
    # Only auto-deploy (checkout) the $BRANCH specified above.
    if [[ $ref = refs/heads/$BRANCH ]];
      echo "Branch $ref received. Deploying ${BRANCH} branch to \"$DEPLOYDIR\" folder."
      git --work-tree=$DEPLOYDIR checkout -f
      echo "Done."
         echo "Branch $ref received. Doing nothing: only the ${BRANCH} branch may be auto-deployed to the \"$DEPLOYDIR\" folder."

    Now, whenever changes are pushed to the bare repo, they will be automatically copied to the desired deploy folder. Conveniently, none of the .git folders or other version control info will be placed in the deploy folder. You can easily upload the full contents of your deploy folder to your production web sever, without worrying about accidentally including extraneous version control files. If you want to make more changes to the post-receive hook, and test them quickly, take a look at this article.

  11. We also need to make sure that the “app” deploy folder which this post-receive hook wants to deploy to actually exists. Let’s back out of the hooks folder back to our site’s root directory and create it.
    cd ../..
    mkdir app
  12. Now let’s test the post-receive hook. From an individual developer’s repo, use this command (or a GUI) to push changes to the bare repo.
    cd app-developerOne
    git push origin master
  13. If you look in the deploy folder, it should have your latest pushed changes. (For me, this is just an index.html file.)
  14. To create other repos for other developers:
    cd ..
    git clone app.git app-developerTwo

    Now anyone can push and pull directly from master branch, and their pushed changes will automatically be placed in our deploy folder. Our workflow is all set up!

This should be everything you need to set up a basic git workflow, without any need for a git server! Developers should pull the latest changes from the bare repo before beginning work, then push their new commits back to the bare repo. This isn’t much different from other git workflows you may be familiar with (such as using GitHub). Anytime new changes are pushed to the bare repo, a ready-to-be-uploaded version of your website or web app will be placed in your deploy folder.

Any questions? Ask below or email me.

5 thoughts on “Use git with just a shared network drive. No git server required!”

    1. One of the nice things about Git is that it was always designed to work with Git folders like this.
      As long as you have Git software installed (and, if you were able to follow these steps, you do have it installed), you can use all of your usual commands or GUI tools to interact with your Git folders.

      For example, on Windows type open the start menu and type “Git GUI” to find Git’s default GUI tool. Then click “Open Existing Repository” to select the Git folder that you’re working on.

      Git GUI allows you to view commits via “Repository” > “Visualize master’s history” or “Visualize all history”. You can see diffs and previous commits here.

      You can reset to a different earlier commit by reverting to its hash. You could do this via the command like (for example: ) or could do it in the GUI by visualizing history as above, then right clicking on the branch you’d like to revert to, and choosing “reset master branch to here”.

      You can revert unstaged changes for a file (or several files) via “Commit” > “Revert changes”.

      You can also do this stuff on the command line if you know the right commands, but I personally tend to go with the GUI.

  1. Is it necessary to put the developers folders on the network drive? Could they just as easily be put on the local drive?

      1. Certainly, any drive of your choosing works. I choose a network drive so that the devs can easily access it from their own computers.

Leave a Comment

Your email address will not be published. Required fields are marked *