Gitプッシュを使用してプロジェクトをデプロイする


412

を使用してWebサイトを展開することは可能git pushですか?私はそれがサーバー側でgitフックを使用して実行することと関係があるという勘を持ってgit reset --hardいますが、これを達成するにはどうすればよいですか?


2
これは本番サーバーが1つしかない場合にのみ当てはまると思いますよね?
ライク、2012年

6
@Rijkまあ、Gitで同時に複数のサーバーにプッシュできますが、そのレベルに到達すると、このようなハックではなく、実際のソリューションが必要になる場合があります。
Kyle Cronin

私は自分のプロジェクトでcapistranoを使用することに成功しました。元々はRuby on Railsアプリケーションのデプロイメント用に設計されましたが、PHPや他のプロジェクトでうまく機能します。

:ru.soのロシアへの回答翻訳ru.stackoverflow.com/questions/428483/...
ニックVolynkin

回答:


287

私はこのサイトでこのスクリプトを見つけましたが、それは非常にうまく機能しているようです。

  1. .gitディレクトリをWebサーバーにコピーします。
  2. ローカルコピーで、.git / configファイルを変更し、Webサーバーをリモートとして追加します。

    [remote "production"]
        url = username@webserver:/path/to/htdocs/.git
    
  3. サーバーで、.git / hooks / post-updateをこのファイルに置き換えます(以下の回答を参照)。

  4. ファイルへの実行アクセスを追加します(これもサーバー上):

    chmod +x .git/hooks/post-update
    
  5. これで、ローカルでWebサーバーにプッシュするだけで、作業コピーが自動的に更新されます。

    git push production
    

128
.gitディレクトリが読み取られないように保護する.htaccessポリシーがあることを確認してください。URLダイビングのような人は、アクセス可能であれば、ソースコード全体を使ってフィールドデーを楽しむことができます。
ジェフファーランド2010年

39
または、パブリックディレクトリをgit repoのサブディレクトリにします。次に、プライベートファイルを公開して、確実に公開されないようにすることができます。
tlrobinson、2010年

3
このリンクは死んでいます。更新後のファイルへの別のリンクはありますか?
ロバートハースト

6
多分私は何かが足りないかもしれませんが、運用サーバーにマスターgitリポジトリの製品ブランチからプルしてほしくないでしょう。OPにはサーバーが1つしかないと思いますか?私は通常、継続的インテグレーションサーバーにサイトの展開を行わせます(展開前にいくつかのテストを実行します)。
アダムゲント2011

4
コミットのシーケンスがすでにあるリポジトリからこれらの手順を実行します。マスターブランチは既にチェックアウトされているため、最初はプッシュできません。次に、リモートの代替ブランチをチェックアウトすると、異なるファイルのみが作業ディレクトリにチェックアウトされます。私はフックがリセットを実行することを期待していました
-barrymac

80

以下の更新後のファイルを使用:

  1. .gitディレクトリをWebサーバーにコピーします。
  2. ローカルコピーで、.git / configファイルを変更し、Webサーバーをリモートとして追加します。

    [remote "production"]
        url = username@webserver:/path/to/htdocs/.git
    
  3. サーバーで、.git / hooks / post-updateを以下のファイルに置き換えます

  4. ファイルへの実行アクセスを追加します(これもサーバー上):

    chmod +x .git/hooks/post-update
    
  5. これで、ローカルでWebサーバーにプッシュするだけで、作業コピーが自動的に更新されます。

    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
Geez ...このスクリプトは、php、python、groovyなど、開発に使用する言語で記述してください!(主観的に)かなり奇妙な構文を持ち、機能的な機能がほとんどないシェルスクリプトに対するこの愛情を理解していません。
dVaffection 2014年

4
@dVaffectionはいずれにしても、gitを使用している場合はシェルコマンドを記述します。そのため、別の言語でスクリプトを作成する代わりに、その言語とシェルを常に両立させます。すべてをシェルで書くのは論理的だと思いませんか?
Abderrahmane TAHRI JOUTI

サーバーでも「git config receive.denyCurrentBranch updateInstead」を実行して、プッシュを受け入れる必要がありました。ブランチがチェックアウトされたからだと思いますか?
stackPusher 2017年

60

この記事のおかげで、多くの誤ったスタートと行き止まりがありましたが、ようやく「git push remote」だけでWebサイトのコードをデプロイできるようになりました。

作者の更新後のスクリプトは1行しかないため、彼のソリューションでは、.htaccess構成でGitリポジトリを非表示にする必要はありません。

これをAmazon EC2インスタンスにデプロイする場合、いくつかの障害があります。

1)sudoを使用して最小限の宛先リポジトリを作成する場合、リポジトリの所有者をec2-userに変更する必要があります。そうしないと、プッシュが失敗します。(「chown ec2-user:ec2-user repo」を試してください。)

