Zenn
🐡

おれのubuntu(WSL2)設定メモ

2024/08/11に公開
WSL 2
tech

\large{Zennは、8万字を超えると、保存できないようなので分けました}
https://zenn.dev/tazzae999jp/articles/0934afe501db0c
\large{上記が、2つ目です}

はじめに

Ubuntu(WSL2)は、

Hyper-VのVMでの動作ではあるが、純粋なLinuxカーネル上で、Ubuntuのディストロを動作させて
Windowsとの統合がなされて、作業のしやすい環境です。

Linuxをターゲットとしたアプリの開発環境としては、非常に有効な

環境ではないかと思っています。

なので、とても、気に入っています。

まずは、

★★ 右側のサイドバーの目次のメニュー項目をざぁっと、ながめてほしいです。 ★★

大枠、どのような事が書いてるかというと

まずは、
WSL2で作業時の基礎的な考え方を書いてます。

それから、

dockerを使った時にMacユーザとの環境差より生じる
バインドマウンドしたホスト側での作業時に発生する★権限問題★を
★★ 「一発で驚くほど楽に解決できる」ついて記載があります。　 ★★
★★ 「一度、設定してしまえば、後はなにもしなくてもよくなります」　★★
★★ 頻繁に「sudo chown -R myuser:mygroup .」を実行するなどの、めんどい事は不要　★★

★★ それは、POSIX ACLという枯れた信頼性の高い技術を使う方法です　★★

これでもう、dockerでバインドマウント時の★権限問題★に、さよなら、できます。

新しい環境を作ったときに、当サイトのPOSIX ACLにあるコマンドを
メモ帳などにコピペして編集し、それらのコマンドを1回打ち込んで設定することを、
やればいいだけです。それだけです。それだけで、

dockerでバインドマウント時の★権限問題★に、さよなら、できます。

補足:
「dockerを使った時にMacユーザとの環境差より生じる」と書いたが
ターゲットをLinuxとしたアプリ開発での開発環境であれば、
ネイティブLinuxや、Ubuntu(WSL2)での環境を考慮した
docker設定や手順こそが本来的で、そちらにあわせていれば
Ubuntu(WSL2)側としては、そもそも、なんの問題もおきないのである。
MacはBSD系のUnixのためLinuxではありません。
そのBSD系のUnixであるがゆえに特有の環境だがMacユーザには楽なdocker設定を
現状多数派であるという理由で、チーム内で連携してくるから
Ubuntu(WSL2)側で★権限問題★が発生するだけです。
Linuxをターゲットにしてるなら、Linuxカーネルを使ってる
Ubuntu(WSL2)側に、むしろ、あわせろよ。と思うんだけど。
仕方がないので調べた結果
POSIX ACLの解決策が最も楽であるとの調査結果に至ったのです
このあたりの話は「上記で最後で記載した★権限問題★とは何か」
の項目の後半で詳細に説明しています。

また、

Xdebugなどdocker-compose.ymlでの追記、箇所
dockerを使った場合に焦点あてて書いてます
その他、Laravelでの開発者向けに、ide-helperについて記載してます。

他、
Linux版のGitkrakenのインストール方法や、考え方を記載してます。
( Ubuntu領域にある大規模gitリポジトリの場合、sourcetreeが固まって使えない問題で、
sourcetreeに代わりとして使えるものとしてのLinux版のGitkraken )

他、もろもろ

＜＜今後も、都度、必要な情報、有効な情報を追記して充実させたいと思ってます＞＞

このような情報を充実させて、
Ubuntu(WSL2)の環境でのエンジニアを増やしたい。
と思ってます。
Ubuntu(WSL2)の環境を利用する敷居を低くすることに貢献したい

当サイトを書いてる目的

目的は、２つあります。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★ ＜1つ目の目的＞ ★
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
Ubuntu(WSL2)の環境でのエンジニアを増やしたい。
増えれば、増えるほど、インターネット上に情報が増えて
トラブルシューティングがしやすい状況となる。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

それから、

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★ ＜2つ目の目的＞ ★
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
私自身が自分のためのカンニングペーパーになるサイトが欲しい
時間かけて過去に調べた情報を必要な時に、すぐに、引っぱり出せる
カンニングペーパーが欲しい
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

＜2つ目の目的＞だけであれば、自分がわかる程度の箇条書きや、簡素な書き方でよいのですが
＜1つ目の目的＞の動機があるため、かなり文章を書きました。

すいません、
日本語の文字列への項目へのページ内リンクがzennのmarkdown記法で、
サポートがないみたいで、ページ内リンクが作れませんでした。
右のサイドバーの目次のメニューや、Ctrl+Fでの文字列検索を活用してほしいです

想定読者

Linuxの基礎知識がある人で、
Ubuntu(WSL2)でのdocker環境での開発での困りごと解決やその手の知識を拾っていきたい人
などを想定してます。
すいませんが、Linuxの基礎知識は前提にさせてもらいます。
その前提もなしにしてしまうと記述量が膨大になってしまいます。

最初からWindows Terminalでの作業がオススメ

「Windows Terminal」だと既存のPowershellも使えます。
複数タブで切り替えて作業しやすいです。
それから、見た目のデザインもかっこいいです。

後述の、
目次の項目の「Windows Terminalが作業しやすい」を先に見て、
wsl -l -oなどや、UbuntuのディストロのインストールからWindows Terminalで
作業してもよいぐらいだと思うです。

なお、WindowsでWSL2自体を有効にする方法などは
https://lazesoftware.com/ja/blog/230130/
のサイトなど、他でもネットにあります。
Docker Desktop自体のインストールなどもネット上に既に情報がありますので
当サイトでは、そこらへんの記述は割愛します。
その後、どうするかなどについての記述にします。

ちなみに、Windows版のDocker Desktopのインストール方法はこちらに情報ありました。
https://zenn.dev/longbridge/articles/d9f544f5b4cb82

Windowsとの統合の話

ls -l で表示されるようなファイルやディレクトリの所有者やパーミッションなどの
概念はそもそも、Windowsにはありません。

にもかかわらず、
Windowsのエクスプローラーや、Windowsのアプリで
Ubuntu領域のフォルダに対して、
\\wsl.localhost\Ubuntu-24.04-my\　からはじまるようなWindows用のパスで
アクセスできます。
そのまま、その場所に、ファイルや、フォルダを作れてしまいます。
そのとき、Ubuntu側のターミナルで、作られたファイルや、フォルダを
ls -lで見た時に所有者やパーミッションはどうなるのだろうか？
Windowsには、ls -lで見た時に所有者やパーミッションなどの概念ないが
この場合は、どうなるんだろうか？

そんなところが、最初、疑問でした。

Ubuntuのディストロをインストール時に、作る初期ユーザ―での実行として
作られたファイルや、フォルダは、そのユーザーの所有物となるような
連携がWSL2の仕組みにあります。
WindowsのアプリでUbuntuの領域で操作時は、その仕組みで
Ubuntu側での初期ユーザ―での実行されたことになる連携のようです。

ちなみに、その初期ユーザはユーザ名とグループ名は同じ文字列で
UID=1000、GID=1000で、インストールしたディストロに作られます。

そういう情報を見て、実際にWindowsアプリでUbuntuの領域にファイルを作ってみたら
所有者が初期ユーザとなってるのを確認できた。
パーミンションはデフォルトのumaskが効いてる感じなのか、
フォルダは755、ファイルは644になってました。

それから、その初期ユーザでは権限がない操作は、Windowsのアプリを通じても
Ubuntu領域ではできないようになってました。
エラーメッセージで怒られるか、単に、怒られないが無視されて実際にはできないなど
Ubuntu側のターミナルでsudoを通じてなどで権限調整をするコマンドを打ち込んでから
Windowsのアプリを通じてやってみたらできました。

つまり、

Ubuntuの領域に対して、実行ユーザが初期ユーザ―として
Windows側の機能で操作できる状況になっていることを理解しました。

上記のような体験を通じて納得していった覚えがあります。

それから、Ubuntuの環境変数PATHの後ろのほうに、WindowsのアプリへのPATHの値が
自動的に追加されていた。
Ubuntuのターミナルから、Windows側のプログラムや、アプリやデータにアクセスしやすいような状況になってます。

code . でカレントディレクトリでVisualStudioCodeが起動できたり、
explorer.exe . でカレントディレクトリについて、エクスプローラーを起動したり
そういったことができるのも、環境変数のPATHの末尾にWindows側の値が
追加されているからです。

WSL2では共通のLinuxカーネルが動いてます。
その共通のLinuxカーネルで、インストールした各ディストロ(ディストリビューション)や、
Docker Desktopをインストールした場合は、そのDockerが動きます。

それらの各、ディストロのUbuntuなどに対して、
上記のようなWindowsとの統合がなされてる環境だと理解しました。

Windowsの機能をある程度、活用しながら作業ができるLinux環境のようなものです。

しかも、WSL2からはHyper-VのVMではあるが、純粋なLinuxカーネルとのこと。

純粋なLinuxカーネルと言っても、Windowsとの統合のために若干は手を加えられて
いるような感じなのか・・。

すいませんが、そこまでの詳細は私にはわかりません。

ただし、純粋なLinuxカーネル上で、Ubuntuなどのディストロを動作させて
Windowsとの統合での作業のしやすさがあれば、
Linuxをターゲットとしたアプリの開発環境としては、非常に有効な環境ではないか
と思っています。

なので、とても、気に入っています。

このUbuntu(WSL2)での環境のアプリ開発者が、もっと、もっと増えて
インターネット上に、沢山情報が書き込まれて、
トラブルシューティングがしやすい状況にどんどんなっていけいいなぁ
と思ってます。

そんな人が、どんどん増えてほしいです。

だから、私も当サイトのような記事を書いてます。

私自身が自分のためのカンニングペーパーになるサイトが欲しかったというのもあります。
時間かけて過去に調べた情報を必要な時に、すぐに、引っぱり出せる
カンニングペーパーが欲しいということです。

上記で説明したWindowsとの統合の、考え方が最初、わかりませんでした
やりながら、あぁ、なるほどと、納得していった記憶があります。

最初にその考え方がわかったほうが、やっていきやすいだろうと思いました。

だから、一旦、考え方の説明文をここに書くことにしました。
ここに書いた文章を読むだけで、やったことが無い人でも
ある程度はイメージが付くのではないか
イメージが先についたほうが行動しやすいと思います。

上記の話を前提として、ここからは注意点を書きます。

普通に、インストールしたディストロをそのまま使ってる場合は、
上記のようなWindowsとの統合が、何もしなくてもデフォルトで効いてくれてるので、
気にしなくてもいいです。

しかし、もし、
ディストロを別名でimportして複製した場合は( 私の場合は、そうしてるのですが )
上記のような、Windowsとの連携が外れた状態になってしまいます。
その場合は、wsl.confの記述をして、上記のようなWindowsとの連携が効くようにする
必要があります。
その件については、それが必要な人は、
目次の項目の「ディストロのexport／importなど」の項目を読んでもらった後に、
目次の項目の「wsl.confの設定変更時の参考ネタ」の項目を読んでもらえば
よろしいかと思います。

dockerを使う開発ではUbuntu(WSL2)を使うのがよい

https://lazesoftware.com/ja/blog/230130/
のサイトで、dockerコンテナより、バインドマウントするホスト側が
NTFSファイルシステムだと変換処理のため非常に動作が遅い
言及されてる解決策２より、ホスト側は、Ubuntuを使うのがよい

補足:
別にdockerを使う、使わないに限らず、
そもそも、Linuxをターゲットにしてるアプリの開発であれば
Ubuntu(WSL2)を使うのがよいと思います。
Windows直で開発環境を作るより、Ubuntu(WSL2)に開発環境を作ったほうがよいと思います
環境的にWindowsだと対応してないものもあると思います。
Linuxをターゲットにしてるアプリの開発で、Ubuntu(WSL2)の環境で対応してないことが
あるとはあんまり思えないです。また、チーム内でのMacユーザの環境構築の方法との
親和性を考えた時、Windowsに環境構築するより、
Ubuntu(WSL2)に開発環境を作ったほうが有利ではないかと思います。
上記のサイトの解決策2では、dockerでバインドマウントした時に、
NTFSファイルシステムへのバインドマウントだと
遅いということを回避したいという動機で、Ubuntuを使うことが書かれていますが、
そもそも、Linuxをターゲットにしてるアプリの開発であれば、
dockerを使う、使わないに限らず、Ubuntu(WSL2)を使うのがよいと思います。

ただし、Ubuntuを使っても/mnt/cなどからはじまるWindowsのNTFSをマウントしてるところ
だと意味がない
ちゃんと、それ以外のlinuxのパスでのホスト側のext4ファイルシステムの領域を
バインドマウントしなければ意味がないです。
ただし、この方法を使うと★権限問題★が発生する。
それは、すぐ、下の
目次の項目の「上記で最後で記載した★権限問題★とは何か」
の項目を読んでいただければよいと思います。
その★権限問題★が何かの説明が詳細に書かれています。
( 理解しようとするとLinuxの基礎知識や、dockerの概念が必要になります )
( 理解できなくても、とりあえず、対処法のPOSIX ACLだけやっといて回避しとくのもよい )
そして、その解決方法として当サイトでは、POSIX ACLをおススメしているので
★権限問題★の対処法については、目次の項目の「POSIX ACL」の項目を読んでいただければ
よろしいかと思います。

補足:
個人的には、ホスト側の 「/home/ユーザー名」の配下のフォルダを
バインドマウントの対象とするのは、あまり、おススメしない。
理由は、dockerコンテナ側にユーザーを作りたくなった時に、
詳細は忘れたがうまく動かない要因があり、環境を作り直したことがあった。
なので、ホスト側の/の直下に、sudoなどでroot権限でフォルダを作って
それを「sudo chown -R myuser:mygroup /そのフォルダ名」
で、作業ユーザーの所有者に変更後、その配下に作業ユーザで作っていった
ホスト側のフォルダをバインドマウントの対象にしておくようにしている。
dockerコンテナ側にユーザーを作りたくなることがあるのか？
という話ですが、それは開発作業中に、実装したいものの仕様によっては動作確認のため
あるかもしれない、そんなのはわからない。
けれど、そうなっても問題がないやり方に、はじめからしとけばよいと思います。

上記で最後で記載した★権限問題★とは何か

Mac環境ではおきないが、Ubuntu環境ではおきる権限問題がある

  • dockerコンテナ内部はrootで作業する(普通はそうであるとのこと)

