Развертывание проекта с помощью Git push

Я делаю это так, что у меня есть пустой репозиторий Git на моем сервере развертывания, куда я отправляю изменения. Затем я вхожу на сервер развертывания, перехожу в каталог документации веб-сервера и выполняю git pull. Я не использую никаких ловушек, чтобы попытаться сделать это автоматически, это кажется больше проблемой, чем того стоит.

Похоже, у вас на сервере должно быть две копии. Пустая копия, которую вы можете нажимать / извлекать, из которой вы будете отправлять свои изменения, когда вы закончите, а затем вы должны клонировать ее в свой веб-каталог и настроить cronjob для обновления git pull из вашего веб-каталога каждый день или так.

Вы могли бы настроить ловушку git, которая, когда, скажем, совершается фиксация, называя «стабильную» ветвь, она извлекает изменения и применяет их к сайту PHP. Большой недостаток заключается в том, что у вас не будет особого контроля, если что-то пойдет не так, и это увеличит время вашего тестирования - но вы можете получить представление о том, сколько работы потребуется, когда вы объедините, скажем, ваша магистральная ветка в стабильную ветку, чтобы знать сколько конфликтов у вас май. Важно следить за любыми файлами, относящимися к конкретному сайту (например, файлами конфигурации), если только вы не собираетесь запускать только один сайт.

В качестве альтернативы, вы пытались вместо этого разместить изменение на сайте?

Для получения информации о хуках git см. Документацию githooks.

Я нашел этот сценарий на этот сайт, и, похоже, он работает довольно хорошо.

1. Скопируйте каталог .git на свой веб-сервер

2. В локальной копии измените файл .git / config и добавьте свой веб-сервер в качестве удаленного:

   [remote "production"]
       url = username@webserver:/path/to/htdocs/.git
   

3. На сервере замените .git / hooks / post-update на этот файл (в ответе ниже)

4. Добавляем доступ на выполнение к файлу (опять же, на сервере):

   chmod +x .git/hooks/post-update
   

5. Теперь просто отправьте локально на свой веб-сервер, и он должен автоматически обновить рабочую копию:

   git push production
   

По сути, все, что вам нужно сделать, это следующее:

server = $1
branch = $2
git push $server $branch
ssh <username>@$server "cd /path/to/www; git pull"

У меня есть эти строки в моем приложении как исполняемый файл под названием deploy.

поэтому, когда я хочу выполнить развертывание, я набираю ./deploy myserver mybranch.

Используя файл пост-обновление ниже:

1. Скопируйте каталог .git на свой веб-сервер

2. В локальной копии измените файл .git / config и добавьте свой веб-сервер в качестве удаленного:

   [remote "production"]
       url = username@webserver:/path/to/htdocs/.git
   

3. На сервере замените .git / hooks / post-update файлом ниже

4. Добавляем доступ на выполнение к файлу (опять же, на сервере):

   chmod +x .git/hooks/post-update
   

5. Теперь просто отправьте локально на свой веб-сервер, и он должен автоматически обновить рабочую копию:

   git push production
   

#!/bin/sh
#
# This hook does two things:
#
#  1. update the "info" files that allow the list of references to be
#     queries over dumb transports such as http
#
#  2. if this repository looks like it is a non-bare repository, and
#     the checked-out branch is pushed to, then update the working copy.
#     This makes "push" function somewhat similarly to darcs and bzr.
#
# To enable this hook, make this file executable by "chmod +x post-update". 
git-update-server-info 
is_bare=$(git-config --get --bool core.bare) 
if [ -z "$is_bare" ]
then
      # for compatibility's sake, guess
      git_dir_full=$(cd $GIT_DIR; pwd)
      case $git_dir_full in */.git) is_bare=false;; *) is_bare=true;; esac