2)amazon-private-key .pem の場所を/ etc / ssh / ssh_configのIdentityFileパラメータとして、または〜/ .ssh / configで「[ Host]-HostName-IdentityFile-User " ここで説明するレイアウト...

...ただし、ホストが〜/ .ssh / configで構成されており、HostNameと異なる場合、Gitプッシュは失敗します。(それはおそらくGitのバグです)


私はあなたが言及した記事の手順に従いました、そしてすべてが魅力のように働きました。セキュリティや安定性に関していくつかの欠点があるのだろうか。これについて何かアドバイスはありますか?
xlttj

xl-t:SSH経由でGitを使用していると仮定すると、Gitを間違えることに危険があると思います。あなたは記事の著者に尋ねることができます。彼はそれを「質問と提案を歓迎します」で終わらせます。私の現在の(頭の痛い)複製戦略は、Panic SoftwareのTransmitを使用することです。
Earl Zedd 2011

1
フックを使用する場合、リンクされた記事には1つの重要な要件があります。.gitがたまたま作業ディレクトリと同じ命名体系にある場合、フックは失敗します。つまり、/ foo / bar(作業ディレクトリ)および/foo/bar.git(ベアボーンgitリポジトリ)。/ foo / barの名前を/foo/bar.liveや/ foo / blahなどの別の名前に変更してください。もし疑問に思っている場合は、作業ディレクトリの名前がベアボーンリポジトリは「リモート:致命的:元のcwdに戻れませんでした:そのようなファイルまたはディレクトリはありません」
Antony

1
実行するためにデプロイ後のフックが必要になる理由はわかりません。コードの変更をリモートリポジトリにプッシュすると、リモートリポジトリが最新になります。何が欠けていますか?
チャーリーシュリーサー2012年

1
@CharlieSに不足しているのは、gitではブランチをチェックアウトしたリポジトリにブランチをプッシュできないことです。この場合、(IMHOは非常に良い)答えは2つのリポジトリを持つことです:プッシュするベアリポジトリと、ベアリポジトリがプッシュされるとフックを介して作業ディレクトリが更新される2番目のリポジトリ。
ベンヒューズ

21

サーバーにgitをインストールしたり、.gitフォルダーをそこにコピーしたりしないでください。git cloneからサーバーを更新するには、次のコマンドを使用できます。

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

プロジェクトから削除されたファイルを削除する必要があるかもしれません。

これにより、チェックインされたすべてのファイルがコピーされます。rsyncは、とにかくサーバーにインストールされているsshを使用します。

サーバーにインストールするソフトウェアが少ないほど、彼の安全性が高くなり、構成の管理と文書化が容易になります。また、サーバー上に完全なgitクローンを保持する必要もありません。すべてを適切に保護することがより複雑になるだけです。


3
注意点:作業ディレクトリにあるファイルをrsyncします。現在の変更を隠し、すべてをクリーンアップし、デプロイしてから元に戻すスクリプトを使用することで回避できると思います。
mateusz.fiolka 2012

サーバーは男性ですか?
Ian Warburton 2017年

12

本質的にあなたがする必要があるのは以下のものです:

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

私のアプリケーションには、これらの行がという実行可能ファイルとして含まれていますdeploy

私は展開のI型をしたいとき./deploy myserver mybranch


sshに別の秘密鍵またはユーザー名が必要な場合の問題の解決方法については私の回答を参照してください
Karussell

このソリューションは、複数のサーバーに展開するときに私のソリューションよりも高速です!メインリポジトリにプッシュして、そこから並行してプルするだけです。また、すべてのインスタンスにキーを配置したくない、または配置できない場合は、キーエージェントを使用してください。ssh -A ...
Karussell、2012年

1
この回答が「シームレスに」機能するために使用するSSHキーの設定に関するガイドを含めると、簡単になります
Hengjie

git pull自動デプロイメントでは、競合がある場合にマージ部分で手動クリーンアップが必要になる可能性があるため、の使用は避けてください。
Quinn Comendant 2015

9

私が行う方法は、展開サーバーに変更をプッシュするためのGitリポジトリを裸にすることです。次に、展開サーバーにログインし、実際のWebサーバーのdocsディレクトリに移動して、git pullを実行します。私はこれを自動的に実行するためにフックを使用していません。それは価値があるよりも厄介なようです。


新しいコードでエラーが発生した場合、コミットごとにリセットするか、プル全体をリセットしますか?(または1つだけが可能ですか?)
ルディー

1
@Rudie:デプロイメントサーバーで変更をロールバックする必要がある場合は、を使用git resetして、最新の変更(プル全体だけでなく、すべてのコミット)の間を移動できます。最新のコミットではない特定のものをロールバックする必要git revertがある場合は、使用できますが、それは緊急時にのみ使用する必要があります(git revert以前のコミットの影響を元に戻す新しいコミットを作成します)。
グレッグヒューギル