補足:
rootで作業する(普通はそうであるとのこと)
と書いたが本当はそうは思わない。
実際にはBSDのUNIXなのに、Linuxだと嘘ついての多数派である
Macユーザの作業が楽だから、そうしてるだけの話で、
そんなのは、全く、本来的ではないはず。
仕方がないから、こちらがそれに同調して、「(普通はそうであるとのこと)」
と言ってあげてるだけの話。
後述の本来的な話としては、システム作業はrootで、それ以外は一般ユーザと
分けて使うのが本来のはず。

  • ホスト側は一般ユーザで作業する

  • ディレクトリや、ファイルを作成した時の所有者は作業した実行ユーザー

  • dockerコンテナ側のrootで作業中に作られたものはroot所有

  • ホスト側の一般ユーザで作業したものは、一般ユーザ所有

  • しかし、Macでは、バインドマウントしている領域はホスト側で見た時は、常に一般ユーザ所有になってる。

    そのためMacでのホスト側で一般ユーザで実行するgit操作などでは権限エラーなどの
    問題がおきない。
    (同一ファイルやディレクトリについてdockerコンテナ側がroot所有であっても)

    なぜ、そうなるかの理由は複雑であるため、後述の

    ＜＜なぜ、Mac環境では、この権限問題がおきなくてUbuntuではおきるのか＞＞
    のところで、説明を詳細に書いてますので、そこを参照してください。

    一方、
    Ubuntuではdockerコンテナでroot所有になったものはホスト側でも
    root所有となるため、ホスト側での一般ユーザでのgit操作やその他の作業時に
    root所有となってるファイルや、ディレクトリが混在しているがために権限エラーの
    トラブルとなってしまう。
    Dockerfileをローカルで編集するなどして、ホスト側で作業する一般ユーザーと
    UID、GIDをあわせたユーザを作り、dockerコンテナ側の作業もそのユーザにあわせる
    などの考え方もあるが

    補足:
    そもそも、この考え方が本来的であろう、Linux/Unixでの作業なのだから
    rootユーザでシステム構築して、他は一般ユーザで作業し、ネットワーク越しなら
    両サイドでUID、GIDを合わせた同一ユーザで作業する考えなどは
    Unix系では基礎的な考え方であり、それを無視して単にMacで楽ができる方式
    で連携してくるのでUbuntu(WSL2)側で★権限問題★がおきてしまうのである

    仕方がないので、調査した結果、
    POSIX ACLを使う解決策がありまして、それが最も楽な( この本来的でない状況での )
    解決法だったので、このサイトでは、おススメとして紹介してる次第である。
    ここでは一旦、この権限関連の問題点の説明を続行する。

  • Ubuntu側は、バインドマウント領域は一般ユーザ所有とroot所有が混在した状態になる

  • バインドマウントした領域は通常は、gitのローカルリポジトリのルートディレクトリなど

  • Ubuntu側で、ブランチ切替や、プル時に権限エラーなどがでてgitが不整合になってしまう

  • gitコマンドは一般ユーザで打ち込むため、root所有のディレクトリでファイルを作成、削除などは権限エラーでできない。root所有のファイルを更新、削除などできない

  • ステージング追加、削除や、commitは実ファイルの操作でなくgit内の管理領域の更新なので、この手のエラーはでない。git checkoutや、git pullなど実際にディレクトリ、ファイルを作成、更新、削除する行為の時に問題が発生する

上記、問題の解決策については、このサイトの

POSIX ACL

で説明している解決策がおススメ

ローカルのgitリポジトリのルートディレクトリを基点に配下の末端までに対して

POSIX ACLで作業している一般ユーザにフル制御の権限を別枠でカーネルレベルで

付与する方法である。

POSIX ACLは、20年ぐらい前からある枯れた技術のようなので信頼性は高いだろう


★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
＜＜なぜ、Mac環境では、この権限問題がおきなくてUbuntuではおきるのか＞＞
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
ところで、ここで話題になってる権限問題は、

なぜ、Macでは発生しないが、Ubuntu(WSL2)では発生するのかを説明する
かなり複雑な話なので、順を追って説明するしかありません。
そもそも、dockerはLinuxカーネルで動くものである
DockerHubのイメージは何かのLinuxのディストリビューションのみで
そこにレイヤーを重ねていく方式となってる
ホストマシンにLinuxカーネルがなければ、dockerは動作しない
MacはUnix系であるがBSD系のUnixがカーネルであり、直接、dockerを動作させることができない

そのため、hyperkitなどのVMでlinuxカーネルを準備して、そこでdockerを動作させている
(詳細は知らんしMacの種類や環境で異なるのか？、そこらへん知らんけど、とにかくVMで)

つまり、Mac本体とdockerは別カーネルで、別々にうごいており
バインドマウントは、別々に動いてるもの同士をくっつけるようなことを
する必要性が、Macでdockerを使う場合はある。

それに、
Macはファイルシステムもaplfsなどで、linuxのext4とも異なる

カーネルだけでなくファイルシステムも異なるため、dockerコンテナからホストへ
バインドマウント時に直接的なマウントできない

そのため、osxfs, Fuse, virtioFSなどの共有ファイルのやり方を間に介して
バインドマウントする


そのため、Ubuntu(WSL2)でのバインドマウントよりも低速である
もっとも、virtioFSが使えるようになってから、かなり速度改善があったようではあるが・・


これらの、osxfs, Fuse, virtioFSなどの共有ファイルの仕組みは、
「こちら側」と「あちらが側」で権限に２面性がある様子。
わかりにく話かもしれませんが、すぐ後で、俗っぽい言葉で説明しなおしてますので
一旦、我慢して読んでください。

つまり、
ファイルや、ディレクトリに付与される
所有者ユーザー、所有グループ、パーミンションが
dockerコンテナ側と、ホスト側で異なる状態になりうるようである。


Macのdockerのバインドマウントについて、
このあたりの影響してなのか、それが意図して設計した動きとしてそうなったのか、
偶然にも図らずもそうなったのかは不明だが
dockerコンテナ側でroot所有であっても、バインドマウントした領域で
同じディレクトリや、ファイルをホスト側で見た時に、一般ユーザの所有となっている
ホスト側で見た時に、一般ユーザの所有となっているので、
前述のgit操作でのブランチ切替や、git pull時での
権限エラーの問題が発生しないのである。

★★★★★★★★
わかりにくい事柄なので、俗っぽい言葉で説明をしなおします。
★★★★★★★★
例えばの話、PC上のある領域を他の人にも見えるように共有したとします。
自分は読み書きできる状態だが、他の人は読み取り専用の設定などしたとする。
その場合、共有したときに、「こちら側」と「あちら側」では権限が異なります。
この例の場合、
「こちら側」：自分は読み書きできる
「あちら側」：他の人は読み取り専用
という権限の２面性のこと。
ですので、共有ファイルやら、そういった仕組みは、そもそも、
「こちら側」、「あちら側」など本来的に、権限に2面性を持ったものであり、
osxfs, FUSE, virtioFSも、そのようなものではないか。
そんなosxfs, FUSE, virtioFSを間に介して、Macがdockerのバインドマウント
を解決しているので、
dockerコンテナ側はroot所有だが、同じファイルや、ディレクトリについて、
ホスト側では、一般ユーザー( おそらく、dockerコンテナを起動したユーザー )
の所有となるの２面性を持った権限状態になってるのではないか
ということを説明したかった。( 説明するの、めんどい話ですけど・・ )
それが、意図してそれを設計した結果そうなったのか、偶然にも図らずも、そうなったかは
知らないが、実際問題、Macユーザはこの話題での権限問題で、
git操作時、ブランチ切替や、プルでエラーになったりしないとのこと
★★★★★★★★
それで、
この詳細を知ってか知らずか、Macで問題がおきなかったのだからと
そのようなdocker-compose.yml, Dockerfileがチーム開発で提供されることがある
その時に、Ubuntu(WSL2)利用者としてはどう対処すべきかである
その解決策として当サイトでは、後述にてPOSIX ACLを使うのがよいのではないかと説明してる。


一方、


Ubuntu(WSL2)では、WSL2での共通のLinuxカーネルにてdockerおよび、Ubuntuのディストロが動作している。
dockerコンテナは技術的には、linux上のnamaespaceで隔離された単なるプロセスに過ぎない
したがってバインドマウントしても、それは同じlinuxカーネルで動いてる別プロセスが
namespace違いを解決した形で単にアクセスしているだけである
そのため、Ubuntu(WSL2)での(というかネイティブlinuxでも多分、そうだが)
dockerコンテナからホストへのバインドマウントは最も高速である
バインドマウントについて、速度面については気にする必要はない
ただし、dockerコンテナでrootで作業し、root所有として作成されたものは
ホスト側で見てもroot所有となっているため
そのままでは、ホスト側の一般ユーザで操作しようとした時に権限エラーとなってしまう
だからといって、毎回、毎回、頻繁に
sudo chown -R myuser:mygroup .
をgitリポジトリのルートディレクトリで打ち込んで回避するやり方もめんどいし
やり忘れてgit操作してしまい、エラーでgitが不整合になるとそれを直したりする作業が
煩雑でめんどいので、一回、設定しとけば後は何もしなくても問題なしとなるような
解決策が望まれた。その解決策として後述のPOSIX ACLを書いてるのである。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★


以上、本当に説明するのが、非常にめんどい、話だったのですが
なんで、こんなことになってるのかということです。
それは、昔、WSL2の環境がなかったときに、Linuxをターゲットにしたアプリの開発では
UnixがベースになってるMacで開発環境を作ったほうが圧倒的に有利だったわけです
その歴史的な背景で現状、Macユーザが多いため、Macユーザ側で作業が楽なやり方での
環境構築の連携がされがちなところが、あるのではないかと思うです

でも、よく考えてみれば、MacもUnixベースではあるがベースとなってるのは
BSD系のUnixであるため、Linuxではないんですね
だから、virtioFSを介した結果での上記ような事などになってるんだと思うんです。

よく考えてもらいたいのですが、
Ubuntu(WSL2)でLinuxベースの環境のほうがLinuxアプリの開発環境としては
より本来的なのではないかと、個人的に思うです

だから、もっと、Ubuntu(WSL2)でのLinuxターゲットのアプリ開発者が増えてくれて
人数比で負けない状況となれば、あとは、理屈の本筋論、
本来は、どっちが本筋なのか？　Linuxカーネルでしてるほうでしょ
と、言い返すことができると思うです

そしたら、Ubuntu(WSL2)利用者にとっての状況が改善するんじゃないかと思うです
そのために、Ubuntu(WSL2)利用者を増やしたい

私の、このサイトも、Ubuntu(WSL2)利用者を増やす助けになれば幸いだと思うです。



dockerの基礎知識

dockerの基礎知識は、

https://zenn.dev/suzuki_hoge/books/2022-03-docker-practice-8ae36c33424b59

のzennの本を全部読んだら概念がわかりやすい
でも、dockerのコマンドを一個一個、覚えて打ち込んでいく方法は難しいので

上記で基礎概念を見た後に

docker-composeを使った方式が手早い

機会があれば、docker-compose.ymlなどについても当サイトに追記したい

kubernetesというのがあるらしいが、そこまでの発展系は、私には、まだ、よくわからない


ちょっとした覚書だけ書いておく

docker compose stop
で停止
docker compose down
で削除
別のフォルダ構成にdocker-compose.ymlを置いて
同じコンテナ名のものを別フォルダの配下で構築しなおしたい場合
事前に、元のところで「docker compose down」して削除しておいたほうがよい

docker compose build
でイメージから作成
キャッシュを無視して、再ビルドを強制したければ
docker compose build --no-cache

docker compose up -d
で、コンテナ起動

docker compose ps
でコンテナの状態を確認。




dockerの基礎知識(ENTRYPOINTを指定しつつデフォルトのCMD復元)

Dockerfileで、バインドマウントしているホスト領域に対して
何かを行いたいことがあったが
Dockerfile内での各RUN でのコマンドの実行の段階では
バインドマウントが行われる前の段階であったため
うまくいかなかった。

そこで、
Dockerfileの末尾に下記のものを追加した。

# バインドマウントをした後の領域への設定が必要なため
# entrypoint.sh側で処理を行う必要性があった

# entrypoint.shをコピーして実行権限を付与
COPY entrypoint.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/entrypoint.sh

# コンテナ起動時にentrypoint.shを実行
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]

# ENTRYPOINTを書くことで、デフォルトのCMDが実行されなくなるため
# docker inspect php:7.4-apache
# で
#            "Cmd": [
#                "apache2-foreground"
#            ],
#
# 確認し、それを実行することにした
# entrypoint.shで、「exec "$@"」の記述で実行される
# デフォルトのCMDを指定する。
CMD ["apache2-foreground"]

バインドマウントがなされている前提の処理を
entrypoint.shに記述した
ENTRYPOINTを書くと、デフォルトのCMDの実行が上書きされて動かないようである
ですので、
CMD ["apache2-foreground"]
でデフォルトと同じものをCMD指定しておいて
entrypoint.sh内では、
exec "$@"
をすることで、上記の例で、CMD指定をした
apache2-foreground
を実行することができる
ところで、
CMD ["apache2-foreground"]
のデフォルトのCMDの見つけ方ですが
Dockerfileで
FROM php:7.4-apache
を基点にしている例では、

docker inspect php:7.4-apache

を実行して表示されたものから

            "Cmd": [
                "apache2-foreground"
            ],

のようなCMDの指定を見つけて、これをDockerfileの最後に書けば
ENTRYPOINTを書いても、ENTRYPOINTで指定したシェルスクリプトの中で
exec "$@"
を実行することでデフォルトですべきCMDの処理を行う構成にできる。

docker inspect php:7.4-apache

の段階でエラーになる場合は、
docker images
で表示されるリストに、php:7.4-apache
がないのですから
docker pull php:7.4-apache
して
docker images
で表示されるリストに、php:7.4-apache
が含まれる状況にした後に
docker inspect php:7.4-apache
をすればよい。

ちなみにここで言及している
ENTRYPOINTや、デフォルトのCMDは、
docker compose build
や、
docker compose build --no-cache
のときには、動くのではなく
docker compose up -d のときに毎回動くものである
そのため、
entrypoint.sh内に記述するファイルや、フォルダの作成や、コピーや移動などの
処理は、前回の実行で既にある　などのときでも
問題なくエラーにならないような記述が必要である
例として、
mkdir -p /var/www/html/laravelapp/storage/app/public/ffmpeg-bin
などでは、mkdirは、「-p」のオプションがあれば、既にある場合はなにもせず、エラーにもならない
特にユーザに聞いてきてそこで処理がとまることがない
cp -u /usr/lib/x86_64-linux-gnu/libav*.so* /var/www/html/laravelapp/storage/app/public/ffmpeg-bin
などでは、cpは「-u」のオプションがあれば、コピー先が既にあった場合は、
コピー元の更新日時が新しい場合だけコピーしなおす
そうでない場合もエラーにならず、正常に完了し、特にユーザに聞いてきてそこで処理がとまることがない。
「docker compose up -d のときに毎回動く」を前提にして
既にあるケースを考慮し、
このように配慮をして
エラーにならず、正常に完了し、特にユーザに聞いてきてそこで処理がとまることがない
となるような、
シェルスクリプトの実装をすることがENTRYPOINTで指定するentrypoint.shでは、
必要になるだろう。

dockerの環境がおかしくなった時

自分は、なったことないけど
dockerがおかしくなったときの最終手段として、
下記に書いてるように、綺麗にする方法があるらしい

https://qiita.com/24Century/items/f77e4fde7ed806d29096

Windows Terminalが作業しやすい

Microsoft StoreからインストールできるWindows Terminalが作業しやすい

インストール後は、スタートメニューの横の虫眼鏡で、terminal 打ち込んだから

カタカナで、「ターミナル」という項目が出てくるので、それを押すと
Windows Terminalが起動できる

複数のディストリビューションとか、普通にpowershellや、コマンドプロンプトとか、タブで切り替えて使える。

wsl -d ディストリビューション名

例)
wsl -d Ubuntu-24.04-my

補足:
このコマンドは、powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。
wslコマンドで、ディストロにログインします。
exitで出たら、また、powershellに戻ります。

上記コマンドで、対象のディストリビューションを選択してログインできる。
なのですが、毎回、
wsl -d ディストリビューション名
を打ち込むのは、めんどいので、
いつも、使うディストロが決まっているのであれば
wslと打ち込むだけで、そのディストロにログインできるようにしておきたい

そんなときは、

wsl --set-default <ディストリビューション名>

例)
wsl --set-default Ubuntu-24.04-my

補足:
このコマンドは、powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。

で、デフォルトのディストロを設定できる。
wslとだけ打ち込んだときは、デフォルトのディストロにログインすることになる。

wsl -l -v

補足:
このコマンドは、powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。

で現在、環境にあるディストロのリストが見れるがデフォルト指定したディストロには、

「*」記号がが付いて表示される。

また、
今どのディストロにログインしているのかわかりにくくなったら

wslpath -w .