fi 
update_wc() {
      ref=$1
      echo "Push to checked out branch $ref" >&2
      if [ ! -f $GIT_DIR/logs/HEAD ]
      then
             echo "E:push to non-bare repository requires a HEAD reflog" >&2
             exit 1
      fi
      if (cd $GIT_WORK_TREE; git-diff-files -q --exit-code >/dev/null)
      then
             wc_dirty=0
      else
             echo "W:unstaged changes found in working copy" >&2
             wc_dirty=1
             desc = "working copy"
      fi
      if git diff-index --cached HEAD@{1} >/dev/null
      then
             index_dirty=0
      else
             echo "W:uncommitted, staged changes found" >&2
             index_dirty=1
             if [ -n "$desc" ]
             then
                   desc = "$desc and index"
             else
                   desc = "index"
             fi
      fi
      if [ "$wc_dirty" -ne 0 -o "$index_dirty" -ne 0 ]
      then
             new=$(git rev-parse HEAD)
             echo "W:stashing dirty $desc - see git-stash(1)" >&2
             ( trap 'echo trapped $$; git symbolic-ref HEAD "'"$ref"'"' 2 3 13 15 ERR EXIT
             git-update-ref --no-deref HEAD HEAD@{1}
             cd $GIT_WORK_TREE
             git stash save "dirty $desc before update to $new";
             git-symbolic-ref HEAD "$ref"
             )
      fi 
      # eye candy - show the WC updates :)
      echo "Updating working copy" >&2
      (cd $GIT_WORK_TREE
      git-diff-index -R --name-status HEAD >&2
      git-reset --hard HEAD)
} 
if [ "$is_bare" = "false" ]
then
      active_branch=`git-symbolic-ref HEAD`
      export GIT_DIR=$(cd $GIT_DIR; pwd)
      GIT_WORK_TREE=${GIT_WORK_TREE-..}
      for ref
      do
             if [ "$ref" = "$active_branch" ]
             then
                   update_wc $ref
             fi
      done
fi

После множества неудачных запусков и тупиков я наконец смог развернуть код веб-сайта с помощью всего лишь «git push удаленный» благодаря эта статья.

Сценарий автора после обновления состоит всего из одной строки, и его решение не требует конфигурации .htaccess, чтобы скрыть репозиторий Git, как это делают некоторые другие.

Пара камней преткновения, если вы развертываете это на инстансе Amazon EC2;

1) Если вы используете sudo для создания чистого целевого репозитория, вам нужно изменить владельца репо на пользователя ec2, иначе push не удастся. (Попробуйте "chown ec2-user: ec2-user репо.")

2) Push не удастся, если вы не настроите заранее расположение вашего amazon-приватный ключ.pem, либо в / etc / ssh / ssh_config в качестве параметра IdentityFile, либо в ~ / .ssh / config с использованием параметра «[Host] - HostName - IdentityFile - User »описание макета здесь ...

... ОДНАКО, если Host настроен в ~ / .ssh / config и отличается от HostName, Git push завершится ошибкой. (Вероятно, это ошибка Git)

не устанавливайте git на сервер и не копируйте туда папку .git. чтобы обновить сервер из клона git, вы можете использовать следующую команду:

git ls-files -z | rsync --files-from - --copy-links -av0 . [email protected]:/var/www/project

возможно, вам придется удалить файлы, которые были удалены из проекта.

это копирует все зарегистрированные файлы. rsync использует ssh, который в любом случае установлен на сервере.

чем меньше программного обеспечения вы установили на сервере, тем он безопаснее и тем проще управлять его конфигурацией и документировать ее. также нет необходимости хранить полный клон git на сервере. это только усложняет защиту всего должным образом.

Учитывая среду, в которой несколько разработчиков имеют доступ к одному и тому же репозиторию, следующие рекомендации могут помочь.

Убедитесь, что у вас есть группа unix, к которой принадлежат все разработчики, и передайте ей право собственности на репозиторий .git.

