- 投稿日:
これは、かつて参画したGitHubを利用したプロジェクトでブランチフローが悪く事故が多発したので考案し、運用した内容です。
基本的には後々の運用を考えた時に情報源になり、かつGit操作に極力手間を取られることがなく、CI/CDを回しながら品質を維持できる内容で考えています。
フローの要件として考えたこと
取り回しが単純明快であること
開発以外の要素に振り回されないように単純なフローにしていて、世に言われる履歴の綺麗さとか言うのは個人的には関心が薄いので重視していません。その代わりコミットが壊れないことや、インデックスとして見やすくなるような部分を重視しています。
GitHubとの相性が良いこと
まず個々の開発タスクをIssueベースで管理し、Pull Requestベースで取り込む運用としました。
Pull Requestの取り込み方式はSquash Mergeとし、メインブランチのコミット履歴がPull Requestのマージコミットになるようにしました。
これはメインブランチのコミット履歴はPull Requestのマージコミットだけあれば後から追えるというのと、メインブランチのコミットログを単純にする意味でこの方式にしています。
CI/CDを活用しやすいこと
これは割とどこでもやっていると思いますが、ブランチ名にdevelop
とかstaging
, production
とか付けて管理することで、自動的に環境を識別できるようにしました。
実際に運用したフロー
フロー図
フローの運用内容
develop/main
ブランチを最新ブランチとする運用develop/main
ブランチ相当のものが複数ある状態というのが世の中にあると思いますが、管理が非常に大変なのでそれはしない方向にしました
- 機能ブランチを
develop/main
ブランチに取り込むのはSquash Merge- 基本的に変更履歴を見る時はGitLensや
blame
で変更行からPull Requestを当てて、そこを見に行くという運用にしていました
- 基本的に変更履歴を見る時はGitLensや
- 機能ブランチに
develop/main
ブランチを取り込むのはmerge
- 一般的には
rebase
が多いと思いますが、次の観点から採用しませんでした- どのポイントで取り込んだのかわからない
merge
と比較した場合にコンフリクト対応に手を取られる- 経験上ここで事故が頻発する
- 素直に
push
出来ない
merge
であれば以下のように単純な流れに出来ますし、push前に差分確認して事故を防ぐことも容易ですgit switch develop/main
git pull
git switch -
git merge -
- コンフリクトがあれば解消
git push
- 一般的には
- デプロイ方式によるルートブランチ分割
- ルートブランチ名によってデプロイ先を変更できるようにしました
- GitHub Actionsでブランチ名を拾って環境変数を差し替えることでデプロイするワークフローを組んでいます
staging/
やproduction/
ブランチはdevelop/main
からcheckout
する運用です- これらはデプロイするためだけの使い捨てブランチなので毎回生えます
あとがき
このフローの利点としてはマージでコンフリクトが起きても基本的にCurrentとIncomingを一回比較するだけで済むのでコンフリクトの解消が簡単で、コンフリクト時はIncomingが壊れないようにCurrentを直すのが基本になり、Currentを優先する場合は適宜上書きするといった内容です。
ブランチの合流はmerge
だとマージコミット分一回の解消だけでいいので事故の発生要因が低いのがrebase
と比較した時の利点です。rebase
だとコミット回数分再帰的に合流させる必要があるのでブランチの寿命が長かったりすると苦行になってきます。
このフローができた経緯としては元々はGitHub Flowをベースにしていたのですが、色々やっていくうちにこうしたらもっと良くなるのではないか?というのを試行錯誤していてこの形に落ち着いたのですが、後から調べたらGitLab Flowに近い形式に見えたので、似た内容は既に誰かが考えているものだなと感じました。
上で挙げた内容の他にもGitHubのリポジトリ設定でブランチ保護のルールを設定したり、Pull Requestのマージ設定でSquash mergingだけ許可したり、ヘッドブランチの自動削除をするなど、基本的に面倒なことを考えたり、しなくて良い様にするなど、開発に注力しやすいように環境を整えると心理的な抵抗が少なく運用できて便利だなと感じています。
- 投稿日:
VSCodeでは出来たことがPhpStormだと上手く出来なかったので、その解消法です
Remote Developmentに慣れてるとハマりやすいと思います
PhpStormに類似の機能は多分ないです
PhpStorm編
確認環境
一応Apacheの上に乗っかったLaravelで確認してますがそこらへんの環境情報は端折ってます
Env | Ver |
---|---|
Windows | 11 Pro |
PhpStorm | 2021.3.2 |
Docker | 20.10.11 |
docker-compose | 1.29.2 |
PHP | 8.1.1 |
Xdebug | 3.1.3 |
Dockerfile
PHPが入ってるDockerfileに以下を追記
出来ることならヒアドキュメントで書きたい
RUN pecl install xdebug
RUN docker-php-ext-enable xdebug
RUN echo "zend_extension=xdebug" > /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.mode=develop,coverage,debug,trace" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.start_with_request=trigger" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.client_host=host.docker.internal" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.trigger_value=StartProfileForMe" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
Dockerの設定
適当にDockerを追加してコンテナとローカルのパスをマッピング
PHPインタプリタの設定
CLIインタプリタをDockerに向けて設定します
パスマッピングは勝手にやってくれた気がする
デバッグ
HTTPリクエスト
受話器みたいなところを押してcurlなりPOSTMANなりブラウザなりにXDEBUG_TRIGGER=StartProfileForMe
というCookieを刺してリクエストするとブレークにかかります
初回だけパスマッピングを構成するダイアログが出てくるのでよしなに処理します
PHPUnit
デバッグ構成を作ってデバッグするだけ
おまけのVSCode編
VSCodeだとネイティブに動くのでDockerの存在を考えなくて済むのは楽ですが、IDEとしての性能はPHP Intelephenseに課金してもPhpStormには劣るので微妙なところ(静的解析に問題がある
確認環境
PhpStormと被る部分は端折ってます
Env | Ver |
---|---|
VSCode | 1.64.2 |
ms-vscode-remote.remote-containers | 0.217.4 |
robberphex.php-debug | 1.14.0 |
Dockerfile
PHPが入ってるDockerfileに以下を追記
PhpStormとの違いはxdebug.client_host
が不要なところです
(PhpStormでもCLI Debugだとなくていけるっぽいのでややこしい)
RUN pecl install xdebug
RUN docker-php-ext-enable xdebug
RUN echo "zend_extension=xdebug" > /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.mode=develop,coverage,debug,trace" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.start_with_request=trigger" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.trigger_value=StartProfileForMe" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
launch.json
- Listen for Xdebug
- HTTPリクエスト用
- PHPUnit
- PHPUnit用
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for Xdebug",
"type": "php",
"request": "launch",
"port": 9003
},
{
"name": "PHPUnit",
"type": "php",
"request": "launch",
"program": "${workspaceFolder}/vendor/phpunit/phpunit/phpunit",
"args": ["${file}"],
"env": {
"XDEBUG_TRIGGER": "StartProfileForMe"
},
"port": 9003
}
]
}
デバッグ
PHPのいるコンテナにAttach Visual Studio CodeしてF5押せばデバッグできます
あとがき
個人的に操作感はVSCodeの方が好みなので使えるならVSCodeでいきたいのですが、今の所PhpStormには敵わないという感じなのが悲しい
まぁJS/TS用のエディタみたいなもんだし仕方がないですね…
ただGitのGUI周りはVSCodeが圧倒的に好みなので、Git操作するときだけVSCode使ってたりはします
しかしPhpStormとVSCodeを共存させるのはxdebug.client_host
の向きの関係で微妙な感じですね…
- 投稿日:
初回セットアップ
pacman -Syuu
# 一回落ちるのでもう一度起動して
pacman -Syuu
入れとくと便利なものたち
pacman
pacman -sS unzip
pacman -S --noconfirm unzip
pacman -sS diffutils
pacman -S --noconfirm diffutils
pacman -sS dnsutils
pacman -S --noconfirm dnsutils
pacman -sS openssh
pacman -S --noconfirm openssh
pacman -sS patch
pacman -S --noconfirm patch
pacman -sS perl
pacman -S --noconfirm perl
pacman -sS zsh
pacman -S --noconfirm zsh
pacman -sS git
pacman -S --noconfirm git
# prompt用に退避させる
mv /usr/bin/git /usr/bin/msys2_git
バイナリ追加
dotfileの設定
Windows Terminal連携
{
"defaultProfile": "{17da3cac-b318-431e-8a3e-7fcdefe6d114}",
"profiles": {
"defaults": {},
"list": [
{
"commandline": "C:/env/msys64/msys2_shell.cmd -defterm -here -use-full-path -no-start -msys -shell zsh",
"font": {
"face": "Consolas",
"size": 11
},
"guid": "{17da3cac-b318-431e-8a3e-7fcdefe6d114}",
"icon": "C:/env/msys64/mingw64.ico",
"name": "MINGW64 / MSYS2",
"colorScheme": "VSCode"
}
]
},
"schemes": [
{
"name": "VSCode",
"background": "#1e1e1e",
"foreground": "#d4d4d4",
"black": "#000000",
"blue": "#2472c8",
"brightBlack": "#666666",
"brightBlue": "#3b8eea",
"brightCyan": "#29b8db",
"brightGreen": "#23d18b",
"brightPurple": "#d670d6",
"brightRed": "#f14c4c",
"brightWhite": "#e5e5e5",
"brightYellow": "#f5f543",
"cyan": "#11a8cd",
"green": "#0dbc79",
"purple": "#bc3fbc",
"red": "#cd3131",
"white": "#e5e5e5",
"yellow": "#e5e510"
}
]
}
msys2_shell.cmdのCLI Optionsの意味合い
-mingw32 | -mingw64 | -ucrt64 | -clang64 | -msys[2]
それぞれで実行環境が変わる
-msys
で基本的に良い
-defterm | -mintty | -conemu
開くターミナルの指定
-defterm
- 標準ターミナルで開く
- Windows TerminalやVSCodeで開く場合はこれを指定する
-mintty
- Minttyが起動する
-conemu
- Conemuが起動する
-here
現在の作業フォルダをカレントディレクトリとして開く
-where DIRECTORY
指定ディレクトリをカレントディレクトリとして開く
-[use-]full-path
Windowsのパスを継承する
-no-start
新窓で開かない
指定しない場合start
コマンドでシェルが起動する
-shell SHELL
ログインシェルを指定する
例えば-shell zsh
ならzshがログインシェルになる
未指定の場合bashがログインシェルになる
msys2_shell.cmd
を書き換えて実現することもできるが、アップデートで書き換えた内容が消えることがあるのでオススメしない
-help | --help | -? | /?
ヘルプの表示
- 投稿日:
置換をするためのコマンドだが、PCREは基本使えない(自前でビルドすれば使える)
大抵のケースでPerlを使った方が楽だが、Dockerなど、入っていない環境では重宝する
オプション
-l
入力からケツ改行を消す
CLI入力するとケツに改行が入るのでそれを除去できる-p
入力行を処理する-e
スクリプトを流せるphp -r
のようなもの-i[ext]
ファイル置換。extに指定があるとバックアップファイルが生えるsed -i.bak -e 's/aaa/bbb/' path/to/file