を実行して確認している。
このコマンドはWindows用のパスに変換して表示するためのコマンドであるが
そのときのWindows用のパスは、その一部にディストロ名があるため
そのディストロ名を見れば、今、どのディストロにログインしているのかを
確認することができる。

例として
$ pwd
/etc/systemd
のとき

$ wslpath -w .
\\wsl.localhost\Ubuntu-24.04-my\etc\systemd

この\wsl.localhost\Ubuntu-24.04-myの部分を見て

Ubuntu-24.04-myのディストロにログイン中かと確認できる。

この、wslpath -w . は、カレントディレクトリについて

Windowsアプリが参照できるパスの形を返す。

エクスプローラーに貼り付けるような使い方もありかもしれないが

そもそも、カレントディレクトリについてエクスプローラーで開きたかったら

explorer.exe .

と打ち込めば、カレントディレクトリについてWindows用のパスで、
explorerが起動する。
私は、どうしても、explorerのスペルが覚えられない。
普通に打ち込んだらスペルミスをしてしまう。
( .exeまで必要であることなども、わかりにく、他のコマンドはそんなことないのに、
こいつだけイレギュラーで、そんなの覚えられない )
でも、大丈夫、
explまで打ち込んでタブを押せば
explorer.exeおよび、スペースまで入力補完されるので、後は.を後は打ち込んで
Enterキーを押せばよい。
むしろ、expl+TAB+.+ENTERで
「イーエックスピーエル、タブ、ポチ、エンター」の呪文ほうが
explorer.exeのスペルより覚えやすいとさえ、思っている。
( 完全に、私の特有の感覚の話ですけど )





ディストロのインストール

wsl -l -o

補足:
このコマンドは、powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。

でインストール可能なディストロの一覧を表示する。

LTSが付いてるもので一番、バージョンが高いものをインストールすればよいと思うです。

wsl --install -d <ディストリビューション名>

例)
wsl --install -d Ubuntu-24.04

補足:
このコマンドは、powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。

で、「wsl -l -o」のリストより、対象のディストロ指定してをインストールできます

インストール時に、初期ユーザ名とパスワードを入力する

この初期ユーザは、ユーザー名、グループ名が同じで

UID、GIDがともに1000で作成されたりする

WindowsのアプリからUbuntuの領域にファイルやフォルダを作成された時

この初期ユーザでの実行とみなされ、作られたファイルや、フォルダの所有者も

Ubuntu上では、この初期ユーザとなる。

上記のように、インストールしたディストロを直で使ってもよいが

個人的には、それはそのまま置いておいて、そこから別名で複製したものを

使うようにしてる。

一旦、exportしてimportするときにしか別名はつけられない



ディストロのexport／importなど

「Ubuntu-24.04」から「Ubuntu-24.04-my」を複製するケース
export/importしないと直接、ディストロの名前を、好きな名前に変更できない

補足:
powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。

エクスポートの例

wsl --export Ubuntu-24.04 Ubuntu-24.04.tar

インポートの例

wsl --import Ubuntu-24.04-my C:\MyWSL\Ubuntu-24.04-my Ubuntu-24.04.tar

この「C:\MyWSL\Ubuntu-24.04-my」は自分であらかじめ、そういうフォルダを準備し
指定します。わかりやすいフォルダ構成がよいでしょう

インポートすると、そこにHyper-Vの仮想マシンを表すファイルができてます。

消す場合の例

wsl --unregister Ubuntu-24.04-my

★これやると本当に消えてなくなってしまうから、慎重に！★
これを実行するとHyper-Vの仮想マシンを表すファイルが綺麗に消えてなくなってます。



wsl.confの設定変更時の参考ネタ

普通にインストールしたディストロをそのまま使ってる時はあまり気にしなくてもよい

その場合はWindowsが管理しているシステム系の深いフォルダ階層にHyper-Vの仮想マシンファイルがおいてあるなどする

また、wsl.confを特にいじらなくてもWindowsのNTFS領域を勝手にマウントしたり

ターミナル上で初期ユーザ―(インストール時)でログインしたりの設定になっていたりする

ただし、

*.tarファイルにexportして、importするときに、ディストロの名前を
Ubuntu-24.04からUbuntu-24.04-my
などに、名前を変更したようなディストロを使う時、
下記のようなwsl.confにしてないと、具合が悪かった
要するにwsl.confに設定を書いておかないと
WindowsのNTFS領域を勝手にマウントしたり

ターミナル上で初期ユーザ―(インストール時)でログインしたりの設定になってくれない

環境変数のPATHにWindowsのPATHの値を追加してくれるかどうかも、おそらくあやしかった

詳細は忘れてしまったが、それらを回避するため、wsl.confの設定を変更する必要があった

その件についてのメモ書き

例として
\\wsl.localhost\Ubuntu-24.04-my\etc
の
wsl.conf
を下記のようにしとく

myuserのところだけ、自分のユーザ名にしておく
Ubuntuをインストール時に初期ユーザがUID=1000、GID=1000で作られてたりするので
それを指定するようなイメージ

[boot]
systemd=true

[automount]
enabled=true
root = /mnt/
options="metadata,uid=1000,gid=1000,umask=002,dmask=002,fmask=002"

[user]
default=myuser

[interop]
appendWindowsPath = true

後続の★「npm installで固まる問題の対処」★
も行う、行ってるならば

[network]
generateResolvConf = false

も追記する

上記の記述内容にして

wsl --shutdown

補足:
このコマンドは、powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。

を実行し、設定を反映する

★★★★★★★★★★★★★★★★★★★★★★★★
＜追記＞ npm installで固まる問題の対処
★★★★★★★★★★★★★★★★★★★★★★★★
npm installで固まる問題があり、それの解決のため
https://memoryclip.uchiida.com/2021/12/wsl2_change_resolv_conf/
の情報を参考にした。

wsl.confに

[network]
generateResolvConf = false

を追加した
/etc/resolv.conf
が
/mnt/wsl/resolv.conf
のシンボリックリンクだったため
シンボリックリンクとしての、/etc/resolv.conf　を一旦削除したうえで
実ファイルとして、
/etc/resolv.conf
の中身を

nameserver 8.8.8.8
nameserver 8.8.4.4

とした。
これで、npm install は固まらなくなった

なお、ネームサーバーの
nameserver 8.8.8.8
nameserver 8.8.4.4
は、GoogleのDNSを使う方法のようだ。

これでどうして固まる問題が解消したかの詳細までは不明でござる
★★★★★★★★★★★★★★★★★★★★★★★★

他、豆知識
npmのバージョンを最新にしたい:
npm install -g npm@latest

プロジェクトの依存関係をインストールまたは更新したい:
npm install

キャッシュの問題でインストールが進まない場合にキャッシュをクリアしたい:
npm cache clean --force






新しいディストロ使いはじめるときdockerが使いたければ

新しいディストロ使いはじめるとき、そのディストロでdockerが使いたい場合は、
https://lazesoftware.com/ja/blog/230130/
のサイトで説明しているように、Docker Desktopの画面で、

設定の歯車マーク
↓
Resouce
↓
WSL Integration
で、
そのディストロを有効にして

そのディストロでDocker Desktopが効いて
dockerが使える設定にしておくことを忘れずにしておこう。


それから、当然のことながら
設定の歯車マーク
↓
General
で、
Use the WSL 2 based engine
にチェックが入ってる必要はあります。



新しいディストロ使いはじめるときなどに最新化しとく

新しいディストロ使いはじめるとき

sudo apt update
sudo apt upgrade

は、最初に、一度は、やっておいたほうがよさそう
新しいディストロ使いはじめるときなどにやっとく
新しいPC買ったら、更新して最新化すると思うが、そのイメージ

そのほうが後々に、作業時に環境トラブルになりにくいのではないか。



WSL-RemoteでVisualStudioCodeを動作させる件の話

VisualStudioCodeで作業フォルダとして開きたいディレクトリ
( たとえば、.gitフォルダがおいてるローカルのgitリポジトリのルートディレクトリ
などそこがソースコードが置いてる場所のルートディレクトリだったりするディレクトリ )
がカレントディレクトリの状況にて

code .

を打ち込んでVisualStudioCodeを起動する
VisualStudioCodeで、
Remote Development
のプラグインをインストールすると、このプラグインはパックになっているので、
WSL
Dev Container
Remote - SSH
Remote - Tunnels
などのプラグインもインストールされる。
それから、自分が今、VisualStudioCodeにインストールしている
他のプラグインも一通り見ていくと
「Ubuntu XXXXXにもインストール」みたいな青色のボタンが表示されているものが
あったりする。
※ Ubuntu XXXXXは、今操作してるディストロ名のことです。
それらは、ひとおおり、そのボタンを押して言って
今操作しているディストロでVisualStudioCodeを起動時に有効になるようにしていく
その後、
一旦、VisualStudioCodeを閉じて、
再度、

code .

で起動する
メニューで「表示」－「ターミナル」でVisualStudioCode上でターミナルを表示できるが
pwdで表示したパスが、
\\wsl.localhost\Ubuntu-24.04-my\ などからWindows用のパスでなく
/からはじまるLinux用のパスであること
や、
whoamiで、自分のユーザーを引き継いでるかとか
必要な環境変数などを引き継いでるかなど確認し
OKそうであれば、
WSL-RemoteでのVisualStudioCodeの起動ができてると思われる
これは何かというと、説明がめんどいのであるが
VisualStudioCode自体は、Windowsアプリであるが
Linuxを意識して、それで直で動くLinuxアプリのような動きをして
WindowsとLinuxの変換が発生しないような動き方で、動くことができてる
設定になってるかというような意味だと思われます。
厳密な意味は若干、間違ってるかもしれませんが、だいたい、そんな感じでしょう。



VisualStudioCodeの拡張プラグインの調子が悪いとき

~/.vscode-server
自体を削除する

cd ~
mv .vscode-server .vscode-server_backupYYYYMMDD

などでバックアップを取る形で消すか

rm -rf .vscode-server

などで「.vscode-server」を削除する

そのあと、ローカルのgitのリポジトリなどで

code .

でVisualStuioCodeを起動する。
各、拡張プラグインについて
「アンインストール」
「インストール」
「WSL: Ubuntu-24.04-my にインストール」
の順で押しなおす
青色の！マークが出てるかもしれないが、実際には
なおったりする

以上、なにかの、おまじないか、儀式のような。
手順であるが、これで治ったりしている。
こんなん、覚えられないから、ここに書くことにした。



Linux版のGitKrakenのインストール (Windows版ではないよ)

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★ \\wsl.localhost\Ubuntu-24.04-my などからはじまるWindowsパスで
★ Ubuntu領域をアクセス時に、大量のファイルや、フォルダにまとめて処理をすると
★ 重たいです。
★ そのため、Ubuntu領域にあるローカルのgitリポジトリに対して
★ Windowsアプリのsourcetreeを使った場合に、大規模gitリポジトリの場合に、
★ 固まってしまい使い物にならないです。
★ 残念ながら、Linux版のsourcetreeのアプリはありません。
★ そのため、Linuxアプリで、Linuxのパスを意識して動作するもので
★ sourcetreeの代わりとして使えるアプリが必要だった。
★ 上記の流れより、Linux版のGitkrakenのインストール方法や
★ Linux版のGitkrakenを使っていく際の考え方を書いてます。
★ ( Windows版のGitkrakenの話ではありませんし、それはネットに沢山、情報あります )
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

WSL2側にgitリポジトリおいてる時、sourcetreeだと大規模gitリポジトリだと
重たく、固まってしまい、使い物にならない。

その代わりとなるものとして、
Linux版のGitKrakenをUbuntu環境にインストールしておく
Ubuntuに日本語フォントも入れて文字化けしないようにしておく

インストール作業に入る前に、ダウンロードしてくるファイルについて
使ってるマシンに応じて、選択する必要がある。

通常のPCやラップトップ（64-bit）: gitkraken-amd64.deb
wget https://release.gitkraken.com/linux/gitkraken-amd64.deb

ARMベースのデバイス: gitkraken-arm64.deb
wget https://release.gitkraken.com/linux/gitkraken-arm64.deb

古いPCや特定の32-bit環境: gitkraken-i386.deb
wget https://release.gitkraken.com/linux/gitkraken-i386.deb

のように自分のマシンを考慮し、調整が必要。

wgetでダウンロードしたファイルをカレントディレクトリに保存する操作が
あるので、/tmpなどに移動してから作業を行うのがよいだろう。

そのうえで、

sudo apt update && sudo apt upgrade -y
sudo apt install -y libasound2 libnotify-bin libnss3 gvfs xdg-utils libsecret-1-0

wget https://release.gitkraken.com/linux/gitkraken-amd64.deb

sudo dpkg -i gitkraken-amd64.deb
sudo apt --fix-broken install -y

sudo apt install -y fonts-noto-cjk
sudo apt install -y ibus ibus-mozc

ibus-setup
↑ これはいらんかも。

gitkraken

と打てば使えるはず


gitkrakenはWSLgという描画方式でlinuxアプリがGUIで動く

この描画は多少重いが、これは固定費用と考えることができる

毎月の家賃は決まった固定費用だが、光熱費などは変動費用であるイメージ

sourcetreeは、\\wsl.localhost\Ubuntu-24.04-my などからはじまる

Windows用のパスを見てる。Windows用のパスでUbuntu領域にアクセスすると

１つのファイルや、ディレクトリへの処理なら問題ないが、複数ファイルやディレクトリを

まとめて処理するような時に、大量だと重たくなる

これは変動費用であるが、大規模gitリポジトリだとsourcetreeは固まって使い物にならない

そのため、固定費用としてのWSLgによる描画のコストを払ってでもGitkrakenのlinuxアプリを

Ubuntu(WSL2)にインストールし、linuxのパスを直接、見るため変動費用を抑える考え方

そのことで大規模gitリポジトリでも使えるようにしようという狙い

ただし、ブランチの切り替えをGitkrakenで行うと、大規模gitリポジトリの時に

クラッシュしてしまう報告があるとのこと

Gitkrakenでのステージングエリアへのファイルの追加、削除は問題になる可能性は低いとのこと

ですので、Gitkrakenは状況確認として、閲覧するだけとして、

変更操作は、ステージングエリアへのファイルの追加、削除だけにしておく

他の変更操作はすべて、ubuntuのターミナル上で、gitコマンドで行うような

使い方をするのがベストだろう

gitHubを対象にGitkrakenを使う分には無料で使うことができる

gitLabなどの他のリポジトリの仕組みを使いたい場合は有料となる




sourcetreeに「\wsl.localhost\Ubuntu-24.04-my～」などのパス指定時のエラーの解決方法

soucetreeに、
\\wsl.localhost\Ubuntu-24.04-my などからはじまるWindows用のパスで

ローカルのgitリポジトリのパスを指定すると、エラーが出る

その場合は、sourcetree上の「ターミナル」ボタンでgitbashを開く

もしくは、

ローカルのgitリポジトリのパスでエクスプローラーで一旦、開く

右クリックで「Open Git Bash Here」を押してgitbashを開く

git logとコマンドを打ち込んでみると

fatal: detected dubious ownership in repository at '//wsl.localhost/Ubuntu-24.04-my/XXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
To add an exception for this directory, call:

        git config --global --add safe.directory '%(prefix)///wsl.localhost/Ubuntu-24.04-my/XXXXXXXXXXXXXXXXXXXXXXXXXXXXX'

などのエラーメッセージが出る。

ここに示された

git config --global --add safe.directory '%(prefix)///wsl.localhost/Ubuntu-24.04-my/XXXXXXXXXXXXXXXXXXXXXXXXXXXXX'

のコマンドをそのまま、gitbashで打ち込む
( XXXXXXXXXXXXXXXXXXXXXXXXXXXXX の箇所なども含め、上記はあくまで例なので
実際には、その時、実際にgitBashで表示されたものをコピペする形で実行してくださいね )

