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.)

    #!/bin/sh
    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.
    BRANCH="master"
    
    read oldrev newrev ref
    
    # Only auto-deploy (checkout) the $BRANCH specified above.
    if [[ $ref = refs/heads/$BRANCH ]];
    then
      echo "Branch $ref received. Deploying ${BRANCH} branch to \"$DEPLOYDIR\" folder."
      git --work-tree=$DEPLOYDIR checkout -f
      echo "Done."
    else
         echo "Branch $ref received. Doing nothing: only the ${BRANCH} branch may be auto-deployed to the \"$DEPLOYDIR\" folder."
    fi
    

    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.