Skip to content

Instantly share code, notes, and snippets.

@nonbeing
Forked from noelboss/git-deployment.md
Last active October 27, 2025 01:01
Show Gist options
  • Select an option

  • Save nonbeing/f3441c96d8577a734fa240039b7113db to your computer and use it in GitHub Desktop.

Select an option

Save nonbeing/f3441c96d8577a734fa240039b7113db to your computer and use it in GitHub Desktop.

Revisions

  1. nonbeing revised this gist Jun 17, 2019. 1 changed file with 15 additions and 8 deletions.
    23 changes: 15 additions & 8 deletions git-deployment.md
    Original file line number Diff line number Diff line change
    @@ -18,12 +18,18 @@ This creates a scenario where there is no middle-man, high security with encrypt
    2. Have a local working-directory ready to deploy, with AT LEAST 2 commits in the `git log`.
    2. Have SSH access to your server using private/public key

    # TLDR: Procedure
    1. Create a directory on your remote (ssh) server to receive the deployment (e.g. `/var/www/html`)
    2. Add a bare git repository on the remote server
    4. Add the `post-receive` hook shell script to the bare repository, make it executable
    5. Add the remote-repository as a 'git remote' to your local git repository
    6. Push to the production server, relax.
    ## TLDR: Procedure
    - Have the local workspace dir ready to deploy

    - Create a directory on your remote server to receive the deployment (e.g. `/var/www/html`)

    - Add a bare git repository on the remote server

    - Add the `post-receive` hook (shell script) to the bare repository, make it executable

    - Add the remote-repository as a 'git remote' to your local git repository

    - Push to the production server, relax.

    ## 1. Have a local working-directory ready to push
    Nuf said. I assume we are working on master – but you could work on any branch. Ensure there are at least 2 commits.
    @@ -50,6 +56,7 @@ The script we will use does check if the correct branch is being pushed (it won'

    See the [post-receive](#file-post-receive) file for details.

    Ensure it is executable: `chmod a+x ~/bare-project.git/hooks/post-receive`

    ## 5. Add a remote to your local git repo
    Now we'll add the bare repository (on the remote server) to your local system as a 'git remote'. For this example, `prod` is what we'll call this remote. This could also be called "staging" or "live" or "test" etc if you want to deploy to a different system or multiple systems.
    @@ -62,8 +69,8 @@ Now we'll add the bare repository (on the remote server) to your local system as

    Make sure `bare-project.git` corresponds to the name of the bare repo you used in step 3.

    ## 6. Push to the remote server
    Now you can deploy the master branch to the remote server:
    ## 6. Deploy!
    Now you can push the master branch to the remote server:

    $ git push prod master

  2. nonbeing revised this gist Jun 17, 2019. 1 changed file with 3 additions and 4 deletions.
    7 changes: 3 additions & 4 deletions git-deployment.md
    Original file line number Diff line number Diff line change
    @@ -4,17 +4,16 @@ Also see: https://gist.github.com/lemiorhan/8912188

    Here are the simple steps needed to push your local git repository directly to a remote (e.g. prod) server over ssh. This is based on [Digital Ocean's Tutorial](https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks).

    ## How it works
    ## Overview

    You are developing in a working-directory on your local machine, let's say on the `master` branch. Usually people push code to a remote
    server like github.com or gitlab.com and pull or export it to a production server. Or you use GitHub's webhooks to send a POST request to a webserver to take appropriate actions such as cloning/checking out a branch on the remote (prod) server.

    But here, we can use a `bare` git repository on the production server and publish a branch of our choice (e.g. `master`) directly to that
    server. This remote repository on the server, acts upon the push event using a 'git hook' (in this case, the `post-receive` git hook) to put the files into a deployment directory on your server. No need for any intermediary such as GitHub.
    But here you could simply use a `bare` git repository on the production server and publish a branch of your choice (e.g. `master`) directly to that server. This remote repo on the server acts upon the push event using a 'git hook' (in this case, the `post-receive` git hook) to put the files into a deployment directory on your server. No need for any intermediary such as GitHub.

    This creates a scenario where there is no middle-man, high security with encrypted communication (using ssh keys, only authorized people get access to the server) and high flexibility from using a shell script (in the `post-receive` hook) for the deployment.

    # Prerequisites
    ## Prerequisites
    1. Know how to use GIT, ssh etc.
    2. Have a local working-directory ready to deploy, with AT LEAST 2 commits in the `git log`.
    2. Have SSH access to your server using private/public key
  3. nonbeing revised this gist Jun 17, 2019. 1 changed file with 16 additions and 1 deletion.
    17 changes: 16 additions & 1 deletion git-deployment.md
    Original file line number Diff line number Diff line change
    @@ -85,4 +85,19 @@ remote: Ref refs/heads/master received. Deploying master branch on server...
    remote: Already on 'master'
    To ssh://[email protected]:234/home/webuser/bare-project.git
    d2b8c82..ac8be14 master -> master
    ```
    ```

    ## 7. Roll-backs

    If you pushed a "bad" deployment to the remote server and need to roll it back, fret not! It's easy to roll-back to an earlier, "good" commit using a forced push:

    ```
    # on your local machine
    # assuming that HEAD~1 is the commit you want to roll-back to
    $ git reset --hard HEAD~1 # or git revert if you prefer that
    # force push to the remote server
    $ git push -f prod master
    ```

  4. nonbeing revised this gist Jun 17, 2019. 2 changed files with 87 additions and 64 deletions.
    120 changes: 67 additions & 53 deletions git-deployment.md
    Original file line number Diff line number Diff line change
    @@ -1,74 +1,88 @@
    # Simple automated GIT Deployment using GIT Hooks
    Also see: https://gist.github.com/lemiorhan/8912188

    Here are the simple steps needed to create a deployment from your lokal GIT repository to a server based on [this](https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks) in-depth
    tutorial.
    # Simple automated deployment using git hooks

    Here are the simple steps needed to push your local git repository directly to a remote (e.g. prod) server over ssh. This is based on [Digital Ocean's Tutorial](https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks).

    ## How it works

    You are developing in a working-copy on your local machine, lets say on the master branch. Most of the time, people would push code to a remote
    server like github.com or gitlab.com and pull or export it to a production server. Or you use a service like my [Deepl.io](https://deepl.io) to
    act upon a Web-Hook that's triggered that service.
    You are developing in a working-directory on your local machine, let's say on the `master` branch. Usually people push code to a remote
    server like github.com or gitlab.com and pull or export it to a production server. Or you use GitHub's webhooks to send a POST request to a webserver to take appropriate actions such as cloning/checking out a branch on the remote (prod) server.

    But here, we add a "bare" git repository that we create on the production server and pusblish our branch (f.e. master) directly to that
    server. This repository acts upon the push event using a 'git-hook' to move the files into a deployment directory on your server. No need for a midle man.
    But here, we can use a `bare` git repository on the production server and publish a branch of our choice (e.g. `master`) directly to that
    server. This remote repository on the server, acts upon the push event using a 'git hook' (in this case, the `post-receive` git hook) to put the files into a deployment directory on your server. No need for any intermediary such as GitHub.

    This creates a scenario where there is no middle man, high security with encrypted communication (using ssh keys, only authorized people get access to the server)
    and high flexibility tue to the use of .sh scripts for the deployment.
    This creates a scenario where there is no middle-man, high security with encrypted communication (using ssh keys, only authorized people get access to the server) and high flexibility from using a shell script (in the `post-receive` hook) for the deployment.

    # Prerequisit
    1. Know how to use GIT, Terminal etc.
    2. Have a local working-working copy ready
    # Prerequisites
    1. Know how to use GIT, ssh etc.
    2. Have a local working-directory ready to deploy, with AT LEAST 2 commits in the `git log`.
    2. Have SSH access to your server using private/public key

    # Todos
    1. Create a folder to deploy to on production server (i.e. your httpds folder)
    2. Add a bare repository on the productions server
    4. Add the post-receive hook script to the bare repository (and make it executable)
    5. Add the remote-repository resided on the production server to your local repository
    # TLDR: Procedure
    1. Create a directory on your remote (ssh) server to receive the deployment (e.g. `/var/www/html`)
    2. Add a bare git repository on the remote server
    4. Add the `post-receive` hook shell script to the bare repository, make it executable
    5. Add the remote-repository as a 'git remote' to your local git repository
    6. Push to the production server, relax.

    ## 1. Have a local working-working copy ready
    Nuf said. I asume we are working on master – but you could work on any branch.
    ## 1. Have a local working-directory ready to push
    Nuf said. I assume we are working on master – but you could work on any branch. Ensure there are at least 2 commits.

    ## 2. Create a directory for deployment on the remote server
    ssh into your remote (e.g. production) server.

    ## 2. Create a folder to deploy to
    ssh into your prodctionserver:
    We'll assume that your username is `webuser` on `server.com` and you access it (for "security-through-obscurity" reasons) over port 234 instead of the usual 22:

    $ ssh user@server.com
    $ mkdir ~/deploy-folder
    $ ssh webuser@server.com -p234
    $ mkdir ~/deploy-dir

    ## 3. Add a bare repository on the productions server
    Now we create a "bare" repository – one that does not contain the working copy files. It basicaly is the content of the .git repository folder in a normal working copy. Name it whatever you like, you can also ommit the .git part from project.git or leave it to create the repository in an exisiting empty folder:
    (Note: If you ssh in over the default ssh port of `22`, then you can also just use the regular `ssh [email protected]` instead of `ssh [email protected] -p22`, but let's assume you use port `234`)

    ## 3. Add a bare git repository on the remote server
    Now we'll create a "bare" git repository – one that does not contain any working copy files. It only has the contents of the `.git` directory in a normal working copy such as `refs`, `hooks`, `branches` etc. Call it whatever you like, but for our purposes, let's call it `bare-project.git`:

    $ git init --bare ~/project.git
    $ git init --bare ~/bare-project.git

    ## 4. Add the post-receive hook
    This scrtipt is executed when the push from the local machine has been completed and moves the files into place. It recides in project.git/hooks/ and is named 'post-receive'. You can use vim to edit and create it. The script does check if the correct branch is pushed (not deploying a develop branch for example) and

    #!/bin/bash
    while read oldrev newrev ref
    do
    # only checking out the master (or whatever branch you would like to deploy)
    if [[ $ref =~ .*/master$ ]];
    then
    echo "Master ref received. Deploying master branch to production..."
    git --work-tree=/home/webuser/deploy-folder/ --git-dir=/home/webuser/project.git/ checkout -f
    else
    echo "Ref $ref successfully received. Doing nothing: only the master branch may be deployed on this server."
    fi
    done

    Download [post-receive](#file-post-receive) for an improved version
    ## 5. Add remote-repository localy
    Now we add the this bare repository to your local system as a remote. Where "production" is the name you want to give the remote. This also be called "staging" or "live" or "test" etc if you want to deploy to a different system or multiple systems.
    ## 4. Add the post-receive hook into the bare git repo
    The `post-receive` hook is a shell script that is executed when the push from the local machine has been received. We will write this script so that it deploys the files into required deployment directory (`~/deploy-dir` in this example). The `post-receive` file is located at this path: `~/bare-project.git/hooks/post-receive`. It must be named exactly as **post-receive**. Normally, it is not present by default, so use a text editor such as `vim` to create and edit it.

    The script we will use does check if the correct branch is being pushed (it won't deploy a `develop` branch, e.g.)

    See the [post-receive](#file-post-receive) file for details.


    ## 5. Add a remote to your local git repo
    Now we'll add the bare repository (on the remote server) to your local system as a 'git remote'. For this example, `prod` is what we'll call this remote. This could also be called "staging" or "live" or "test" etc if you want to deploy to a different system or multiple systems.

    $ cd ~/path/to/working-copy/
    $ git remote add production [email protected]:project.git
    $ cd ~/path/to/working-copy/on-your-local-system/

    # assuming you ssh over port 234 instead of 22,
    # otherwise if you use the default port (22), you can just omit the `:234` part of the following url:
    $ git remote add prod ssh://[email protected]:234/home/webuser/bare-project.git

    Make sure "project.git" coresponds to the name you gave in step 3. If you are using Tower or a similar App, you will see the newly added remote in your sidebar under "Remotes" (make sure it's not collapsed).
    Make sure `bare-project.git` corresponds to the name of the bare repo you used in step 3.

    ## 6. Push to the production server
    Now you can push the master branch to the production server:
    ## 6. Push to the remote server
    Now you can deploy the master branch to the remote server:

    $ git push production master
    $ git push prod master

    If you are using tower, you can drag&drop the master branch onto the new production remote. That's it. Have questions, improvements?
    That's it.

    You should see something like:

    ```shell
    $ git push prod master

    Enumerating objects: 4, done.
    Counting objects: 100% (4/4), done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 948 bytes | 948.00 KiB/s, done.
    Total 3 (delta 0), reused 0 (delta 0)
    remote: Ref refs/heads/master received. Deploying master branch on server...
    remote: Already on 'master'
    To ssh://[email protected]:234/home/webuser/bare-project.git
    d2b8c82..ac8be14 master -> master
    ```
    31 changes: 20 additions & 11 deletions post-receive
    Original file line number Diff line number Diff line change
    @@ -1,16 +1,25 @@
    #!/bin/bash
    TRAGET="/home/webuser/deploy-folder"
    GIT_DIR="/home/webuser/www.git"

    #for debugging
    #set -ex

    # the work tree, where the checkout/deploy should happen
    TARGET="/home/webuser/deploy-dir"

    # the location of the .git directory
    GIT_DIR="/home/webuser/project.git"


    BRANCH="master"

    while read oldrev newrev ref
    do
    # only checking out the master (or whatever branch you would like to deploy)
    if [[ $ref = refs/heads/$BRANCH ]];
    then
    echo "Ref $ref received. Deploying ${BRANCH} branch to production..."
    git --work-tree=$TRAGET --git-dir=$GIT_DIR checkout -f
    else
    echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
    fi
    done
    # only checking out the master (or whatever branch you would like to deploy)
    if [ "$ref" = "refs/heads/$BRANCH" ];
    then
    echo "Ref $ref received. Deploying ${BRANCH} branch on server..."
    git --work-tree="${TARGET}" --git-dir="${GIT_DIR}" checkout -f ${BRANCH}
    else
    echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
    fi
    done
  5. @noelboss noelboss revised this gist Jun 23, 2016. 2 changed files with 6 additions and 8 deletions.
    2 changes: 1 addition & 1 deletion git-deployment.md
    Original file line number Diff line number Diff line change
    @@ -51,7 +51,7 @@ This scrtipt is executed when the push from the local machine has been completed
    if [[ $ref =~ .*/master$ ]];
    then
    echo "Master ref received. Deploying master branch to production..."
    git --work-tree=~/deploy-folder/ --git-dir=~/project.git/ checkout -f
    git --work-tree=/home/webuser/deploy-folder/ --git-dir=/home/webuser/project.git/ checkout -f
    else
    echo "Ref $ref successfully received. Doing nothing: only the master branch may be deployed on this server."
    fi
    12 changes: 5 additions & 7 deletions post-receive
    Original file line number Diff line number Diff line change
    @@ -1,17 +1,15 @@
    #!/bin/bash
    cd ~/
    PATH=$(pwd)
    REPO="$PATH/project.git"
    TRAGET="$PATH/deploy-folder"
    BRANCH="live"
    TRAGET="/home/webuser/deploy-folder"
    GIT_DIR="/home/webuser/www.git"
    BRANCH="master"

    while read oldrev newrev ref
    do
    # only checking out the master (or whatever branch you would like to deploy)
    if [[ $ref =~ .*/"${BRANCH}"$ ]];
    if [[ $ref = refs/heads/$BRANCH ]];
    then
    echo "Ref $ref received. Deploying ${BRANCH} branch to production..."
    git --work-tree=${TRAGET} --git-dir=${REPO} checkout -f
    git --work-tree=$TRAGET --git-dir=$GIT_DIR checkout -f
    else
    echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
    fi
  6. @noelboss noelboss revised this gist Jun 23, 2016. 1 changed file with 9 additions and 9 deletions.
    18 changes: 9 additions & 9 deletions post-receive
    Original file line number Diff line number Diff line change
    @@ -1,18 +1,18 @@
    #!/bin/bash
    BRANCH ="deploy/live"
    REPO ="~/www.git"
    TRAGET ="~/testdeploy"
    LOG ="~/logs/deploy-master.log"
    NOW =$(date +"%Y-%m-%d-%H:%M:%S")
    cd ~/
    PATH=$(pwd)
    REPO="$PATH/project.git"
    TRAGET="$PATH/deploy-folder"
    BRANCH="live"

    while read oldrev newrev ref
    do
    # only checking out the master (or whatever branch you would like to deploy)
    if [[ $ref =~ .*/"$BRANCH"$ ]];
    if [[ $ref =~ .*/"${BRANCH}"$ ]];
    then
    echo "Ref $ref received. Deploying $BRANCH branch to production..."
    git --work-tree=$TRAGET --git-dir=$REPO checkout -f
    echo "Ref $ref received. Deploying ${BRANCH} branch to production..."
    git --work-tree=${TRAGET} --git-dir=${REPO} checkout -f
    else
    echo "Ref $ref successfully received. Doing nothing: only the $BRANCH branch may be deployed on this server."
    echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
    fi
    done
  7. @noelboss noelboss revised this gist Jun 23, 2016. 1 changed file with 11 additions and 11 deletions.
    22 changes: 11 additions & 11 deletions post-receive
    Original file line number Diff line number Diff line change
    @@ -1,18 +1,18 @@
    #!/bin/bash
    BRANCH ="master"
    REPO ="~/project.git"
    TRAGET ="~/deploy-folder"
    BRANCH ="deploy/live"
    REPO ="~/www.git"
    TRAGET ="~/testdeploy"
    LOG ="~/logs/deploy-master.log"
    NOW =$(date +"%Y-%m-%d-%H:%M:%S")

    while read oldrev newrev ref
    do
    # only checking out the master (or whatever branch you would like to deploy)
    if [[ $ref =~ .*/${BRANCH}$ ]];
    then
    echo "Ref ${ref} received. Deploying ${BRANCH} branch to production..."
    git --work-tree=$TRAGET --git-dir=$REPO checkout -f
    else
    echo "Ref $ref successfully received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
    fi
    # only checking out the master (or whatever branch you would like to deploy)
    if [[ $ref =~ .*/"$BRANCH"$ ]];
    then
    echo "Ref $ref received. Deploying $BRANCH branch to production..."
    git --work-tree=$TRAGET --git-dir=$REPO checkout -f
    else
    echo "Ref $ref successfully received. Doing nothing: only the $BRANCH branch may be deployed on this server."
    fi
    done
  8. @noelboss noelboss revised this gist Jun 23, 2016. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion git-deployment.md
    Original file line number Diff line number Diff line change
    @@ -57,7 +57,7 @@ This scrtipt is executed when the push from the local machine has been completed
    fi
    done

    Download [post-receive](post-receive) for an improved version
    Download [post-receive](#file-post-receive) for an improved version
    ## 5. Add remote-repository localy
    Now we add the this bare repository to your local system as a remote. Where "production" is the name you want to give the remote. This also be called "staging" or "live" or "test" etc if you want to deploy to a different system or multiple systems.

  9. @noelboss noelboss revised this gist Jun 23, 2016. 2 changed files with 19 additions and 0 deletions.
    1 change: 1 addition & 0 deletions git-deployment.md
    Original file line number Diff line number Diff line change
    @@ -57,6 +57,7 @@ This scrtipt is executed when the push from the local machine has been completed
    fi
    done

    Download [post-receive](post-receive) for an improved version
    ## 5. Add remote-repository localy
    Now we add the this bare repository to your local system as a remote. Where "production" is the name you want to give the remote. This also be called "staging" or "live" or "test" etc if you want to deploy to a different system or multiple systems.

    18 changes: 18 additions & 0 deletions post-receive
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,18 @@
    #!/bin/bash
    BRANCH ="master"
    REPO ="~/project.git"
    TRAGET ="~/deploy-folder"
    LOG ="~/logs/deploy-master.log"
    NOW =$(date +"%Y-%m-%d-%H:%M:%S")

    while read oldrev newrev ref
    do
    # only checking out the master (or whatever branch you would like to deploy)
    if [[ $ref =~ .*/${BRANCH}$ ]];
    then
    echo "Ref ${ref} received. Deploying ${BRANCH} branch to production..."
    git --work-tree=$TRAGET --git-dir=$REPO checkout -f
    else
    echo "Ref $ref successfully received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
    fi
    done
  10. @noelboss noelboss revised this gist Jun 23, 2016. 1 changed file with 21 additions and 21 deletions.
    42 changes: 21 additions & 21 deletions git-deployment.md
    Original file line number Diff line number Diff line change
    @@ -33,41 +33,41 @@ Nuf said. I asume we are working on master – but you could work on any branch.
    ## 2. Create a folder to deploy to
    ssh into your prodctionserver:

    $ ssh [email protected]
    $ mkdir ~/deploy-folder

    $ ssh [email protected]
    $ mkdir ~/deploy-folder
    ## 3. Add a bare repository on the productions server
    Now we create a "bare" repository – one that does not contain the working copy files. It basicaly is the content of the .git repository folder in a normal working copy. Name it whatever you like, you can also ommit the .git part from project.git or leave it to create the repository in an exisiting empty folder:

    $ git init --bare ~/project.git
    $ git init --bare ~/project.git

    ## 4. Add the post-receive hook
    This scrtipt is executed when the push from the local machine has been completed and moves the files into place. It recides in project.git/hooks/ and is named 'post-receive'. You can use vim to edit and create it. The script does check if the correct branch is pushed (not deploying a develop branch for example) and

    #!/bin/bash
    while read oldrev newrev ref
    do
    # only checking out the master (or whatever branch you would like to deploy)
    if [[ $ref =~ .*/master$ ]];
    then
    echo "Master ref received. Deploying master branch to production..."
    git --work-tree=~/deploy-folder/ --git-dir=~/project.git/ checkout -f
    else
    echo "Ref $ref successfully received. Doing nothing: only the master branch may be deployed on this server."
    fi
    done
    #!/bin/bash
    while read oldrev newrev ref
    do
    # only checking out the master (or whatever branch you would like to deploy)
    if [[ $ref =~ .*/master$ ]];
    then
    echo "Master ref received. Deploying master branch to production..."
    git --work-tree=~/deploy-folder/ --git-dir=~/project.git/ checkout -f
    else
    echo "Ref $ref successfully received. Doing nothing: only the master branch may be deployed on this server."
    fi
    done

    ## 5. Add remote-repository localy
    Now we add the this bare repository to your local system as a remote. Where "production" is the name you want to give the remote. This also be called "staging" or "live" or "test" etc if you want to deploy to a different system or multiple systems.

    $ cd ~/path/to/working-copy/
    $ git remote add production [email protected]:project.git

    $ cd ~/path/to/working-copy/
    $ git remote add production [email protected]:project.git
    Make sure "project.git" coresponds to the name you gave in step 3. If you are using Tower or a similar App, you will see the newly added remote in your sidebar under "Remotes" (make sure it's not collapsed).

    ## 6. Push to the production server
    Now you can push the master branch to the production server:

    $ git push production master
    $ git push production master

    If you are using tower, you can drag&drop the master branch onto the new production remote. That's it. Have questions, improvements?
  11. @noelboss noelboss revised this gist Jun 23, 2016. No changes.
  12. @noelboss noelboss revised this gist Jun 23, 2016. No changes.
  13. @noelboss noelboss revised this gist Jun 23, 2016. 1 changed file with 39 additions and 5 deletions.
    44 changes: 39 additions & 5 deletions git-deployment.md
    Original file line number Diff line number Diff line change
    @@ -16,9 +16,9 @@ This creates a scenario where there is no middle man, high security with encrypt
    and high flexibility tue to the use of .sh scripts for the deployment.

    # Prerequisit
    1. Have a local working-working copy ready
    2. Have SSH Access to your server
    3. Optonaly configure your server for access with ssh-key (google it)
    1. Know how to use GIT, Terminal etc.
    2. Have a local working-working copy ready
    2. Have SSH access to your server using private/public key

    # Todos
    1. Create a folder to deploy to on production server (i.e. your httpds folder)
    @@ -34,6 +34,40 @@ Nuf said. I asume we are working on master – but you could work on any branch.
    ssh into your prodctionserver:

    $ ssh [email protected]
    $ mkdir deploy
    $ mkdir ~/deploy-folder


    ## 3. Add a bare repository on the productions server
    Now we create a "bare" repository – one that does not contain the working copy files. It basicaly is the content of the .git repository folder in a normal working copy. Name it whatever you like, you can also ommit the .git part from project.git or leave it to create the repository in an exisiting empty folder:

    $ git init --bare ~/project.git

    ## 4. Add the post-receive hook
    This scrtipt is executed when the push from the local machine has been completed and moves the files into place. It recides in project.git/hooks/ and is named 'post-receive'. You can use vim to edit and create it. The script does check if the correct branch is pushed (not deploying a develop branch for example) and

    #!/bin/bash
    while read oldrev newrev ref
    do
    # only checking out the master (or whatever branch you would like to deploy)
    if [[ $ref =~ .*/master$ ]];
    then
    echo "Master ref received. Deploying master branch to production..."
    git --work-tree=~/deploy-folder/ --git-dir=~/project.git/ checkout -f
    else
    echo "Ref $ref successfully received. Doing nothing: only the master branch may be deployed on this server."
    fi
    done

    ## 5. Add remote-repository localy
    Now we add the this bare repository to your local system as a remote. Where "production" is the name you want to give the remote. This also be called "staging" or "live" or "test" etc if you want to deploy to a different system or multiple systems.

    $ cd ~/path/to/working-copy/
    $ git remote add production [email protected]:project.git

    Make sure "project.git" coresponds to the name you gave in step 3. If you are using Tower or a similar App, you will see the newly added remote in your sidebar under "Remotes" (make sure it's not collapsed).

    ## 6. Push to the production server
    Now you can push the master branch to the production server:

    $ git push production master

    If you are using tower, you can drag&drop the master branch onto the new production remote. That's it. Have questions, improvements?
  14. @noelboss noelboss revised this gist Jun 23, 2016. 1 changed file with 20 additions and 1 deletion.
    21 changes: 20 additions & 1 deletion git-deployment.md
    Original file line number Diff line number Diff line change
    @@ -15,6 +15,25 @@ server. This repository acts upon the push event using a 'git-hook' to move the
    This creates a scenario where there is no middle man, high security with encrypted communication (using ssh keys, only authorized people get access to the server)
    and high flexibility tue to the use of .sh scripts for the deployment.

    # Todos
    # Prerequisit
    1. Have a local working-working copy ready
    2. Have SSH Access to your server
    3. Optonaly configure your server for access with ssh-key (google it)

    # Todos
    1. Create a folder to deploy to on production server (i.e. your httpds folder)
    2. Add a bare repository on the productions server
    4. Add the post-receive hook script to the bare repository (and make it executable)
    5. Add the remote-repository resided on the production server to your local repository
    6. Push to the production server, relax.

    ## 1. Have a local working-working copy ready
    Nuf said. I asume we are working on master – but you could work on any branch.

    ## 2. Create a folder to deploy to
    ssh into your prodctionserver:

    $ ssh [email protected]
    $ mkdir deploy


  15. @noelboss noelboss created this gist Jun 23, 2016.
    20 changes: 20 additions & 0 deletions git-deployment.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,20 @@
    # Simple automated GIT Deployment using GIT Hooks

    Here are the simple steps needed to create a deployment from your lokal GIT repository to a server based on [this](https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks) in-depth
    tutorial.

    ## How it works

    You are developing in a working-copy on your local machine, lets say on the master branch. Most of the time, people would push code to a remote
    server like github.com or gitlab.com and pull or export it to a production server. Or you use a service like my [Deepl.io](https://deepl.io) to
    act upon a Web-Hook that's triggered that service.

    But here, we add a "bare" git repository that we create on the production server and pusblish our branch (f.e. master) directly to that
    server. This repository acts upon the push event using a 'git-hook' to move the files into a deployment directory on your server. No need for a midle man.

    This creates a scenario where there is no middle man, high security with encrypted communication (using ssh keys, only authorized people get access to the server)
    and high flexibility tue to the use of .sh scripts for the deployment.

    # Todos
    1. Have a local working-working copy ready
    2. Add a bare repository on the productions server