gitbash上の--globalとして、safe.directoryの設定値を記憶させるような意味だと思う



その後、sourcetreeを一回、閉じて開きなおすとエラーがでなくなる

おそらく、sourcetreeが内部的に使ってるのがデフォルトではgitbashであろうが

そこに設定を記憶しエラーがでずにsourcetreeでも情報取得ができるようになる

ただし、sourcetreeをUbuntu領域のローカルのgitリポジトリに対して

「\wsl.localhost\Ubuntu-24.04-my～」などのWindows用のパス指定で

使う方法は、大規模gitリポジトリの場合は、処理が重たく固まって使い物にならないため

前述のGitkrakenを使う方式を検討するのがよいだろう






POSIX ACL

gitリポジトリなどソースコードを管理しているホスト側の領域を
dockerでバインドマウントしているとき、
dockerコンテナ内がrootでフォルダや、ファイルを作ってroot所有になったとき、
ホスト側の一般ユーザで、gitでブランチの切り替えや、プルしたときに、
root所有の箇所について、書き込みや、削除ができなくてエラーになってしまうのを回避したい
また、その領域をWindowsアプリで作業するときに、
一般ユーザーで作業時にroot所有になってしまってるところが権限エラーでできないと
作業しにくいため
gitリポジトリなどソースコードを管理しているルート領域に対して
末端まで権限付与の設定しておきたい。それができるのが、POSIX ACLである。
要するに、ls -lなどで見ることができる、
所有者、所有グループ、パーミンションがどうあれ、
問答無用で、権限付与が行えてしまうような仕組みであり、
しかも、ある基点のフォルダに1回設定してしまえば、配下にその後
作成されていく、ファイルや、フォルダにも適用される。
まさに、前述の★権限問題★の解決策として、有効に使える手段である。

POSIX ACL自体のインストール

sudo apt-get update
sudo apt-get install acl

下記の
/example/path/localGitDir
は、
自分の「gitリポジトリなどソースコードを管理しているルート領域」などを指定する

myuserは、自分の一般ユーザーの名前
mygroupは、自分の一般ユーザーのグループの名前
多分、wsl2のディストロをインストール時に初期ユーザを設定し
それを使うならば、UID=1000、GID=1000で
ユーザー名、グループ名同じになってたりして
それをそのまま指定するイメージで使う場合が多いと思われる

以下はmyUser:myGroupが、/example/path/localGitDirの配下
末端まで（その後、後から配下に新しく作られたファイルや、ディレクトリも対象に)
ls -lなどで表示される一般的なパーミッションに関係なく
rwxの操作についてフル制御で可能にするための設定を行うコマンドである

補足:
ローカルの開発環境なので「rwxの操作についてフル制御で可能」で問題ないでしょう
本番デプロイ時は、別のフォルダで「git clone」からやり直したまっさらな
最新の状態からデプロイ作業するなどして、
本番環境はセキュリティについて考えるので、こんなバカなことはしないです。
あくまで、ローカルの開発環境で★権限問題★を回避し
作業しやすい状況にすればいいですよね。という趣旨です。

それが、下記の、その１）、その２）、その３）である
POSIX ACLは指定したディレクトリに対して、カーネルレベルで、こういった
権限付与を行うための20年ぐらい前からある枯れた技術である
これを使うことで、dockerコテンテナでroot操作しroot所有になってる
ファイルやディレクトリが混在している状況でも、ホスト側の
一般ユーザーでgitのブランチ切替や、その他のファイル作成、更新、削除など
問題なく行えるようにするための設定を行うのが、趣旨である。
毎回、毎回、頻繁に sudo chown -R myuser:mygroup . を
ローカルのgitリポジトリのルートでしたくないからである
これをし忘れてgit操作などでエラーがでて不整合を直すなどの手間をかけたくないからである。
ここで紹介してるPOSIX ACLは一度、設定しとけば後は何もしなくてもよいからである。
なお、wsl2のディストロをインストール時に初期ユーザを対象に行うならば
UID=1000、GID=1000でユーザー名、グループ名同じになってたりするので、
その初期設定した一般ユーザでの作業を意識している場合は、
下記のコマンドでの、myUserとmyGroupは同じ文字列になったりするでしょう。
Ubuntu(WSL2)を開発で使うなら、むしろ、その状況が多いのではないか。
ですから、おそらく
下記のコマンドをメモ帳などにコピペして
myuserとmygroupのところについて、ご自身の初期ユーザ―などの
作業ユーザーの文字列に、置き換えて
/example/path/localGitDir
を、ご自身のローカルのgitリポジトリのルートフォルダ( 直下に.gitがあるフォルダ )
などのパスに置き換えたものを、そのまま、
ターミナルで、その１）、その２）、その３）の順番で
実行する形で作業してもらえればよろしいのではないかと思います。

その１)

sudo setfacl -Rm d:u:myuser:rwx /example/path/localGitDir

その２)

sudo setfacl -Rm d:g:mygroup:rwx /example/path/localGitDir

その３)

sudo setfacl -Rm m::rwx /example/path/localGitDir

この、その３）はumaskの影響が、その１）、その２）に対して効かないように
するためのものとして必要である。
ACLの設定していても、システムのumask値のフィルターがかかって、
設定が効かない箇所が部分的に発生してしまう
その３）のコマンドは、ACLマスク値の設定であり
それをrwxとしているということは、システムのumask値がACLについては、
一切、働かないようにするという意味である
これをしないとうまくいかないよ。
なお、このコマンドは引数指定した該当ディレクトリに対するACL設定への
ACLマスク値の設定をするコマンドであり
システムのumask値は変更しない。

getfacl /example/path/localGitDir

が、上記の、その１），その２），その３）
を確認するコマンドである。


getfacl /example/path/localGitDir

の実行結果が、下記のようになってたら、いけてる

# file: example/path/localGitDir
# owner: myuser
# group: mygroup
user::rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:myuser:rwx
default:group::r-x
default:group:mygroup:rwx
default:mask::rwx
default:other::r-x

上記のうち、myuserとmygroupの記述と

maskの設定の部分の下記の部分が肝である。

# owner: myuser
# group: mygroup
mask::rwx
default:user:myuser:rwx
default:group:mygroup:rwx
default:mask::rwx

また、設定を削除するのは、

sudo setfacl -b /example/path/localGitDir

である。

/example/path/localGitDirに対して設定すれば、

その配下の末端まで設定が適用される。その後、配下に新たに作成された

ディレクトリや、ファイルにも適用される

しかし、下記の注意事項を考慮する必要がある。

＜注意事項＞
設定したディレクトリ配下でchmodコマンドでパーミッションの変更操作をすると
その部分以降の末端まで、局所的にACLが効かなくなるとのこと
大元のディレクトリでACLの設定を消して、また、設定しなおせば、
その無効になった配下の局所的なエリアも含めて元に戻るとのこと
ACLを設定した配下のエリアでは、chmodの併用は避けるようにして、ACLでの制御に統一するか
どうしてもchmodが必要になった場合は、
大元のディレクトリでACLの設定を消して、また、設定しなおす
オペレーションをしてれば問題ない
もっとも、ACLでgitリポジトリ内でmyuserがフル制御できる状況ならば
chmodの必要性はないはずで、めったに考慮の必要はないはず






末端までの再帰的なgrep

Windows環境であれば、よくsakuraエディタのgrep機能で
基点となるフォルダ以降で、キーワード検索してましたが、

Ubuntu領域でそれをやると
\wsl.localhost\Ubuntu-24.04-my\ からはじまるようなWindows用のパスであり、
WindowsとLinuxの変換の関係で検索に時間がかかる

なので、Ubuntu上のターミナルでコマンドを打てばよい。

例として
キーワード：json_decode
対象ファイル : *.blade.php
末端のフォルダまで再帰的に探したいケースでは、
Ubuntu上のターミナルで、検索の基点となるディレクトリをカレントディレクトリとして

grep -r "json_decode" --include="*.blade.php" .

★Visual Studio Codeの検索機能でも代用できたかな★

補足:
厳密には代用できません。/vendorの内部などは、Visual Studio Codeの検索機能では
検索対象にならない。( 理由は不明 )
/vendorなどフレームワーク内部などが検索対象外だったりして、
その中身も含めて検索したいときもあります。
そういう検索対象外にする設定がVisual Studio Code側に便利だと思って
検索対象外にしているんでしょうが、その検索対象外となった箇所を検索したいときもある
そんなときは、ターミナル上で上記のコマンドで検索すればよいだろう。
そんな時には、一応、役に立つ。

説明
-r（--recursive）: カレントディレクトリから再帰的に検索します。
"json_decode": 検索する文字列です。
--include="*.blade.php": 指定されたパターン（この場合は *.blade.php）に一致するファイルだけを検索対象とします。
.で、カレントディレクトリを基点に検索します。

該当するファイル名だけを表示したい場合は
-rでなく、-rlとすればよい

grep -rl "json_decode" --include="*.blade.php" .

なお、末端まで再帰的ではなく、カレントディレクトリの直下だけ探したい場合は、
-rのオプションは不要で