1. В .git / config репозитория сервера установите sharedrepository = true. (Это говорит git о разрешении нескольких пользователей, что необходимо для коммитов и развертывания.

2. установите одинаковую umask для каждого пользователя в их файлах bashrc - 002 - хорошее начало

Легкомысленный до - это не зависящие от языка хуки просто добавь воды git для автоматизации развертывания с помощью git push. Он также позволяет настраивать хуки запуска / остановки для перезапуска веб-сервера, разогрева кеша и т. д.

https://github.com/mpalmer/giddyup

Проверьте Примеры.

Обновление: сейчас я использую решение Ллойд Мур с ключевым агентом ssh -A .... Направление в основное репо и затем параллельное извлечение из него со всех ваших машин немного быстрее и требует меньше настроек на этих машинах.

Не вижу здесь этого решения. просто нажмите через ssh, если на сервере установлен git.

Вам понадобится следующая запись в вашем локальном .git / config

[remote "amazon"]
    url = amazon:/path/to/project.git
    fetch = +refs/heads/*:refs/remotes/amazon/*

Но что там с amazon:? В вашем локальном ~ / .ssh / config вам нужно будет добавить следующую запись:

Host amazon
    Hostname <YOUR_IP>
    User <USER>
    IdentityFile ~/.ssh/amazon-private-key

теперь ты можешь вызвать

git push amazon master
ssh <USER>@<YOUR_IP> 'cd /path/to/project && git pull'

(Кстати: /path/to/project.git отличается от фактического рабочего каталога / пути / к / проекту)

Я закончил тем, что создал свой собственный элементарный инструмент развертывания, который автоматически извлекал бы новые обновления из репозитория - https://github.com/jesalg/SlimJim - в основном он слушает github post-receive-hook и использует прокси для запуска скрипта обновления.

Мы используем капистрано для управления развертыванием. Мы создаем capistrano для развертывания на промежуточном сервере, а затем запускаем rsync со всем нашим сервером.

cap deploy
cap deploy:start_rsync (when the staging is ok)

С capistrano мы можем легко откатиться в случае ошибки

cap deploy:rollback
cap deploy:start_rsync

Мой взгляд на решение Христиане.

git archive --prefix=deploy/  master | tar -x -C $TMPDIR | rsync $TMPDIR/deploy/ --copy-links -av [email protected]:/home/user/my_app && rm -rf $TMPDIR/deploy

• Архивирует основную ветку в tar
• Извлекает tar-архив в каталог развертывания в системной временной папке.
• rsync превращается в сервер
• удалить каталог развертывания из временной папки.

Я использую следующее решение от toroid.org, которое имеет более простой скрипт перехвата.

на сервере:

$ mkdir website.git && cd website.git
$ git init --bare
Initialized empty Git repository in /home/ams/website.git/

и устанавливаем ловушку на сервер:

$ mkdir /var/www/www.example.org
$ cat > hooks/post-receive
#!/bin/sh
GIT_WORK_TREE=/var/www/www.example.org git checkout -f
GIT_WORK_TREE=/var/www/www git clean -f -d # clean directory from removed files

$ chmod +x hooks/post-receive

на вашем клиенте:

$ mkdir website && cd website
$ git init
Initialized empty Git repository in /home/ams/website/.git/
$ echo 'Hello, world!' > index.html
$ git add index.html
$ git commit -q -m "The humble beginnings of my web site."

$ git remote add web ssh://server.example.org/home/ams/website.git
$ git push web +master:refs/heads/master

затем, чтобы опубликовать, просто введите

$ git push web

На сайте есть полное описание: http://toroid.org/ams/git-website-howto

git config --local receive.denyCurrentBranch updateInstead

Добавлено в Git 2.3, это может быть хорошей возможностью: https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

Вы устанавливаете его в репозитории сервера, и он также обновляет рабочее дерево, если оно чистое.

В 2.4 были внесены дальнейшие улучшения с Крюк push-to-checkout и обработка нерожденных веток.

Пример использования:

git init server
cd server
touch a
git add .
git commit -m 0
git config --local receive.denyCurrentBranch updateInstead

cd ..
git clone server local
cd local
touch b
git add .
git commit -m 1
git push origin master:master

cd ../server
ls

Выход:

a
b

У этого есть следующие недостатки, упомянутые в анонсе GitHub:

• На вашем сервере будет каталог .git, содержащий всю историю вашего проекта. Вероятно, вы захотите дополнительно убедиться, что он не может быть доставлен пользователям!
• Во время развертывания пользователи могут на мгновение обнаружить сайт в несогласованном состоянии, с некоторыми файлами в старой версии, а другими в новой версии или даже с наполовину записанными файлами. Если это проблема для вашего проекта, push-to-deploy, вероятно, не для вас.
• Если вашему проекту нужен этап «сборки», вам нужно будет настроить его явно, возможно, через githooks.

Но все эти моменты выходят за рамки Git, и о них нужно позаботиться с помощью внешнего кода. В этом смысле это вместе с хуками Git является окончательным решением.

В качестве дополнительного ответа я хотел бы предложить альтернативу. Я использую git-ftp, и он отлично работает.

https://github.com/git-ftp/git-ftp

Простота использования, введите только:

git ftp push

и git автоматически загрузит файлы проекта.

С уважением

Для сценария развертывания

В нашем сценарии мы храним код на github / bitbucket и хотим развернуть его на действующих серверах. В этом случае у нас работает следующая комбинация (это ремикс на высоко оцененные ответы здесь):

1. Скопируйте каталог .git на свой веб-сервер
2. На вашей локальной копии git remote add live ssh://user@host:port/folder
3. На пульте: git config receive.denyCurrentBranch ignore

4. На удаленном: nano .git/hooks/post-receive и добавьте это содержимое:

   #!/bin/sh GIT_WORK_TREE=/var/www/vhosts/example.org git checkout -f

5. На пульте: chmod +x .git/hooks/post-receive

6. Теперь можно туда пихать с git push live

Ноты

• Это решение работает со старыми версиями git (протестировано с 1.7 и 1.9)
• Вам нужно сначала нажать на github / bitbucket, чтобы у вас было последовательное репо в реальном времени.

• Если ваша папка .git находится в корне документа, убедитесь, что вы скрыли ее извне, добавив в .htaccess (источник):

  RedirectMatch 404 /\..*$

Я использую два решения для крючка после получения:

РАЗВЕРТЫВАНИЕ РЕШЕНИЯ 1

#!/bin/bash 
#  /git-repo/hooks/post-receive - file content on server (chmod as 755 to be executed)
# DEPLOY SOLUTION 1 

    export GIT_DIR=/git/repo-bare.git
    export GIT_BRANCH1=master
    export GIT_TARGET1=/var/www/html
    export GIT_BRANCH2=dev
    export GIT_TARGET2=/var/www/dev
    echo "GIT DIR:  $GIT_DIR/"
    echo "GIT TARGET1:  $GIT_TARGET1/"
    echo "GIT BRANCH1:  $GIT_BRANCH1/"
    echo "GIT TARGET2:  $GIT_TARGET2/"
    echo "GIT BRANCH2:  $GIT_BRANCH2/"
    echo ""

    cd $GIT_DIR/

while read oldrev newrev refname
do
    branch=$(git rev-parse --abbrev-ref $refname)
    BRANCH_REGEX='^${GIT_BRANCH1}.*$'
    if [[ $branch =~ $BRANCH_REGEX ]] ; then
        export GIT_WORK_TREE=$GIT_TARGET1/.
        echo "Checking out branch: $branch";
        echo "Checking out to workdir: $GIT_WORK_TREE"; 

        git checkout -f $branch
    fi

    BRANCH_REGEX='^${GIT_BRANCH2}.*$'
    if [[ $branch =~ $BRANCH_REGEX ]] ; then
        export GIT_WORK_TREE=$GIT_TARGET2/.
        echo "Checking out branch: $branch";
        echo "Checking out to workdir: $GIT_WORK_TREE"; 

        git checkout -f $branch
    fi
done

РАЗВЕРТЫВАНИЕ РЕШЕНИЯ 2

#!/bin/bash 
#  /git-repo/hooks/post-receive - file content on server (chmod as 755 to be executed)
# DEPLOY SOLUTION 2

    export GIT_DIR=/git/repo-bare.git
    export GIT_BRANCH1=master
    export GIT_TARGET1=/var/www/html
    export GIT_BRANCH2=dev
    export GIT_TARGET2=/var/www/dev
    export GIT_TEMP_DIR1=/tmp/deploy1
    export GIT_TEMP_DIR2=/tmp/deploy2
    echo "GIT DIR:  $GIT_DIR/"
    echo "GIT TARGET1:  $GIT_TARGET1/"
    echo "GIT BRANCH1:  $GIT_BRANCH1/"
    echo "GIT TARGET2:  $GIT_TARGET2/"
    echo "GIT BRANCH2:  $GIT_BRANCH2/"
    echo "GIT TEMP DIR1:  $GIT_TEMP_DIR1/"
    echo "GIT TEMP DIR2:  $GIT_TEMP_DIR2/"
    echo ""

    cd $GIT_DIR/

while read oldrev newrev refname
do
    branch=$(git rev-parse --abbrev-ref $refname)
    BRANCH_REGEX='^${GIT_BRANCH1}.*$'
    if [[ $branch =~ $BRANCH_REGEX ]] ; then
        export GIT_WORK_TREE=$GIT_TARGET1/.
        echo "Checking out branch: $branch";
        echo "Checking out to workdir: $GIT_WORK_TREE"; 

        # DEPLOY SOLUTION 2: 
        cd $GIT_DIR/; mkdir -p $GIT_TEMP_DIR1; 
        export GIT_WORK_TREE=$GIT_TEMP_DIR1/.
        git checkout -f $branch
        export GIT_WORK_TREE=$GIT_TARGET1/.
        rsync $GIT_TEMP_DIR1/. -v -q --delete --delete-after -av $GIT_TARGET1/.
        rm -rf $GIT_TEMP_DIR1
    fi

    BRANCH_REGEX='^${GIT_BRANCH2}.*$'
    if [[ $branch =~ $BRANCH_REGEX ]] ; then
        export GIT_WORK_TREE=$GIT_TARGET2/.
        echo "Checking out branch: $branch";
        echo "Checking out to workdir: $GIT_WORK_TREE"; 

        # DEPLOY SOLUTION 2: 
        cd $GIT_DIR/; mkdir -p $GIT_TEMP_DIR2; 
        export GIT_WORK_TREE=$GIT_TEMP_DIR2/.
        git checkout -f $branch
        export GIT_WORK_TREE=$GIT_TARGET2/.
        rsync $GIT_TEMP_DIR2/. -v -q --delete --delete-after -av $GIT_TARGET2/.
        rm -rf $GIT_TEMP_DIR2
    fi
done

Оба решения основаны на более ранних решениях, доступных в этом потоке.

Обратите внимание BRANCH_REGEX = '^ $ {GIT_BRANCH1} .$ ' фильтры для названий веток, соответствующих "master" "или строка" dev * "и развертывает дерево работ, если отправленная ветвь совпадает. Это позволяет развернуть версию разработчика и основную версию в разных местах.

РАЗВЕРНУТЬ РЕШЕНИЕ 1 удаляет только файлы, которые являются частью репо и были удалены фиксацией. Это быстрее, чем Deployment Solution 2.

DEPLOY SOLUTION 2 имеет то преимущество, что он удалит любые новые файлы из производственного каталога, который был добавлен на стороне сервера, независимо от того, был ли он добавлен в репо или нет. Это всегда будет чистый обман репо. Это медленнее, чем решение для развертывания 1.