ちょうど好奇心から:なぜフックはこれに値するよりも厄介だと思いますか?
ライク、2012年

@Rijk:これにフックを使用すると、実際のWebサーバーのdocsディレクトリが自動バックグラウンドプロセスによって変更されます。ログインすると、変更がdocsディレクトリに適用されるタイミングを正確に制御できます。また、問題が発生した場合の修正も簡単です。コミッターがWebサーバーにログインするための十分なアクセス権を持っていない場合は、フックがより適切な場合があります。
Greg Hewgill、2012年

実際のwebappフォルダーも.gitリポジトリですか?.gitフォルダーはどうですか、それは外の世界に見えますか?
フェルナンド14

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ディレクトリが含まれます。ユーザーに提供できないことを確認したい場合があります。
  • 展開中、ユーザーが一時的にサイトを一貫性のない状態に遭遇する可能性があります。古いバージョンのファイルと新しいバージョンのファイル、または半分書き込まれたファイルです。これがプロジェクトの問題である場合、プッシュデプロイはおそらく役に立ちません。
  • プロジェクトに「ビルド」ステップが必要な場合は、おそらくGithooksを使用して、それを明示的に設定する必要があります。

ただし、これらの点はすべてGitの範囲外であり、外部コードで処理する必要があります。その意味で、これはGitフックと一緒に、究極のソリューションです。


これを設定するには、ターミナルで次のコマンドを実行します: 'git config receive.denyCurrentBranch updateInstead'
stackPusher

5

更新:ロイドムーアソリューションとキーエージェントを使用していますssh -A ...。メインリポジトリにpushしてから、すべてのマシンから並行してプルすることは、少し高速であり、それらのマシンで必要なセットアップが少なくなります。


このソリューションはここには表示されません。gitがサーバーにインストールされている場合は、sshを介してプッシュするだけです。

ローカルの.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ディレクトリをWebサーバーにコピーする
  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フォルダーがドキュメントルート内にある場合は、.htaccesssource)を追加して、フォルダーを外部から非表示にしてください。

    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に統合しましたか?
マーティンアブラハム


1

サーバーに2つのコピーがあるはずです。プッシュ/プルが可能なベアコピー。完了時に変更をプッシュし、これをWebディレクトリに複製し、cronジョブを設定して、Webディレクトリからgit pullを毎日更新するか、そう。


1

gitフックを設定して、「安定した」ブランチと言ってコミットすると、変更がプルされてPHPサイトに適用されると考えられます。大きな欠点は、何か問題が発生した場合に多くの制御ができず、テストに時間がかかることです。しかし、トランクブランチを安定ブランチにマージすると、どのくらいの作業が必要になるかを知ることができます。衝突する可能性のある競合の数。1つのサイトのみを実行するつもりでない限り、サイト固有のファイル(構成ファイルなど)に注意することが重要です。

あるいは、代わりにサイトに変更をプッシュすることを検討しましたか?

gitフックの詳細については、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
  • masterブランチをtarにアーカイブします
  • tarアーカイブをシステムの一時フォルダーのデプロイディレクトリに抽出します。
  • サーバーへの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
Matthieu Moy

1

補足的な答えとして、私は代替案を提供したいと思います。私はgit-ftpを使用していますが、正常に動作します。

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

使いやすく、タイプのみ:

git ftp push

gitは自動的にプロジェクトファイルをアップロードします。

よろしく


0

複数の開発者が同じリポジトリにアクセスしている環境では、次のガイドラインが役立つ場合があります。

すべての開発者が所属するUNIXグループがあることを確認し、そのグループに.gitリポジトリの所有権を付与します。

  1. サーバーリポジトリの.git / configで、sharedrepository = trueを設定します。(これは、コミットとデプロイに必要な複数のユーザーを許可するようにgitに指示します。

  2. bashrcファイル内の各ユーザーのumaskを同じに設定します-002が良いスタートです


0

リポジトリから新しい更新を自動的にプルダウンする独自の基本的な展開ツールを作成することになりました-https ://github.com/jesalg/SlimJim-基本的に、それはgithub post-receive-hookをリッスンし、プロキシを使用してトリガーします更新スクリプト。


0

ポスト受信フックには2つのソリューションを使用します。

ソリューション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 *」文字列に一致するブランチ名をフィルタリングし、プッシュされたブランチが一致する場合は作業ツリーをデプロイします。これにより、開発バージョンとマスターバージョンを別の場所にデプロイできます。

DEPLOY SOLUTION 1は、リポジトリーの一部であり、コミットによって削除されたファイルのみを削除します。Deployment Solution 2よりも高速です。

DEPLOY SOLUTION 2には、repoに追加されたかどうかに関係なく、サーバー側に追加された本番ディレクトリから新しいファイルが削除されるという利点があります。それは常にレポのきれいなだましでしょう。Deployment Solution 1よりも遅いです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.