grep "json_decode" --include="*.blade.php" ./*

でよい。



git mergeでエディタを起動しないようにする設定の話

git mergeするときに、マージする内容によっては、
gitは、マージに関するコミットメッセージを自動生成するのであるが、

そのマージに関する自動生成されたコミットメッセージの取り扱いで、

大枠、下記の a)、b)のいずれかの動きを行う設定がある。

  • a)
    マージ処理の途中で、エディタが自動で起動し、
    ユーザに下記の２択をしてもらう
    1、「編集し保存してエディタを終了」
    2、「変更せず、エディタをそのまま終了」
    このことにより、
    必要であれば、メッセージの変更が行える状況で、
    いずれにせよ。
    ユーザがエディタを閉じた後、
    マージ処理を続行し処理を完結させる設定。

  • b)
    a)のためのエディタ起動はせずに、自動生成された
    メッセージをそのまま適用する形で、
    マージ処理を続行し処理を完結させる設定。

の２種類の設定がある。

どうやら、この設定について、
Macと、Ubuntu(WSL2) では、
デフォルトの設定値が異なるようである。

Macは、デフォルトで、上記の b)になっている設定のようだ。
Ubuntu(WSL2)は、上記の a)になっており、しかも、
その時に起動するエディタの初期設定がnanoエディタとなっているようだ。

Ubuntu(WSL2)で、git mergeしたときに、下記のような出来事があった。

現在のブランチが、
feature/hanako/iikanji_no_task
のときに、

git merge develop_chot_iikanji
で、develop_chot_iikanji の内容をマージするときに、
マージする内容によっては、自動生成されたメッセージについて
nanoエディタが起動する。

私は、nanoエディタを使ったことがなく、

git mergeしたら使い方のわからないnanoエディタが、ターミナルの画面いっぱいに

表示されて、いきなり、なんですの？？

と、なりました。

nanoエディタから出られなくなって、あきらめて、ターミナルを「×」ボタンで閉じてしまいました。

すると、git mergeのプロセスが途中で中途半端な状態になってしまったようです。

再度、ターミナルを開きなおして、確認したところ、

期待通りのファイルがマージされていました。

だから、マージはうまくいったと勘違いしました。( ★これが間違いでした★ )

他のチームメンバーのプルリクが承認された分をマージで取り込みたかったので

gitHub上の承認済のプルリクの内容に、一致するソースコードのファイルが

ローカル上にありましたので、マージはうまくいったと勘違いしました。( ★これが間違いでした★ )

ファイルのマージはうまくいってたようですが

マージの途中プロセスで表示されたnanoエディタを

ターミナルごと「×」ボタンで閉じてしまったため

マージのプロセスが途中で強制終了された形となり、後続処理でするであろう

gitの内部的な管理情報の更新がうまくいっておらず、

ファイルは確かにマージされたが、gitの内部的な管理情報としては、マージされていない

ような状況となってしまいましたが、それに気づかず

そのまま、自分の分をコミットおよび、プッシュし、プルリクをだして、

最終的にそれが承認されて、develop_chot_iikanjiにマージされました。

その後、develop_chot_iikanjiでプルした時に、

私の１つ前の

他のチームメンバーのプルリクでのコミット分が丸ごと削除された

形になってしまいました。

最終的に、その修正のプルリクで対応したが、ご迷惑をおかけする結果となった。

この失敗をうけて、

下記のように、Ubuntu(WSL2)では対応しておくべきだと考えました

チーム開発してる際、Macユーザが b)のデフォルト設定で、
git merge しているんだから、git mergeの際は、自動生成されたメッセージをうけいれて開発作業をしている
だから、チーム内で「git mergeの際の自動生成されたメッセージ」についての
特別なルールや、決め事がなければ、
Ubuntu(WSL2)側も、b)の設定でよろしいであろう。

しかし、環境作った時に、b)の設定にしておくこと自体を忘れてしまってて
同様の失敗を繰り返すことが無いように、

１）

git merge --no-edit develop_chot_iikanji

常に「--no-edit」をつけておくことにしよう
さすれば、b)のモードで、途中でエディタを開くことがなくマージ処理が完結するとのことだ。

私は、記憶力があまりなく、どうせ、このようなコマンドは、
どこぞのメモ書きからのコピペ編集だから、そこのメモ書きに
「--no-edit」を書いとけば、コピペ編集の手間としては
たいして、変わらないから、それでよし
そのメモ書き自体を紛失しても、当サイトのここの記述に
アクセスすれば、問題なし

次に、

２）

git config --global core.mergeoptions --no-edit

を打ち込んで設定しておき
git config --global core.mergeoptions
を打ち込んだときに、
--no-edit
と表示される設定にしておけば
git mergeは、b)モードで動いてくれるとのこと

３）
ログインプロセスで読み込むようなシェルに

export GIT_MERGE_AUTOEDIT=no

を追記しておき
echo $GIT_MERGE_AUTOEDIT
としたときに、
no
と表示される状態にしておけば
git mergeは、b)モードで動いてくれるとのこと

上記、１）、２）、３）のどれか１つでもあれば、
git mergeは、b) のモードで動くが
念のため、全部、やっておいてもよろしかろう。
Macは、おそらく、２）、３）のいずれかが、
デフォルトで入ってるから、
デフォルトでgit mergeが b)モードで動くのではないか

そして、万が一にでも、gitコマンドで( git mergeに限らず )
エディタが起動することがあっても、
使い方がわからないnanoエディタが起動するのではなく
使い方を知ってるエディタが起動してくれるように

git config --global core.editor vim

をしておき
git config --global core.editor
と打ち込んだときに、
vim
と表示される状況としておき、vimエディタが起動することを期待したい
ただし、これは、本当に効いてくれるかは不明
もし、なにかの事情でgitコマンドから
エディタが自動起動されることが、もし、あって
そのとき、vimエディタが起動した
もしくは、残念ながらnanoエディタが起動した
その事象を見て、この記事の、
ここの記述内容をまた、更新することに、いたしましょう





git push時にPATトークンが求められる問題

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
１つ下の項目の
目次の項目の「PATトークンの入力なしで、git push可能にするため、Windows側の認証機能を間借りする方法」
で、Windows側の認証機能を間借りした形で、
git pushするようにしたら、PATトークンの入力を省略できることがわかりました。
なので、その方法でしたい人は、
目次の項目の「PATトークンの入力なしで、git push可能にするため、Windows側の認証機能を間借りする方法」
を参照してください。
そこに書いた方法で設定すれば、
gitBashや、Macのgitコマンドと同様に、PATトークンの入力なしで
git pushが可能な環境になるでしょう。

それでも、プッシュすべき内容物によってはPATトークンが必要になってしまう
こともあるのか？
その場合は、ここの項目も参考に読んでください
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

Ubuntu(WSL2)上でのgitコマンドでgit pushするときに、

パスワードが求められたときに、そこに、PATトークンをコピペ入力しないと

権限エラーでリモートへのpushができないことがある

remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/get-started/getting-started-with-git/about-（中略）
fatal: Authentication failed for 'https://github.com/XXXXXXXXXXXXXXX

上記のようなエラーメッセージが表示されて

リモートへのpushができない問題がある。

2021/08/13よりgithubのポリシーが変わったようであるが

なぜか、gitbashや、Macでのgit push時は、この問題が発生しないとのこと

その理由は不明である

ただ、Ubuntu(WSL2)上でのgitコマンドでgit pushするときには、

この問題が発生する。

その回避策としては自分のアカウントでgitHubのサイトにログインして

PATトークンを取得し、それをgit push時にパスワードを求められた時に

アカウントのパスワードの代わりに、PATトークンの文字列をコピペ入力すれば

git pushが成功することがわかっている

https://nlab-notebook.com/entry/2023/04/23/200000
にてPATトークンの作成方法が書かれている

https://qiita.com/ryomoucmei/items/ec8c225603ef983fc318
のサイトの情報も参考になる。
とりあえずは、repoだけのチェックでよいだろう

ただし、pushすべきものによってはrepo以外のものも必要な場合がある

fly.ioへのデプロイのために作成されたファイルをpush時に、

repoだけでは対応できないファイルがあり、repoだけチェックして作った

PATトークンでは、pushできない問題があった

そのため、workflowもチェックを入れたPATトークンを新たに取得し

そのPATトークンをアカウントのパスワードの代わりにコピペ入力したところ

git pushに成功したという経緯もあるので、ご参考にしてください



こんなことをしなくても、そもそも、gitbashや、Macのgitコマンドのように普通に

やってても、git pushができる方法を知ってる人がいたら教えてほしいぐらいである

がわかりました！！
すぐ下の、目次の項目の「PATトークンの入力なしで、git push可能にするため、Windows側の認証機能を間借りする方法」
に書きました。

PATトークンの入力なしで、git push可能にするため、Windows側の認証機能を間借りする方法

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
gitbashや、Macのgitと同じようにPATトークンの入力なしで普通に
git pushできる状態にするための設定を書いてます。
gitbashや、Macのgitも、OS側にある認証機能を使ってるのではないか
それと同様に、Windows側の認証機能を間借りする設定にすれば解決できました。
Ubuntu(WSL2)だけでは解決しようと設定すると困難（できるかもしれんが難しいものなど)
なものは、今回みたいにWindows側を間借りするような手立てで乗り切ればよいだろう。
認証処理だけの間借りなので、ほとんどパフォーマンスは低下しないはずである
このようにほとんどパフォーマンス低下しない事柄でのWindows側の機能の間借り戦略は
Ubuntu(WSL2)利用時のやり方として有効なのだろう
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

新しいディストロの環境でこの方法で試したら、
1度目からPATトークンの入力を求められなかったのを動作確認しました。

ですので、おそらく、ここに書いた方法で
Windows側の認証機能を間借りすれば、
gitBashや、Macのgitコマンドと同様に、PATトークンの入力なしで
git pushが可能な環境になるでしょう。

Windows環境にインストールされたGit for Windowsの認証の機能を利用することで
解決できる。
私の環境では既に、Git for Windowsがインストールされており
C:\Program Files\Git\mingw64\libexec\git-core
に
git-credential-wincred.exe
が存在した。
( インストールしていない人は、Git for Windowsのインストールを先にしてください )

そのうえで、Ubuntu側でターミナルで、
下記のコマンドを実行します。

git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/libexec/git-core/git-credential-wincred.exe"

「Program\ 」の\記号が気になるがこれは、隣のスペースをエスケープするために
Bashや、zshの仕様として入れとかなきゃいけないらしいです。

Ubuntuのターミナル上で、
スペースのエスケープのために上記で指定した\を除いたイメージのパスでls -lしたときに
ファイルがちゃんと見えていて、git操作を行う作業ユーザで実行権限があるのかどうかを確認してください
このあたりができてないと多分、うまくいかないとおもいますよ

ls -l "/mnt/c/Program Files/Git/mingw64/libexec/git-core/git-credential-wincred.exe"

ちなみに、上記の解除は、

git config --global --unset credential.helper

であり、

git config --global credential.helper

で何も表示されなければ解除できてるとのこと

現状では、
Ubuntu(WSL2)自体のgitの認証系は発展途上な様子で
Ubuntu単体で機能拡張しようとすると、aptパッケージマネージャでのインストール方法が
標準的に搭載されていない様子。
Windowsのものを間借りする方法が現実的な様子。

上記の方法は、Windows側のgit-credential-wincred.exeを通じて
WindowsのGitHubに対する資格情報にアクセスし、
認証を解決するので、PATトークンの入力を免除された形で
git pushを成功させる方法である。

★★★★★★★★★★★★
ファイル、ディレクトリへのアクセスはUbuntu側で行い
単なる認証処理の間借りであるため、
この間借りそのものでは、WindowsとLinux間の変換にまつわる
パフォーマンス低下はほぼ発生しないとのこと
★★★★★★★★★★★★



gitの「リモート追跡ブランチをローカルブランチ化」方法

ローカルには、まだ、存在しないが、他のチームメンバーが更新中のリモートにあるブランチを
ローカルにもってきたい。

つまり、「リモート追跡ブランチをローカルブランチ化」の件ですが、

https://note.com/llminatoll/n/na33651a6dc3e
にて、

リモート追跡ブランチをローカルブランチ化して、自由にコミット等の操作ができるようにしたいですよね。

と書いてあり
soucetreeでのやり方が書かれています。

Ubuntu(WSL2)での開発時は、おそらく、git変更操作は、ほぼ、gitコマンドで行うことになると思いますので
上記と同内容のことをgitコマンドで行う方法を、ここで紹介します。

リモート追跡ブランチをローカルブランチ化して、自由にコミット等の操作ができるようにしたいですよね。

というのが、まさにそれで、それができるようにしたい。
そのやり方です。

git remote -v

を打ち込んだときに、

origin  https://github.com/hogehoge/foo_bar.git (fetch)
origin  https://github.com/hogehoge/foo_bar.git (push)

みたいな表示がでてくるです。

https://github.com/hogehoge/foo_bar.git

の部分は、おそらく、同じだったりしてて
(fetch)、(push)で２行でてくるのですが
一番左が、originになってたら、( おそらく、originになってることが多いけど )
後述のコマンドのところは、「origin/」でいいんです。
そうじゃなくて他の値だったら、後述のコマンドの「origin/」の部分は、
「他の値/」に変えたやり方にするというのが、まず、注意点としてあります。

そのうえで、

まず、とりあえず、

git fetch --all

を打ち込んでおくのが、よろしいみたいです。( おまじない　です )

その後に、

git checkout -t origin/develop

「-t」で 「origin/」をつけるよ。「git remote -v」の結果がoriginでなく
他の値だったら「他の値/」をつけるよ。

とか

git checkout -t origin/feature/hanako/iikanji_no_task

「-t」で 「origin/」をつけるよ。「git remote -v」の結果がoriginでなく
他の値だったら「他の値/」をつけるよ。

などとすれば、「リモート追跡ブランチをローカルブランチ化」
で、

リモート追跡ブランチをローカルブランチ化して、自由にコミット等の操作ができるようにしたいですよね。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
(追記)
リモート追跡ブランチって何よ
とか、なんでフェッチするのとかがわかりにくいなぁと思ってたが

https://qiita.com/tatsuya_1995/items/4b8871709d3efe688400

こちらの記事が図解入りでわかりやすいと思った
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

が、行える状況となる

この「-t」のtは、tracking:追跡 の tだそうです。
「origin/」の部分は、前述の「git remote -v」が、originでなく他の値だったら
「他の値/」にするのは、注意のこと。

補足:
「git checkout -b」で「-b」は現在のブランチから作るので
コマンド打つときの、現在のブランチが重要ですが、
今回の「git checkout -t」で「-t」の場合は、
リモートを元に新しいブランチを作成してチェックアウトするコマンドで、
コマンドを打つときに、現在どのブランチにいるかは結果に影響しません

では、ここで紹介したやり方は、

どんな時に、必要か

  • 新しい環境で、git cloneしなおした状況
  • 途中、参加メンバーの環境構築時
  • 本番デプロイ作業に先立って、最新状態をまっさらな形でローカルに落としたい時

など、ではないか。

★★★★★★★★★★★★★★★★★★★★★★★★★★
★(追記)★★
★★★★★★★★★★★★★★★★★★★★★★★★★★
git cloneした環境が2つある前提で、
( 8080などのホスト側のポートを、7080、6080などに変えて並行で動作できる環境などにして )
下記のケースで使えました。

プルリクを出したが未だ承認待ちの状況で、
developから別のfeatureブランチを作って、別issueを先行開発中だった
承認待ちのプルリクであげたソースコードの一部も
先行開発で必要だったため、先行開発用のfeatureのほうに
ローカルだけで、追加するなどの環境調整しながら、先行開発していた

そんなときに、承認待ちのプルリクのレビューの指摘があり、
承認待ちのプルリクのfeatureでの対応の必要性が生じたが

1つのgitリポジトリの環境で、
先行開発用のfeature
と、
承認待ちのプルリクのfeature
でブランチを行き来して作業だと

一時的に、ローカルに環境調整してた分の調整などがあり
作業として、めんどい　ことになる

そこで、もう1個のgit cloneした環境側に、

承認待ちのプルリクのfeatureについて、
トラッキングモードで、
リモートからローカルに、落としてきたうえで
( ★ここで、当、目次項目の「リモート追跡ブランチをローカルブランチ化」が使える★ )
レビューの指摘対応の、
ステージング追加、コミット、プッシュをすれば

今、先行開発用で作業中の環境のほうでの
めんどい調整作業は不要で、
そのまま、作業を続行できる

考え方に気が付いた

このノウハウを視野に入れ、なるべく初期段階で
git cloneした環境が2つ作っておくというのも、有効な方法論だと思った

gitは、複雑なところがあるので、
1つのgit cloneした環境でやりくりするのが、大変で、めんどい
ところもあるので、こういう思考もありだな

と気が付きましたので、

ここに追記しておくことにしました。
★★★★★★★★★★★★★★★★★★★★★★★★★★

「新しい環境で、git cloneしなおした状況」は、
なにかの事情で、ローカルのgitリポジトリの位置を変えたとか
端末自体を変更したとか、まっさらな状態でgit cloneしたとき
ローカルにあるブランチをみたとき、main( もしくは、master )ぐらいしかなく、developすらローカルにはない

「途中、参加メンバーの環境構築時」は
途中、参加の人だから、まっさらな状態でgit cloneしたとき
ローカルにあるブランチをみたとき、main( もしくは、master )ぐらいしかなく、developすらローカルにはない

「本番デプロイ作業に先立って、最新状態をまっさらな形でローカルに落としたい時」の件ですが
各自のローカルでの開発作業は、いろんな諸事情で、
本番デプロイ用としてふさわしくないかもしれない
ide-helperなど、ツールのインストールでartisanバイナリや、composer.json, composer.lockなどが個人用になってるかもしれない

ステージングにも追加していない、テストドライバーや、スタブがローカルに残存していたり
いろんなタスクを並行して実行しているうちに、ローカルにゴミがあったりするかもしれない
なので、
本番デプロイ作業に先立って、最新状態をまっさらな形で、別のフォルダで、git cloneしてから
それを元にして、本番デプロイ作業をすべきではないか
当然、そのときは、
ローカルにあるブランチをみたとき、main( もしくは、master )ぐらいしかなく、developすらローカルにはない

★あ！！、本番デプロイだから、main( もしくは、master )だけ、あればよいのか！！★★

うーん、では、本番デプロイ時でなく

なにかの、疑似本番環境(結合テスト、システムテスト環境)などへの
デプロイ時のためなら、
developなどは、必要でしょう。



「developにて「git checkout -b」で同名のfeatureをローカルに一旦作ってプルで落としてくるやり方」との比較

1つ前の目次項目で、
gitの「リモート追跡ブランチをローカルブランチ化」方法
を紹介したが、

他にもリモートのfeatureをローカルに落としてくるやり方はある。
下記のとおり

git checkout develop_chot_iikanji
git pull origin develop_chot_iikanji
git checkout -b feature/hanako/iikanji_no_task
git pull origin feature/hanako/iikanji_no_task

のように
developにて「git checkout -b」で同名のfeatureをローカルに一旦作ってプルで落としてくるやり方

このやり方がよいという人がいる

この方法の＜メリット＞、＜デメリット＞は、下記のとおり

＜メリット＞

git checkout -b feature/hanako/iikanji_no_task
をしているため、必ず、今の最新のdevelopから分岐したfeatureで作業していることを明示できる

＜デメリット＞

リモートに上がってるfeatureが、今の最新のdevelopから分岐しているケースしか使えないやり方
たとえば、developのバージョンが10だったときに、
git checkout -b でバージョン10のdevelopから分岐したfeatureがリモートに上がってたとする
プルリクされた、そのリモートのfeatureが、なにかの事情で、しばらく放置されてたとする

他のプルリクがマージされ
developのバージョンが11や、12などに更新された場合
git checkout -b feature/hanako/iikanji_no_task
をすると、その11や、12のdevelopからローカルで、同じ名前のfeatureを作ることになる。

リモートのfeatureは、バージョン10のdevelopから分岐しているのに、
git pull origin feature/hanako/iikanji_no_task
をしたら、不整合になると思う。

この場合は、元々、プルリクを出した人に、ローカルで最新のdevelopをマージして
プッシュしなおしてもらわないと、できないような手順となっている。

たとえば・・・
過去に、プルリクまでしたが、なにかの仕様調整などで長期間、ペンディングになってたが、やっぱり、必要になったものがあったとする。
でも、当時の担当者は、もういないなどのときに、
別の担当者がリモートのそのプルリクをローカルに落としてきて続きの開発や調整がしたいとき、そもそもできない。

一方

gitの「リモート追跡ブランチをローカルブランチ化」方法
の目次項目で説明した
トラッキングでローカルに落としてくる

git fetch --all
git checkout -t origin/feature/hanako/iikanji_no_task

の方法での＜メリット＞、＜デメリット＞
は、下記のとおり

＜メリット＞

リモートに上がってるfeatureが、最新のdevelopから分岐したfeatureでなくても、いつでも、どこでもできる。
上記の「たとえば・・・」の例でも問題なくできる。
常に問題なく、リモートにあがってる分をローカルに落としてこれる。最強のやり方。

＜デメリット＞

上記のとおり、最強のやり方ではあるが、下記の注意点がある。

トラッキングでローカルに落としてきたもので最終的にプルリクをだして承認してもらってマージまで
してもらおうとする場合には、
最新のdevelopの内容をちゃんとマージして、git logで見た時に
最新のdevelopのコミットのチェーンが乗ってるかどうか気を配る必要がある。

git checkout -b feature/hanako/iikanji_no_task
で、最新のdevelopから分岐を明示的に強制するやり方ではないため、

「 最終的にプルリクをだして承認してもらってdevelopにマージしてもらうこと 」
目的とする場合は、
最新のdevelopのコミットのチェーンが乗ってるかどうか気を配る意識が必要。
その意識や、その注意を払う必要があるのがデメリット。

ただし、
単なる調査や、動作確認が目的でローカルで落としてくる場合は、

この意識は不要ですので＜デメリット＞は特にありません。

ローカル編集中の内容を元に戻す方法( git現在のブランチの最新リビジョン（HEAD）に戻す )

ローカルで編集中のファイルを、現在のブランチの最新リビジョン（HEAD）に戻す方法を書きます

ローカルのgitリポジトリのルートで、コマンド打ち込みますが
そこから見た時の、相対パスが
dir1/subDir1/fileA
のファイルに対して、行う例で、示すと

git checkout HEAD -- dir1/subDir1/fileA

です。

Javaをやってないとわからない話だがeclipse上で、
対象の編集中のファイルを右クリックし、
「チーム」メニューから「置換」を選び、その後「HEADリビジョン」を選択することで、
そのファイルを現在のブランチの最新リビジョン（HEAD）に戻します。
これと同じ操作をgitコマンドでする方法が、上記のコマンドです。

補足:
ステージングに追加してる、してないにかかわらず、使えるとのこと
ステージングに追加してたら、ステージングから外したうえでファイルの内容を
最新リビジョン（HEAD）に戻すとのこと
コミットまでしたファイルについては、最新リビジョン（HEAD）が変わるので
その状況では当コマンドは意味がないので、git resetなどを考慮する必要あり

Ubuntu(WSL2)とは、直接的に関係のない話かもしれないが
Ubuntu(WSL2)環境で開発するのであれば、gitはコマンド操作で、
ほぼ、すべてやり切る必要があるため当項目を追記しました。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
　プルと「git checkout HEAD -- なんとか」の関係性
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

まず、前提として

gitでのプルしようとしたときに、
「マージ」や「コンフリクト」という概念は
ローカルでコミット状態にあるものを対象にした概念である

プルしようとしたファイルと競合するファイルが
ステージングや、未ステージングにある場合は、
プルは単にエラーとなり、結果として、何も実行されない

この基本を抑えつつ

プルと「git checkout HEAD -- なんとか」の関係性
について考えていく

ケーススタディとして、

他の人が担当分の実装を暫定値での仮実装でも、
ローカルの未ステージング領域で変更したり、
追加しておかないと自分の実装が動作確認できないような時がある。

テストドライバーのような実装をローカルで準備し
自分の実装は動作確認する

しかし、そのテストドライバーのような実装は
自分はコミットや、プッシュをしないため

当然、未ステージングに置きっぱなしである

developのブランチに、いるときでさえ

未ステージングに置きっぱなし

そんなときに、

たとえば、

git pull origin develop_chot_iikanji

などでプルしたときに、
未ステージング領域と同じパスのファイルが、
リモートから取り込もうと試みてエラーになる

そんな時に、役立つ。
「git checkout HEAD -- なんとか」
なのである。

git pull origin develop_chot_iikanji

時に、

error: The following untracked working tree files would be overwritten by merge:
hogehoge/bar.blade.php

などのエラーメッセージでプルができない

そんなとき自分がテストのためにローカルで変更して、未ステージングにあったものについて、
本チャンの実装分が、来たということだったりする

そういうときに、

git checkout HEAD -- hogehoge/bar.blade.php

して、hogehoge/bar.blade.phpを元通りにしてから

再度、プルするとうまくいくのである

git checkout HEAD -- hogehoge/bar.blade.php
というのは、
現在のブランチのローカルの最新のコミット（HEAD）
に、hogehoge/bar.blade.phpを戻すという意味である
あくまで、ローカルの最新のコミット（HEAD）に戻すって
ことでリモートは関係ありません
ローカルの最新のコミット（HEAD）に戻ることで
未ステージングから消えます
それで、リモートからプルできる準備ができたということです。

その状況で、プルでリモートから取り込むので、今度はエラーにならないのである

もし、

git checkout HEAD -- hogehoge/bar.blade.php

の時に、

error: pathspec 'hogehoge/bar.blade.php' did not match any file(s) known to git

が出たりするのは、単に、gitは、そんなの知らない

と言ってる

それは、自分の実装の動作確認のため、周辺ものを、新たに追加( 変更ではなく )
してたものだったということだったりする

当然、ローカルのコミットにないわけで
gitは、そんなの知らない
と言っている

その場合は、純粋に、

rm hogehoge/bar.blade.php

で削除してから、プルをやり直すと、うまくいったりする

くれぐれも、いきなり、rmで削除するのはやめよう
gitが知ってるものをrmで削除すると
削除したという差分が、未ステージング領域に上がるため
これがまた、エラーの原因になる

git checkout HEAD -- なんとか

をやってみて、gitに知らないと言われたから
rmするという流れが重要である

＜＜俗っぽい言葉で言いなおすと＞＞
プルしてみて、怒られたものがあれば
gitが知ってたら元に戻してもらって、再度、プルする
知らないよと言われたら
削除してから、プルする

＜＜上記の作業をはじめる前の注意事項＞＞
ローカルに未ステージング領域で、テストドライバー関連の実装が混在してる状況などで
プルを成功させるまでの、やり方としては、たしかに
上記のやり方は効率がよい。
しかし、
その過程で、該当箇所のテストドライバー実装が無くなってしまうので
事前に、退避してから作業をしていたほうがよろしいかと思うです。
その理由は、周辺のそれらのテストドライバー実装の該当箇所の
本チャンの実装をしている担当者のプルリクが承認され、
それを取り込んだ後、自分の実装と結合しての動作確認を
する必要がある
そのとき、うまく結合動作しなかったときの調査として
自分が実装してた時に使ってたテストドライバー実装との
比較で、モジュール間のインターフェースが整合とれているかの
調査の役に立つからだ。
また、テストドライバー実装を保管して、それを
チームメンバーに共有しておけば、
はじめから、意図通りのインターフェースで実装してくれる
可能性が高まり、結合した時に、うまく連携して動作する
可能性が高まるはずで
そういったことに使えるテストドライバー実装が
プルを成功させるのに、効率がよいやり方のプロセスの中で
消されていく前に、退避しておくのがよいだろう
なるべく、自分の分が動作確認がうまくいって、
プルリクが承認される
この時点のテストドライバー実装を保存するのがよい
その途中に、他の人の分でプルするときに
怒られるなどして、なかなか、理想のタイミングでの
保管がかなわないかもしれないが、
めんどい、かもしれないが、何度も、世代管理で保管して
とんでしまわないように、また、できるだけ
直近のタイミングのテストドライバー実装が保管しておくように
注意を払えば、その時点の、保管を気にするのは、
たしかに、めんどいが
後で、楽ができるではないだろうか
★★★★★★★★★★★★★★★★★★★★★★★★★★★★

＜これが調べた理由＞
★★★★★★★★★★★★★★★
（理由１）
★★★★★★★★★★★★★★★
featureAについてのプルリクエストを出したが、まだ、レビュー中である
developより、featureBを作り、次のタスクを開始したい
そのときに、featureAの内容をローカル上で手作業でfeatureBに反映し
そのコードも利用して、featureBの作業をしたい
ところが、後々に、featureAのレビューがOKとなり、
developにマージされた後に、developをプルする。

developからfeatureBへのマージすることになるが
その前に、
先ほど、「featureAの内容をローカル上で手作業でfeatureBに反映し」

の部分を元に戻してから
developからfeatureBへのマージしないと不整合になるのではないか
と思われる。
このときに、元に戻す、操作をするために

developより、featureBを作った時点に、該当ファイルを元にもどしたい

それをやるためのコマンドとして、使えるものを調べたかった
★★★★★★★★★★★★★★★

★★★★★★★★★★★★★★★
（理由２）
★★★★★★★★★★★★★★★
単に、実装をしてて、大きく失敗したので、純粋に元通りにしたいときに
使えるのではないかと思ったから。
★★★★★★★★★★★★★★★

★★★★★★★★★★★★★★★
（理由３）
★★★★★★★★★★★★★★★
上記で、記載した
　プルと「git checkout HEAD -- なんとか」の関係性
のとおり
プルするときに、邪魔になる未ステージングのファイルを
効率よくどかして、プルを成功させる
手段として、非常に有効だから
★★★★★★★★★★★★★★★

git pullのエラーメッセージで判断できる

1つ上の目次項目の「ローカル編集中の内容を元に戻す方法( git現在のブランチの最新リビジョン（HEAD）に戻す )」にて、

くれぐれも、いきなり、rmで削除するのはやめよう
gitが知ってるものをrmで削除すると
削除したという差分が、未ステージング領域に上がるため
これがまた、エラーの原因になる

git checkout HEAD -- なんとか

をやってみて、gitに知らないと言われたから
rmするという流れが重要である

ということを書きましたが、
git pullのエラーメッセージを見ただけで

  • 「git checkout HEAD -- なんとか」をすべきもの
  • rmで削除すべきもの
    のいずれかが、わかります。

★★★★★★★★★★★★★★★★★★★★★★★★★★★
★ エラー内容を見て、対処方法を判別してしまう考え方 ★
★★★★★★★★★★★★★★★★★★★★★★★★★★★

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
その１）「git checkout HEAD -- なんとか」でよし　のエラー
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

error: Your local changes to the following files would be overwritten by merge:
    hogehobe/aaa.blade.php
    hogehobe/bbb.blade.php
    hogehobe/ccc.blade.php
Please commit your changes or stash them before you merge.

英語)
error: Your local changes to the following files would be overwritten by merge:
日本語)
エラー: 次のファイルに対するローカルの変更はマージによって上書きされます:

英語)
Please commit your changes or stash them before you merge.
日本語)
マージする前に変更をコミットするか、隠してください。

この場合に対処法

git checkout HEAD -- hogehobe/aaa.blade.php
git checkout HEAD -- hogehobe/bbb.blade.php
git checkout HEAD -- hogehobe/ccc.blade.php

★このコマンドを打ち込む前のタイミングにて、これがテストドライバーに該当時するなら
★保管しておいて、他のチームメンバーへのインターフェースの連絡や、
★後々の結合動作時の不具合調査のためのネタとすればよい
★という考え方ができる。

カレントディレクトリが、ローカルのgitリポジトリのルートフォルダ
でgit pullのコマンドを打ち込んでるはずだと思います。
なので、エラーに書かれている相対パスそのまま、コピペしてコマンド実行すればよい。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
その２）「rm なんとか」でよし　のエラー
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

error: The following untracked working tree files would be overwritten by merge:
    hogehobe/ddd.blade.php
    hogehobe/eee.blade.php
    hogehobe/fff.blade.php
Please move or remove them before you merge.

    hogehobe/ddd.blade.php
    hogehobe/eee.blade.php
    hogehobe/fff.blade.php

英語)
error: The following untracked working tree files would be overwritten by merge:
日本語)
エラー: 次の追跡されていない作業ツリー ファイルはマージによって上書きされます:

英語)
Please move or remove them before you merge.
日本語)
結合する前に、それらを移動または削除してください。

この場合の対処法

rm hogehobe/ddd.blade.php
rm hogehobe/eee.blade.php
rm hogehobe/fff.blade.php

★このコマンドを打ち込む前のタイミングにて、これがテストドライバーに該当時するなら
★保管しておいて、他のチームメンバーへのインターフェースの連絡や、
★後々の結合動作時の不具合調査のためのネタとすればよい
★という考え方ができる。

カレントディレクトリが、ローカルのgitリポジトリのルートフォルダ
でgit pullのコマンドを打ち込んでるはずだと思います。
なので、エラーに書かれている相対パスそのまま、コピペしてコマンド実行すればよい。

★★★★★★★★★★★★★★★★★★★★★★★★★★★

あと補足しとくと、git pullはエラーメッセージの最後に
Aborting　という文字を出力してます。
これは、結局、エラーがあるので何も変更しなかったという意味だと思います。

Ubuntu(WSL2)でもbrewコマンドは使える

linuxには、apt、yum、pacmanなどのパッケージ管理ツールがある。

どのパッケージ管理ツールを使うかは、linuxのディストリビューションによって異なる。

Macでのパッケージ管理はHomebrewでbrewコマンドのようです。



「Homebrew on Linux」をインストールすれば、Ubuntu(WSL2)でもbrewコマンドが使えます

たいていは、aptパッケージマネージャを使えば代用できるとは思うが

もし、Macユーザが環境構築方法をbrewコマンドを使った方法しか準備しておらず

brewが使えないとインストール困難なものが、もし、有った場合は

「Homebrew on Linux」をインストールしてから、brewコマンドでのインストール

すればよろしいだろう。

というわけで、ここでは、「Homebrew on Linux」のインストール方法を記述する

「Homebrew on Linux」は一般ユーザでのインストール作業となるため

rootにはならず、一般ユーザのまま作業をすすめる

brew --version

で何も表示されなかったり、エラーになったら未だインストールされていない
インストールするには、

sudo apt update
sudo apt upgrade
sudo apt-get install build-essential
/usr/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

を実行する。
sudo apt-get install build-essential
を先にやっておく必要があるとのこと。

/usr/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
を実行したときに、
下記のようなログが出力される
****
==> Next steps:
- Run these two commands in your terminal to add Homebrew to your PATH:
    (echo; echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"') >> /home/myUser/.bashrc
    eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
- Install Homebrew's dependencies if you have sudo access:
    sudo apt-get install build-essential
  For more information, see:
    https://docs.brew.sh/Homebrew-on-Linux
- We recommend that you install GCC:
    brew install gcc
- Run brew help to get started
- Further documentation:
    https://docs.brew.sh
****

上記のログより、拾ってくる形で

(echo; echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"') >> /home/myUser/.bashrc

を実行し、作業している一般ユーザーの環境変数を設定する。

あくまで上記コマンドはログで指示されたものを拾ったものを使う。

vim ~/.bashrc

で、
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
の行が追加されているか見て、
確認したら、保存せず閉じる

そして、

source ~/.bashrc

で、該当の環境変数の読み込みを行ったうえで、

その後、

brew install gcc

を実行すると

「brew install gcc」では、

/home/linuxbrew/.linuxbrew/bin

配下に

c++-14

cpp-14

g++-14

gcc-14

などのシンボリックリンクができる

これはbrewの中での何かのインストール作業に用いるためのものであろう

システムの

/usr/bin/gcc

/usr/bin/g++

とは、別個に「Homebrew on Linux」用として存在する形となる。



brew --version でバージョンが出てきたらインストールできてる

$ brew --version
Homebrew 4.3.9




Laravel環境で未実施のマイグレーションの扱い

自分が作成した状況、もしくは、他の人の承認済のプルリクを取り込むなどして
未実施のマイグレーションがあったとき、
現在のテストデータは、維持したいため、
php artisan migrate:fresh
や
php artisan migrate:fresh --seed
までのことはしたくない時など

php artisan migrate:status
と打ち込む。
するとどこまでのマイグレーションを実行したのかYes, Noでリスト表示される。
それで、冒頭で言ってる

自分が作成した状況、もしくは、他の人の承認済のプルリクを取り込むなどして
未実施のマイグレーションがあったとき
に相当するマイグレーションだけ、No
になってるケースなど
現在のテストデータは、維持したいたが、そのテーブルだけは
動作させるために定義したい

そんなとき
php artisan migrate
だけ実行しておく

再度、
php artisan migrate:status
と、先ほど、NoになってたマイグレーションもYesになって
該当のテーブルがDB上、定義されるだろう

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
＜追記＞：局所的にテーブルを作り直すオペレーションについて
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

php artisan migrate:rollback --step=1

「 php artisan migrate:status 」で見たテーブルのBatchのIdの1つ分、
取り消せるできる
( 該当テーブルの定義を消す )
「 php artisan migrate:status 」を再度見た時に、該当箇所がNoになる
再度、

php artisan migrate

したら
「 php artisan migrate:status 」を再度見た時に、該当箇所がYESになる。
該当のマイグレーションを他の人が変更してきた時で、
該当テーブルを作り直さないと動かないようなケースで、
局所的に、テーブル定義を再作成する

その後、今、作り直したテーブルについてシーダーがあれば

php artisan db:seed --class=HogeFooSeeder

(  HogeFooSeeder.phpがあり、DatabaseSeeder.phpのrun()に指定があれば。)

をすれば、作り直した該当テーブルについてのデータを再作成できるだろう。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

Laravel環境でのキャッシュクリア

Laravel関係で原因不明のエラーが出て、困ったときに
キャッシュのクリアをすると
解消されたことが何度もありました。

そのたびに、キャッシュをクリアするコマンドが何かをメモ書きしたものを
探したり、ググったりしてたのが、めんどいので
ここに書いておくことにした。

補足:
どういう条件かは、詳しくは忘れてしまったが
dockerコンテナ側をイメージのbuildからやり直して、起動しなおす
みたいなことをして、
それでも、ソースコードや、DB定義や値は、
ホスト側で、前のが保存されています。

そのような状況の時など、
他にも、再現パターンはあるかもしれないが

とにかく、キャッシュ内容が、現状の実態とズレているがゆえに
おかしくなって、意味不明のエラーがでるような事が
たまに、あったりする

そのときに、下記のコマンド群を片っ端から打ち込んだら
ほぼ、解消された。
それでも解決しなければ、
storage/logs/laravel.log
などを見て、出てるエラーでググって頑張るしかないですね。

php artisan config:clear
php artisan cache:clear
php artisan route:clear
php artisan view:clear
composer dump-autoload

★追記★
bootstrap/cache/packages.php
bootstrap/cache/services.php
を手動で削除しないと、問題解決しないケースがあります。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
ide-helperをインストール後
php artisan ide-helper:generate
などのコマンドを実行時
There are no commands defined in the "ide-helper" namespace.
のエラーになってしまう問題は、
AUTO-DETECTが効かない問題ですが
キャッシュが効いていて、反映されていないのが原因ですが
上記のコマンド群のうち、
php artisan cache:clear
で解消されるはずだが、それでもエラーが解消されないケースがあります。
これは、上記のコマンドで削除されるはずの
bootstrap/cache/packages.php
bootstrap/cache/services.php
が削除されないケースがあるからです。
その場合は、これらの2ファイルを削除すれば、
php artisan ide-helper:generate
などのコマンドが正常動作します。
実際、この問題でハマって、2ファイルを手で削除したら解決したことがありました。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

★追記★
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
１つ下の目次項目で
先に「composer clear-cache」をしてから「composer install --no-dev」をやっとくのが吉
を追加した
なので、「composer clear-cache」も一応はあることを心得ておくこと
ただし、これは「composer install --no-dev」する直前用なので
今回の趣旨とは違うだろう
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

各々の説明は、下記のとおり

php artisan config:clear
キャッシュされた設定ファイルをクリアします。次回アクセス時に、設定が再読み込みされます。

php artisan cache:clear
アプリケーション全体のキャッシュをクリアします。これにより、キャッシュされたデータが削除され、次回のアクセスで新しいキャッシュが生成されます。

php artisan route:clear
キャッシュされたルート情報をクリアします。これにより、新しいルートが次回のアクセスで再生成されます。

php artisan view:clear
キャッシュされたBladeテンプレートのコンパイル済みビューをクリアします。次回のビュー表示時に、ビューが再コンパイルされます。

composer dump-autoload
Composerのオートローダーを再生成します。新しいクラスやファイルが追加されたときに、これを実行してオートローディングに反映させます。





dockerを使って環境構築時は、
基本的には、永続化したい情報は、ホスト側においてることでしょう。
ソースコードや、composerでのインストール内容や、
MySqlのDBの定義や、設定値のバイナリファイルなど
こういったものは、バインドマウントなどの、その他、マウントでホスト側を見に行く
環境設定が普通だと思います。
だから、dockerコンテナ側を削除してbuildからやり直しても
基本的には、必要な情報は復元されていると思います。


なので、基本的には、ここまでの説明で事足りることが多いと思います。


ただし、何かの事情があり、ホスト側の配置場所が変わるなどして
最初から環境構築時など、DB情報が初期だったりして、
現段階のソースコードで動かしたときに、テーブル定義やデータがなくて
動かないみたいな話の場合、
マイグレーションや、シーダーを既に実装している状況であれば
少なくとも、.envの設定がなされてDBアクセスができる状況ならば
★.envの設定がなされてDBアクセスができる状況でないと下記のコマンドは動きません★

php artisan migrate:fresh --seed

にて、マイグレーションとシーダーを動かして
テーブル定義や、データを作り直せばよろしいでしょう



先に「composer clear-cache」をしてから「composer install --no-dev」をやっとくのが吉

もう、これはタイトル通りです
本番デプロイ時に、git cloneからやり直した綺麗な環境で、
composer install --no-dev
と「--no-dev」をつけて実行した
そのときに、
compose.jsonで
"require": {}にあるものだけインストールされる
"require-dev": {}にあるものはインストールされない
ことを期待した
しかし、"require": {}にあるものでインストールされないものがあった
composer showでインストールされたものを確認できるがそこになかった
composer clear-cache
をやってから
composer install --no-dev
したら、先ほど、インストールされてなかったものがインストールされた

なぜかは知らん。
（　いまいち、こういうところが安定感がないんだよな )
（　安定感がなければ、それでも安定する手順をメモって、そんなん覚えられんから )
（　毎度、このサイトからのコピペで乗り切るしかなかろう。 )

目次項目のタイトルどおり
これからは、

composer clear-cache

composer install --no-dev

の順番で実行する手順にしておけばよろしかろう。

Laravelでの画像のアップロードおよび表示のお作法

アップロード自体は、storage/app/publicの配下に行うのがお作法である
しかし、この領域は公開されていないため、公開領域への
シンボリックリンクを作成する必要がある。

php artisan storage:link

実行例)
# php artisan storage:link
The [public/storage] directory has been linked.

を打てばシンボリックリンクができる。
このコマンド自体が、
storage/app/public
のディレクトリに対するシンボリックリンクを
public/storage
で作ることだけをやる専用のコマンドである。
上記、コマンドを打ち込んだ後の環境においては、
storage/app/public/foo/bar/baz.jpg
のパスにアップロードなどで保存したのであれば、
public/storage/foo/bar/baz.jpg
というパスでシンボリックリンクを通じて、
公開領域のパスとして見える。
それを、*.blade.phpにて、imgタグで表示する実装としては、

<img src="{{ asset('storage/foo/bar/baz.jpg') }}" alt="baz">

のやり方になります。

補足:
http://localhost:8080/storage/foo/bar/baz.jpg
などのURLで「baz.jpg」の画像がブラウザ上で表示できる状況であり、
{{ asset('storage/foo/bar/baz.jpg') }}
が
http://localhost:8080/storage/foo/bar/baz.jpg
のURLを返し、それをimg タグの src属性に指定しているイメージである。

dockerコンテナ内部でのパスで
storage/app/public の絶対パスに対して、
public/storage のシンボリックリンクができるため
ホストマシン側でpublic/storageを見た時に、
中のstorage/app/public側にはいっていけない
ただし、ホストマシン側から、そこにファイルを置きたいケースがある
この時は、下記のようなコマンドを行う

docker cp <local_file_path> <container_name_or_id>:/var/www/html/laravelapp/storage/app/public

例)
例えば、WindowsのPC内の
C:\path\to\your\image.jpg 
を、WSL2環境のNTFS領域のマウントパス/mnt/cを通じたパスで
コピー元を指定するやり方で、
/mnt/c/path/to/your/image.jpg
として、行うの場合の例として

docker cp /mnt/c/path/to/your/image.jpg <container_name_or_id>:/var/www/html/laravelapp/storage/app/public/image.jpg

Ubuntuのext4領域がコピー元の場合は普通にLinuxのパスをコピー元に指定すればよい。

補足:
こんなことしなくてもバインドマウントしてる状況なら
普通にホスト側で
storage/app/public のほうを開けて、そこにファイルを置けた
と後で気が付いた


storageフォルダの所有者をapacheの実行ユーザにしておく

dockerコンテナ内のapacheの実行ユーザが
ユーザ名 : www-data
グループ名 : www-data
であることを確認したうえで、

# ps -ef | grep "apache"
root           1       0  0 01:05 ?        00:00:01 apache2 -DFOREGROUND
www-data      31       1  0 01:22 ?        00:00:02 apache2 -DFOREGROUND
www-data      37       1  0 01:52 ?        00:00:00 apache2 -DFOREGROUND
www-data      41       1  0 03:18 ?        00:00:01 apache2 -DFOREGROUND
www-data      42       1  0 03:37 ?        00:00:00 apache2 -DFOREGROUND
www-data      43       1  0 03:37 ?        00:00:01 apache2 -DFOREGROUND
www-data      44       1  0 03:43 ?        00:00:00 apache2 -DFOREGROUND
www-data      46       1  0 05:06 ?        00:00:01 apache2 -DFOREGROUND
www-data      47       1  0 05:06 ?        00:00:00 apache2 -DFOREGROUND
www-data      63       1  0 07:13 ?        00:00:00 apache2 -DFOREGROUND
www-data      78       1  0 07:24 ?        00:00:00 apache2 -DFOREGROUND
root          85      48  0 07:28 pts/0    00:00:00 grep apache
#
# id www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data)
#

storageフォルダに対して下記をしておく

# chown -R www-data:www-data /var/www/html/laravelapp/storage
# chmod -R 775 /var/www/html/laravelapp/storage

★これをやっておかないと、プログラムでアップロードしたファイルを保存できなかった★
この設定は、アプリで、アップロードの機能を実装する／しない　に関わらず
Laravelでの開発環境構築のお作法です
https://zenn.dev/tazzae999jp/articles/0934afe501db0c
の目次項目の
「storageディレクトリの所有者をapache実行ユーザにするのはLaravelの開発環境構築のお作法」
も参照のこと。

Laravelでアプリ開発者が作る*.js,*.cssの置き場所

アプリのルートからの相対パスで

public/css/foo.css
public/js/bar.js

のように配置する

*.blade.phpからは、

<link href="{{ asset('css/foo.css') }}" rel="stylesheet">

<script src="{{ asset('js/bar.js') }}"></script>

のように使うのであるが、ブラウザのキャッシュなどで反映されないことがあり
それを防ぎたい場合は
気のせいでした。他が間違ってました。そんなことはないと思う
めったにおきない

これは、別にやらんでもよさげ、
他が間違ってて、ハマった時にためしたが、
結局、要らんかったので、あんまり気にしなくてもよい

<link href="{{ asset('css/foo.css') }}?v={{ time() }}" rel="stylesheet">

<script src="{{ asset('js/bar.js') }}?v={{ time() }}"></script>

のように書けばよい。
このような方法を「キャッシュバスティング」というらしい。
そんなんせんでも、いけそう

Dockerネットワーク

今のあるものを一覧を表示する

docker network ls

「xdebug_network」というdockerネットワークの詳細を調べる

docker network inspect xdebug_network

「xdebug_network」というdockerネットワークを作成する

docker network create --driver bridge xdebug_network

「xdebug_network」というdockerネットワークを削除する

docker network rm xdebug_network

上記のように、あらかじめ作ったdockerネットワーク
xdebug_networkなどを
docker-compose.ymlに指定するなどして
アプリと、DBとか、アドマイアなど、コンテナ同士で全部接続しておく

Xdebugのリモートデバッグのために、アプリだけ接続すればよさそうに思えるが
全コンテナしとかないとエラーで動かない






XdebugのUbuntuへのインストールや、設定

情報:
ローカル環境でXAMPP ( Macの人はMAMPか )
でWindowsだけでのphpの開発環境作ってる時のXdebugのインストールや
設定方法については、
ネット上に情報が、既に沢山あると思いますので、それは割愛します。
ここで情報として書いてるのは、docker-compose.ymlとDockerfileを使った
LAMPなどのイメージでのdockerを使った開発で、Xdebugを使う時にどうするのか
ということに焦点をあてて書いてます。
何が書かれているのか、意味がわからなければ、まず、
XAMPPでのローカルでWindowsだけでのphpの開発環境作ってる時の
Xdebugのインストールや設定方法のところから
やり方を調べて、そこの基礎知識を理解してから再度、読んでいただければ
よろしいかと思います。

dockerを使った状態で、Xdebugを使うと
dockerコンテナとホストのリモートでリモートデバッグになるから
その通信路をdocker-compose.ymlで設定する必要がある。
事前に定義したdockerネットワークを用いて、通信路の設定を行う。
上述のxdebug_networkを使うイメージで、
が、dockerが自動的に使用するデフォルトのブリッジネットワークでよいので、
networksセクションの設定の記述は不要です。
ただし、アプリのコンテナにenvironmentセクションでXdebug用の設定を
記述する必要があります。

アプリのコンテナには、下記のものを追加する。

後でわかったがphp.iniの記載があれば
docker-compose.ymlでの追記は不要だとわかった。
＜php.iniの追記内容＞があれば不要   environment:
＜php.iniの追記内容＞があれば不要     XDEBUG_MODE: debug
＜php.iniの追記内容＞があれば不要     XDEBUG_CONFIG: "client_host=host.docker.internal client_port=9003"

＜php.iniの追記内容＞
xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_host=host.docker.internal
xdebug.client_port=9003
xdebug.log=/tmp/xdebug.log


**ここなくてもよい   networks:
**ここなくてもよい     - xdebug_network

他のDBとか、アドマイアのコンテナには、

**これは不要   networks:
**これは不要     - xdebug_network

を各々追加して
docker-compose.ymlの一番下に

**これは不要   networks:
**これは不要     xdebug_network:
**これは不要       external: true

を追加しておく



php.iniには、

xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_host=host.docker.internal
xdebug.client_port=9003
xdebug.log=/tmp/xdebug.log


後でわかったことだが、Dockerfileなどの環境構築プロセスで
RUN pecl install xdebug-3.1.6
などでインストールした後、
docker-php-ext-enable xdebug
をやれば、php.iniに、
zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so
を書く必要がない。
docker-php-ext-enable xdebug
は、インストールされたxdebug.soについてのシンボリックリンクを適切なところに
自動的に作ってくれるもののようだ。

xdebug.log=/tmp/xdebug.log
の設定により、/tmp/xdebug.logにログを書き込もうとします。
php artisan系のコマンド実行時などで、
Xdebug: [Log Files] File '/tmp/xdebug.log' could not be opened.
などのエラーメッセージがコンソールに出ることがあります。
★★  特に、実害はありません。 ★★
rm /tmp/xdebug.log
touch /tmp/xdebug.log
chmod 777 /tmp/xdebug.log
をすれば、このエラーはでなくなったりします。

他のXdebug関連のエラーメッセージがコンソールに出るのも実害がないことが多いです
ブレイクポイントで、デバッガーで止める気がなくても、
VSコード側でデバッガーを起動しとけば、エラーメッセージがでなくなったりします。

を追加するのであるが、

/usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so

は、dockerコンテナ側で使ってるphpのバージョンによって異なる
それは、Xdebugのwizardのサイトで確認することになる

Xdebug自体は、

pecl channel-update pecl.php.net

をやってから

pecl install xdebug-3.1.6

もしくは、

php.iniに
zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so
を書きたくなければ

RUN pecl install xdebug-3.1.6 && \
docker-php-ext-enable xdebug

などで、「docker-php-ext-enable xdebug」
も行う。
docker-php-ext-enable xdebug
は、インストールされたxdebug.soについてのシンボリックリンクを適切なところに
自動的に作ってくれるもののようだ。


後でわかったのだが、
pecl install xdebug
と、「-3.1.6」の部分を書かなくても今のphpのバージョンに則った
バージョンのxdebug.soがインストールされるようです。
Dockerfileに何かを追記するときは、一度、dockerコンテナ側で
該当のインストール作業などを手動でやってみて、
上手くいくやり方を見つけたうえで、Dockerfileに記述するのが、通常的なやり方です。
手動で、
pecl install xdebug
のようにしてみて、実際にインストールされた
/usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so
などのそのときの値をコンソールログより見つけて
それを、php.iniに記述する形です。
なにかの事情で、
pecl install xdebug
と、「-3.1.6」の部分を書かない方式で、うまくいかない場合は、
後述の「Xdebugのwizardのサイト」でphpinfo()をした結果ブラウザに表示された内容を
貼り付けて、「-3.1.6」の部分を割り出して、
「-3.1.6」の部分を含んだコマンドで試してもらえばと思います
はじめから、そうしてもよいです。

をやってインストールする
ただし、上記の例のxdebug-3.1.6の「3.1.6」の部分などは、
何にするかは、phpinfo()の内容をXdebugのwizardのサイトに貼り付けて確認する

https://xdebug.org/wizard
↑、が、「Xdebugのwizardのサイト」でphpinfo()をした結果ブラウザに表示された内容を
このサイトのテキストボックスに貼り付けて「Analyse my phpinfo() output」のボタン
を押すと、インストールすべきXdebugのバージョンや、インストール方法の案内が表示される

ただし、Xdebugのwizardのサイトで表示されたインストールの方法は、
C/C++のソースコードをmakeでコンパイル／リンクしていく方式で
xdebug.soを作ってそれを所定の場所に持っていくような
インストール方法でやり方が書かれている。
その方法は難しいため、「Xdebugのwizardのサイト」では、
xdebug-3.1.6の「3.1.6」の部分などのバージョンだけの確認にとどめる。
そして、
実際のインストールは上記のpeclを使ったコマンドで行うのがよいだろう。
そして、その「pecl install xdebug-X.X.X」でインストールした時の
コンソールに出力されたログの最後のほうに表示内容から
/usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so
の部分をコピペする形で、php.iniに記述する。
なお、php.iniの場所は、
dockerコンテナ内で、
php --ini
を打ち込むと確認できます。

そして、VisualStudioCodeのほうの
./vscode/launch.json
は、下記のようにする

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for Xdebug",
            "type": "php",
            "request": "launch",
            "hostname": "0.0.0.0",
            "port": 9003,
            "pathMappings": {
                "/var/www/html/example_app": "${workspaceFolder}"
            }
        }
    ]
}

上記の
"/var/www/html/example_app"
の部分は、
ローカルのgitリポジトリをバインドマウントしたときに、
.gitがあるリポジトリのルートのディレクトリについて、
コンテナ側のパスだと何になるかのパスの値を指定する
dockerイメージがLAMPのイメージをベースにしていたら、
/var/www/html/からはじまるようなパスだったりすると思われる。

https://marketplace.visualstudio.com/items?itemName=xdebug.php-debug
↑のプラグインをVisualStudioCodeへインストールする必要があると思う。





ide-helperのインストールおよび、設定

＜なんのためにするのか＞
Ubuntuとは直接関係ない話かもしれないが。

Laravelが動的に解決しているものについて

VisualStudioCodeの静的解析ツール「PHP Intelephense」が

静的に解決できない問題を解消したい。

そのため、実行には影響を与えないメタ情報のコードを出力する。

実行には影響を与えないメタ情報のコードを、

VisualStudioCodeが読み込むことでLaravelが動的に解決している

事柄を静的解析ツール「PHP Intelephense」のプラグインが、

静的に解決できるようになる。

そのことを通じて、

正味、実行時にエラーになる個所だけエディタ上で

怒ってくれるような環境や、コーディング時の入力補完が

ある程度、効いてくれるような環境を目指す。

例として、Laravelでエイリアス定義しているものは、

use文を書かなくても実行時にはエラーにならないから

静的解析ツールで怒ってほしくない

また、use文で書いてないそのようなエイリアスでも

静的解析ツールでの入力補完が効くようにしたりになったり

してほしいからである。

https://github.com/barryvdh/laravel-ide-helper
がide-helperの本家の場所

まず、

php artisan --version

でLaravelのバージョンを確認してください

php -v

でphpのバージョンを確認してください
その情報を見て、下記のどちらのコマンドを実行するか
決定してください

Laravelのバージョン: 10および11の場合
( PHP 8.1以上の場合。Laravel 10、11は、PHP 8.1以上である必要がある )

composer require --dev barryvdh/laravel-ide-helper:^3.0

Laravelのバージョン: 6.x、7.x、8.x、および9.x
( PHP 7.2以上の場合。
Laravel 6.xおよび7.xは、最低でもPHP 7.2が必要
Laravel 8.xはPHP 7.3以上
Laravel 9.xはPHP 8.0以上
)

composer require --dev barryvdh/laravel-ide-helper:^2.0



上記よりも、Laravelやphpのバージョンが低い場合は、
ide-helperは対応しません。（　残念ながら )


これは、dockerコンテナ内などで、ローカルのgitリポジトリのルートディレクトリで実行する

その後、下記のコマンドで
メタ情報のファイルを出力する


１）

php artisan ide-helper:generate

このコマンドで、
プロジェクトのルートディレクトリに
_ide_helper.php
が出力される。
すべてのファサードとエイリアスに関するメタデータが含まれます。
アプリの実行には影響がない
このファイルがあることで、「PHP Intelephense」が静的に理解できるようになる。

補足:
There are no commands defined in the "ide-helper" namespace.
のエラーになる場合は、
「Laravel環境でのキャッシュクリア」の目次項目を参照し、
bootstrap/cache/packages.php
bootstrap/cache/services.php
が消えてないケースは、手で削除することも、対応してください。



２）

php artisan ide-helper:models --nowrite

★こちらのコマンドは.envでのDB接続情報を通じてDBアクセスできる状況で★
★MySQLなどのDBのコンテナなどが起動中の時にコマンドを打たたないと正常に動きません★
このコマンドで、
モデルクラスを読み取って
Eloquentモデルに関するメタデータを含む
_ide_helper_models.php
を出力する
「PHP Intelephense」が静的に理解できるようになるためのものだと思われる。

補足:
There are no commands defined in the "ide-helper" namespace.
のエラーになる場合は、
「Laravel環境でのキャッシュクリア」の目次項目を参照し、
bootstrap/cache/packages.php
bootstrap/cache/services.php
が消えてないケースは、手で削除することも、対応してください。



３）

php artisan ide-helper:meta

このコマンドで、
プロジェクトのルートディレクトリに
.phpstorm.meta.php
が出力される。
これは、VisualStudioCodeのようなIDEで「PHPStorm」というものがあり
「PHPStorm」での機能と同様のことをVisualStudioCodeでもできるようにするためのプラグインの
PHPStorm Formatter
PHPStorm Snippets
などを利用するときに役に立つ
PHPStorm用のメタ情報が含まれてるようです。

補足:
There are no commands defined in the "ide-helper" namespace.
のエラーになる場合は、
「Laravel環境でのキャッシュクリア」の目次項目を参照し、
bootstrap/cache/packages.php
bootstrap/cache/services.php
が消えてないケースは、手で削除することも、対応してください。



４）
★注意★このコマンドは/vendor内部のLaravelのフレームワーク内部のソースコードの変更なので
やらないほうがよいという考えもあります。( 1ファイルのヘッダーコメントの追記ですが )
ですから、チーム内での方針でやるかどうか決定すればよいと思います
むやみに、この ４）のコマンドは実行しないほうがよいです。

php artisan ide-helper:eloquent

これを打ち込むと
～/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php
だけ1ファイルのヘッダーのコメントだけ、少しだけ追記される
Eloquentを使った実装時の入力補完などに役立つかもしれない

補足:
There are no commands defined in the "ide-helper" namespace.
のエラーになる場合は、
「Laravel環境でのキャッシュクリア」の目次項目を参照し、
bootstrap/cache/packages.php
bootstrap/cache/services.php
が消えてないケースは、手で削除することも、対応してください。

下記で、静的解析ツール用のメタ情報を出力したら
.git/info/exclude
( 個人別、無視リストに下記のように追加しておく )

/artisan
/.vscode
/_ide_helper.php
/.phpstorm.meta.php
/_ide_helper_models.php

ただし、この設定をしてもgitbashや、sourcetreeでは差分としてあがってファイルもある。
（理由は、知らない)
その件の対処法については、
後述の目次の項目の「.git/info/exclude (個人別無視リスト)の補足事項」を参照のこと。

/artisanは、ide-helperのインストールで、artisanのバイナリファイルが
更新されるようで、
sourcetreeや、gitのツールによっては差分としてあがってきてしまうことがあり
これを防ぐため
artisanのバイナリファイルをプッシュする必要などないと思うため
無視リストの追加でよい
/.vscodeは、launch.jsonなどの変更分が差分にあがらないようにするため

/_ide_helper.php
/.phpstorm.meta.php
/_ide_helper_models.php
については、上記のide-helperのコマンドで出力された
メタ情報なので、個人別無視リストに追加しておく

静的解析ツールをチーム内で使わない人もいたりする
その人たちには関係のない話なので
自分の個人だけ無視リストに追加しておけばよい。

だいたい、一度、設定しとけば、以後はやる必要はない
ただ、
２）

php artisan ide-helper:models --nowrite

★こちらのコマンドは.envでのDB接続情報を通じてDBアクセスできる状況で★
★MySQLなどのDBのコンテナなどが起動中の時にコマンドを打たたないと正常に動きません★
こちらについては、DB設計など、テーブルの構成が変わり
モデルクラスの実装がチーム全体で変わっていくこともあるため
時々、実行して最新化しておくのがよいと思います

以上

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
(追記)
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
VSコードのプラグインに、「Laravel Extra Intellisense」というものもあるが、これだけでは、
Laravelが動的に解決している部分についての赤ニョロを消すことができない。

dockerコンテナ側には、phpがインストールされているが、
ホスト側には、phpがインストールされていない構成では、

「Laravel Extra Intellisense」が無効となる警告がでて、機能しない

この場合、dockerコンテナ側には、phpのバージョンを調べて
それと同じバージョンのものをホスト側にもインストールする

「sudo add-apt-repository ppa:ondrej/php」のようなものでのインストール方式をとると
状況にあわせて、複数のphpのバージョンから、今、有効にしたいものを選択できるようになるらしい

ここでは、dockerコンテナ側のphpのバージョンが下記のとおり

＜ dockerコンテナ側 ＞


root@dae3300e6b85:/var/www/html/laravelapp# php -v
PHP 7.4.33 (cli) (built: Nov 15 2022 06:03:30) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Xdebug v3.1.6, Copyright (c) 2002-2022, by Derick Rethans
root@dae3300e6b85:/var/www/html/laravelapp#

であることを前提に、説明する

sudo apt update

sudo apt install software-properties-common

sudo add-apt-repository ppa:ondrej/php


apt list --upgradable

sudo apt upgrade


sudo apt update


sudo apt install php7.4 php7.4-cli php7.4-fpm php7.4-mbstring php7.4-xml php7.4-zip php7.4-curl php7.4-mysql

上記の結果

＜ ホスト側 ＞

$ php -v
PHP 7.4.33 (cli) (built: Sep 27 2024 04:14:06) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.33, Copyright (c), by Zend Technologies
$

ホスト側でも同じバージョンのphpがインストールされた
その結果、

「Laravel Extra Intellisense」が無効となる警告がでなくなり
「Laravel Extra Intellisense」での入力補完が多少なり効く形になった。

なお、

$ sudo update-alternatives --config php
There is 1 choice for the alternative php (providing /usr/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
* 0            /usr/bin/php7.4   74        auto mode
  1            /usr/bin/php7.4   74        manual mode

Press <enter> to keep the current choice[*], or type selection number:

での番号入力で、今、システムで適用されているphpのバージョンを選択できる

autoのほうはよりあたらいいバージョンがインストール時は、その新しいバージョンに置き換えられる
決まった固定のバージョンを使いたい場合は、manualのようである

上記の例では1種類しかないので、どちらを選んでも同じ

他、下記の補足説明が、2点あります。

＜補足その１＞
実行は、dockerコンテナ側のphpで動いてて、docker-compose.ymlや、
dockerコンテナ側のphp.iniや、ホスト側の「.vscode/launch.json」
Xdebugの設定をしておけば、デバッガーも動く（dockerコンテナ側のphpで動く)
あくまで、
ホスト側( 自分の場合は、Ubuntu(WSL2) )にインストールした、dockerコンテナと同じバージョンのphpは、Laravel Extra Intellisenseの入力補完などの解釈を効かせるためのものである。

＜補足その２＞
他、VisualStudioCodeで、dockerコンテナ側にアタッチして、dockerコンテナ内部を直で開くやり方もあるです。
この方法だと、
ホスト側( 自分の場合は、Ubuntu(WSL2) )にdockerコンテナと同じバージョンのphpをインストールしなくても
Laravel Extra Intellisenseの入力補完などの解釈を効かせられると思う
しかし、以前、VisualStudioCodeで、dockerコンテナ側にアタッチして、dockerコンテナ内部を直で開くやり方してると、
しばらくすると、dockerコンテナ内のアプリの挙動が、めっちゃ遅くなってしまう問題が発生して
断念した経緯がありますので、この方法は使えない

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★




.git/info/exclude (個人別無視リスト)の補足事項

上記にて、.git/info/exclude (個人別無視リスト)に

/artisan
/.vscode
/_ide_helper.php
/.phpstorm.meta.php
/_ide_helper_models.php

を追加する件について記載した。
これをすると、
Ubuntu(WSL2)のgitに関しては、素直に反応して
git statusコマンドを打ち込んだ時に差分としてあがってこない
また、GitKrakenでも差分として表示されない

補足:
これを書いていた段階では、そうでしたが、
その後、別件で、「Ubuntu(WSL2)のgit」や、「GitKraken」でも
.git/info/exclude (個人別無視リスト)に登録しているものが
差分としてあがってくることがありました。
ですので、関係ないです。
タイミングの問題で、git側のキャッシュの諸事情などで起こる現象です。
で、そのgit側のキャッシュのクリアは現時点ではおススメしてない
その件は、この目次項目の一番下に注意事項として書いてます。



しかしながら、
sourcetreeとgitbashでは、この
.git/info/exclude (個人別無視リスト)
に登録すると、登録したファイルの多くは差分としてはあがってこないが、
登録されているのにも関わらず、差分としてあがってきやがるファイルがある
理由は不明である。
( Ubuntu領域をwindows用のパスで見てるなどの変換とかの影響でバグってそうなるのか？ )

しかし、それは、gitbash上で下記のコマンドを打ち込むと
gitbashでgit statusで差分としてあがってこなくなる
sourcetreeは内部的にgitbashを利用しているようなので
連動して、sourcetreeでも差分としてあがってこなくなる

git update-index --assume-unchanged ファイルのパス

で、強制的に差分として挙がらないようにできるとのこと
その「強制的に差分として挙がらないようする」を解除するのが

git update-index --no-assume-unchanged ファイルのパス

とのこと
「no-」が余分にあります。( 「強制無視の解除って」意味で、2重否定のようでわかりにくいですけど )

それで、ide-helperをインストール時に実際にartisanのバイナリファイルが更新されて
Ubuntu(WSL2)のgitや、Gitkrakenでは、.git/info/exclude (個人別無視リスト)に従って
素直に差分から消えたが
gitbashや、sourcetreeでは差分にartisanのバイナリファイルが残る現象があった
（　なぜ？　とか、理由は知らない )

git update-index --assume-unchanged artisan


.git/info/exclude (個人別無視リスト)の時と異なり、artisanの先頭に/記号が付いてないことに注意
通常の相対パスでの指定です。

のコマンドをgitbashで実行することで、
gitbashや、sourcetreeでも、差分としてあがらないようにできた

解除するのは、

git update-index --no-assume-unchanged artisan

と「no-」が余分にあるのを実行するとのことだが、これは試したことがない
実行すると強制無視が解除され差分としてあがってきます。





Discussion