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


412

Можно ли развернуть сайт с помощью git push? У меня есть предчувствие, что это как-то связано с использованием git-хуков для выполнения git reset --hardна стороне сервера, но как мне это сделать?


2
Я предполагаю, что это применимо только в ситуациях, когда есть только один производственный сервер, верно?
— Рейк

6
@Rijk Ну, вы можете использовать несколько серверов одновременно с помощью Git, но как только вы достигнете этого уровня, вы можете захотеть найти реальное решение, а не взломать, как этот.
— Кайл Кронин

Я успешно использовал capistrano в своих проектах, хотя изначально он был разработан для развертывания приложений Ruby on Rails, но он хорошо работает с PHP и другими проектами.

Переводы ответов на русский язык на ru.so: ru.stackoverflow.com/questions/428483/…
— Ник Волынкин

Ответы:


287

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

  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
    

128
Убедитесь, что у вас есть политика .htaccess, которая защищает каталог .git от чтения. У кого-то, кто чувствует себя, как URL-дайвинг, может быть день поля со всем исходным кодом, если он доступен.
— Джефф Ферланд

39
В качестве альтернативы просто сделайте публичный каталог подкаталогом git repo. Тогда вы можете иметь личные файлы, которые вы можете быть уверены, что не будут обнародованы.
— tlrobinson

3
эта ссылка мертва есть ли другая ссылка на файл после обновления?
— Роберт Херст

6
Может быть , я что - то отсутствует , но не вы хотите , чтобы ваша продукция сервер (ы) , чтобы вытащить из мастер мерзавца хранилищами producttion отрасли. Я полагаю, что у ОП есть только один сервер? Я обычно заставляю свой сервер непрерывной интеграции выполнять развертывание моего сайта (выполняя некоторые тесты перед развертыванием).
— Адам Гент

4
После этих шагов из репозитория, который уже имеет последовательность коммитов; сначала вы не можете нажать, потому что основная ветвь уже извлечена. Затем, если вы извлекаете альтернативную ветку на пульте, в рабочий каталог извлекаются только разные файлы. Я ожидал, что хук сделает сброс - тяжело для меня
— barrymac

80

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

  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

5
Боже ... просто напишите этот скрипт на языке, который вы используете для разработки, будь то php, python, groovy или что-то еще! Я никогда не понимал эту любовь к сценариям оболочки, которые имеют (субъективно) довольно странный синтаксис и так мало функциональных особенностей.
— dVaffection

4
@dVaffection в любом случае вы собираетесь писать команды оболочки, если вы используете git. так что вместо написания сценария на другом языке постоянно жонглируйте между этим языком и оболочкой. писать все это в оболочке кажется логичным, не правда ли?
— Абдеррахман ТАХРИ ДЖОУТИ

Мне также пришлось выполнить «git config receive.denyCurrentBranch updateInstead» на сервере, чтобы он мог принять push. Я думаю, потому что ветка была проверена?
— stackPusher

60

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

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

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

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

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

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


Я следовал за шагами в статье, которую вы упомянули, и все работало как шарм. Я только удивляюсь, есть ли некоторые недостатки, касающиеся безопасности или стабильности. Любой совет по этому поводу?
— xlttj

XLT: Предполагая, что вы используете Git вместо SSH, я бы сказал, что опасность заключается в том, чтобы ошибиться с Git. Вы можете спросить у автора статьи; он заканчивает это словами «Вопросы и предложения приветствуются». Моя текущая (безмозглая) стратегия репликации заключается в использовании Transmit by Panic Software.
— Эрл Зедд

1
Связанная статья имеет одно важное требование при использовании хуков. Перехватчики потерпят неудачу, если .git окажется в той же схеме именования, что и рабочий каталог. т.е. / foo / bar (рабочий каталог) и /foo/bar.git (barebone-репозиторий git). Поэтому убедитесь, что вы переименовали / foo / bar во что-то другое, например, /foo/bar.live или / foo / blah. Ну, если вам интересно, точное сообщение об ошибке вы получите, если ваш рабочий каталог имеет то же имя, что и репозиторий barebone является «удаленным: fatal: не удалось перейти обратно к исходному cwd: нет такого файла или каталога»
— Antony

1
Я не понимаю, зачем вам нужен хук после развертывания. Нажатие изменения кода на удаленном репо означает, что удаленное репо обновлено. Что мне не хватает?
— Чарли Шлиссер

1
@CharlieS, чего вам не хватает, так это того, что git не позволит вам выдвинуть ветку в репозиторий, в котором эта ветка проверена. В этом случае (IMHO очень хороший) ответ состоит в том, чтобы иметь два репозитория: пустое хранилище, на которое вы нажимаете, и второе хранилище, рабочий каталог которого обновляется через ловушку, когда на пустое хранилище помещается.
— Бен Хьюз

21

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

git ls-files -z | rsync --files-from - --copy-links -av0 . user@server.com:/var/www/project

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

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

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


3
Одно предупреждение: он rsync файлы, которые у вас есть в вашем рабочем каталоге. Я думаю, что этого можно избежать, используя скрипт, который хранит текущие изменения, очищает все, развертывает и затем восстанавливает тайник.
— mateusz.fiolka

Серверы мужские?
— Ян

12

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

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

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

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


см. мой ответ, как решить проблему, если вам нужен другой закрытый ключ или имя пользователя для ssh
— Karussell

Это решение быстрее моего при развертывании на нескольких серверах! Просто нажмите на основной репо и потяните параллельно с ним. А если вы не хотите или не можете развернуть ключи в каждом экземпляре, используйте агент ключей! ssh -A ...
— Карусселл

1
Было бы проще, если бы вы включили руководство по настройке ключей SSH, от которого зависит этот ответ, чтобы работать «без проблем»
— Hengjie

Использование git pullследует избегать автоматического развертывания , поскольку слияние часть может потребовать ручной очистки , если есть какие - либо конфликты.
— Куинн Комендант

9

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


В случае возникновения ошибок в новом коде, вы сбрасываете данные за коммит или за весь процесс? (Или только 1 возможен?)
— Руди

1
@Rudie: Если вам нужно откатить изменения на сервере развертывания, то вы можете использовать git resetдля возврата к последним изменениям (все фиксации, а не только весь запрос). Если вам нужно откатить что-то конкретное, что не является последним коммитом, то вы можете использовать его, git revertно, вероятно, его следует использовать только в чрезвычайных ситуациях ( git revertсоздает новый коммит, который отменяет эффект некоторого предыдущего коммита).
— Грег Хьюгилл

Просто из любопытства: как вы думаете, почему с крючками будет больше проблем, чем оно того стоит?
— Рейк

@Rijk: при использовании хуков для этого фактический каталог документов веб-сервера изменяется автоматическим фоновым процессом. Вход в систему позволяет мне лучше контролировать, когда изменения применяются к каталогу документов. Кроме того, это легче исправить, когда что-то идет не так. Хуки могут быть более подходящими, если коммиттеры не имеют достаточного доступа для входа на веб-сервер.
— Грег Хьюгилл,

То есть ваша настоящая папка webapp также является репозиторием .git? Как насчет папки .git, она видна внешнему миру?
— Фернандо

9

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 config receive.denyCurrentBranch updateInstead» в терминале
— stackPusher

5

Обновление: сейчас я использую решение Ллойда Мура с ключевым агентом 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 отличается от фактического рабочего каталога / path / to / project)


5

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

В нашем сценарии мы храним код в 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 /\..*$


4

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

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

С Capistrano, мы можем сделать легкий откат в случае ошибки

cap deploy:rollback
cap deploy:start_rsync

Вы интегрировали живое развертывание через rsync в capistrano?
— Мартин Авраам,

2

Giddyup - это не зависящие от языка git-хуки типа " просто добавь воды", которые автоматизируют развертывание с помощью git push. Это также позволяет вам иметь пользовательские перехватчики запуска / остановки для перезапуска веб-сервера, разогрева кеша и т. Д.

https://github.com/mpalmer/giddyup

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


1

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


1

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

В качестве альтернативы вы рассматривали возможность изменения сайта?

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


1

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

git archive --prefix=deploy/  master | tar -x -C $TMPDIR | rsync $TMPDIR/deploy/ --copy-links -av username@server.com:/home/user/my_app && rm -rf $TMPDIR/deploy
  • Архивирует главную ветку в tar
  • Распаковывает архив tar в каталог deploy в системную временную папку.
  • rsync превращается в сервер
  • удалить каталог развертывания из временной папки.

1

Я использую следующее решение от 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


таким образом, не удаляйте существующие файлы в хранилище.
— RusAlex

2
Почему git push web +master:refs/heads/masterвместо просто git push web master?
— Матье Мой

1

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

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

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

git ftp push

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

С уважением


0

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

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

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

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


0

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


0

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

DEPLOY SOLUTION 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

DEPLOY SOLUTION 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 *", и развертывает рабочее дерево, если соответствующая ветвь совпадает. Это позволяет развернуть версию dev и master версию в разных местах.

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.