5丁目通信(仮称)

とある5丁目で活動する還暦を過ぎたWebプログラマーの覚え書きです。それとかかってくる迷惑電話や、家業のアパート経営について。

タグ: Git

  • さくらインターネットのレンタルサーバーではGitを使わないほうがいいよとサポートから言われた話し

    Gitのリモートリポジトリは社内のQNAPのContainer Stationを使ってGitLabを立て使っています。そろそろこちらのGitLabが怪しいので、別のサーバーに移行しようと思っています。その前に簡単にバックアップできるようにリモートリポジトリを立てようかと思って、

    そう言えば今使っているさくらインターネットのレンタルサーバーでも使えるような話しがあったのを思い出して使ってみます。情報としては、

    とか

    とか

    とかでしょうか。どれもディレクトリを作って、git init –bareでいけるよと書いてあります。

    それでは簡単だからやってみようと言うことになり、やってみましたがpushでエラーになります。どうもさくらインターネットのgitにはlfsがサポートしていないようです。git lfs installとコマンドを叩くと、

    git: 'lfs' is not a git command. 

    となってしまいます

    何か解決策があるかもしれないと調べましたが、わからなかったのでさくらインターネットの聞いたところ回答としては次の通りでした。

    さくらインターネットのレンタルサーバーにはgitをインストールしているけど、ユーザーが使うのではなくて運用で使うためだけだから、本格的に使いたいのならVPSに移行して使ってね。

    さくらインターネットのレンタルサーバーでは、簡単なGitしか使えないようです。ちょっとガッカリです。

    さくらインターネットのVPSは以前使っていましたが、自分でOSをアップデートしなければならないし、いろいろと気をつかわなければいけないしで、運用が面倒になってやめてしまっています。GitのためだけにVPSを再契約するのも何だし、どうするか考え中です。

    さくらインターネットのレンタルサーバーでGitを使えるようになると、Webサーバー以外での使い道としてセールスポイントとなると思うけどな。甘いか・・・。

    著:湊川あい, 著:DQNEO
    ¥2,208 (2025/04/01 17:15時点 | Amazon調べ)
    著:リック・ウマリ, 翻訳:吉川邦夫
    ¥3,247 (2025/04/01 17:15時点 | Amazon調べ)
  • Windows11の累積更新プログラムKB5039212をインストールしたら、PCがお亡くなりになった話し

    今使っている自作のデスクトップPCに、Windows11の累積更新プログラムKB5039212を適用したら、USBのエラーでブルースクリーンになるようになった。USBの機器を外してみたけど症状は変わらない。しまいには、Windows11が起動しなくなった。

    仕方ないので、バックアップのThinkPadを使う。こちらにも累積更新プログラムKB5039212を適用したけど何もトラブルはない。この辺りは自作PCの嫌なところである。こちらのThinkPadは、デスクトップPCを回復させたので、バックアップと持ち出しモバイル用で使っている。

    一台では心許ないので、もう一つのWindows11が動いている、これまた自作のPCを確保しておく。まずはソースファイルが入ったディスクを移動する。

    次にメモリを移動してみる。移動先のPVCはメモリが16GBなので、お亡くなりなったPCから32GBのメモリを持ってくる。しかし、メモリを交換したらBIOSが起動する前のメモリチェックで引っかかる。これまた仕方ないので、今までの16GBのメモリに戻しておく。仕方ない続きである。

    Chromeが使いたいほどメモリを使ってくれるし、Adobeのアプリケーションも我が儘にメモリを確保してくれるので、16GBではアプリケーションが起動できないときがある。本来ならば32GBのメモリで動かしたいのだけどお亡くなりなったPCを戻るまで我慢して使う。

    主なファイルはDropboxに同期をしているし、文書関係はEvernoteに置いてあるし、作業のソースはGitにリポジトリにPushしている(お亡くなる寸前にPushしておいた)のでデータ関係はとくに問題はない。問題となるのはアプリケーションのほうである。インストールが面倒くさい。

    その前に、お亡くなりなったPCのWindows11の再インストールである。こちらは手間はかからないのだが、時間がかかる。

    マイクロソフト
    ¥14,900 (2025/03/31 11:56時点 | Amazon調べ)
    マイクロソフト
    ¥21,700 (2025/03/29 08:10時点 | Amazon調べ)

    自作PC用に一番左のWindows11のパッケージを実際に購入しましたが、問題なくインストールできました。Windowsは使うPCの分だけ正しくライセンスを購入しましょう。

    追記

    これでGitの設定をしてソースファイルの作業ができると思いきや、MicrosoftのOfficeアプリがないのでExcelのファイルの修正ができなかった。慌ててOfficeアプリをインストールし出す。そうしたら、AccessランタイムがインストールされているからOfficeアプリをインストールできないと怒られた。Accessランタイムをアンインストールする。

    追記(2024年6月26日)

    ThinkPadの方が、スリープ状態にしてしばらくするとブルースクリーンになる。今回のWindowsアップデートの影響なのかな?

  • シャットダウンしたらWindows11のPCが起動しなくなった話し

    電源を入れっぱなしのPCをたまにはシャットダウンしてから起動してみた。すると電源が入らなくなった。

    このPCはメインで使っているPCだけれど、電源が入らなくなるのは、よくあることである。だから電源を入れっぱなしにしているということもある。本当は対策を取らなければいけなかったのである。

    何回かATX電源のメインスイッチをオンオフをしてあげれば電源が入るのだけど、今回は電源が入ってもBIOSの画面が表示するだけである。どうもWindows11が起動できなくなっている。

    BIOSでは起動ディスクになっているM.2 SSDが見えているのだけど、起動デバイスの一覧にはない。どうもM.2 SSDは起動デバイスとして認識できていなようだ。

    Windows11を再インストールするのも時間かかるので、バックアップとして設定しているThinkPadのノートPCを使うことにする。こちらは壊れたPCと同じアプケーションをなるべくインストールするようにしている。ソースファイルやデータファイルはDropboxやGitのリモートリポジトリにあるので特にデータが消えたかと言う問題もない。ただし、ソースファイルはGitでCloneして来るのも時間がかかるので、壊れたPCのディスクをUSBケーブルで外部ディスクとしてGitのローカルレポジトリごとコピーしてしまう。USBの外部ディスクなので、結局は時間がかかったのだが、Pushしていなかったファイルもあったので、これはこれで正解だったかもしれない。

    HTMLで作成しているWebサイトの更新作業は、GitのSourceTree, DreamWeaver WinSCPなどのアプケーションをインストールしてあればいいのだけど、ASP.NETでのWebサイトを更新するには開発環境を再構築をする羽目になった。しかも、こんなときのお客さんからASP.NETのWebサイトの更新依頼が入った。

    お客さんには作業を待ってもらって、Visual Studio, SQL Server Management Studioなど必要な環境をインストールしておく。しかし、ソースファイルを丸ごとコピーしてVisual Studioのプロジェクトファイルを起動しても、なぜかASP.NETのプロジェクトとしてビルドできないようだ。原因不明である。たまたま、ソリューションファイルがあったのでビルドできて事なきを得た。

    やはり時間がかかったが、ようやくThinkPadのほうに作業環境が移行できた。こんどThinkPadが壊れたら手詰まりになるので、Windows11が起動できないPCを復活させておく。とりあえずはATX電源を注文しておく。

    PCは壊れるものなので、特にSSDは突然壊れるので、バックアップのPCを用意しておくことは重要なのである。

  • error: RPC failed; curl 56 HTTP/2 stream 5 was resetでgit pushができなくなった話し

    突然、git pushができなくなってGitLabのリモートリポジトリにアクセスでき亡くなってしまいました。エラーメッセージは次の通りです。

    error: RPC failed; curl 56 HTTP/2 stream 5 was reset
    send-pack: unexpected disconnect while reading sideband packet
    fatal: the remote end hung up unexpectedly

    おそらくHTTPでアクセスしないでSSHですればいいのですけど、GitLabの設定が面倒なのでやっていません。

    次に以下のサイトにしたがって、http.postBufferの値を大きくしてみます。

    次のコマンドを実行してみます。

    git config --global http.postBuffer 524288000

    結果は変わりません。

    GitLabはQNAPのContainer Stationを使ってDockerのコンテナにしていますので、docker-composeのYMLファイルにgit_max_sizeとgit_timeoutを追加しました。

    GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.and-works.com'
        gitlab_rails['gitlab_shell_ssh_port'] = 2022
        gitlab_rails['lfs_enabled'] = true
        gitlab_rails['lfs_storage_path'] = "/var/opt/gitlab/gitlab-rails/shared/lfs-objects"
        gitlab_rails['time_zone'] = 'Asia/Tokyo'
        gitlab_rails['git_max_size'] = 524288000
        gitlab_rails['git_timeout'] = 300

    参考にしたのは、いろいろ辿り着いたこちらのサイトです。

    最初、コンテナを再起動しただけではだめでした。一度GitLabのコンテナを削除してから起動しないとgit pushができませんでした。

    しかし、QNAPのContainer Stationは、コンテナを削除すると、docker-composeのYMLファイルの設定から何やかんやらすべて削除してくれますので、最小限docker-composeのYMLファイルのバックアップを取っておきましょう。私は、docker-composeのYMLファイルをGitで管理していましたので大丈夫でした。

    QNAPのContainer Stationで、最初からdocker-composeのYMLを挿入してアプリケーションを作成し直しました

    以上で、無事にgit pushができるようになりました。本当ならsshでリモートリポジトリをアクセスできるようにすれば、このような設定の必要はないかと思います。

    ただし、設定しておかしいのは、以下のようなアイコンが表示されるようになって、ボタングレーになってしまったことです。

    起動、停止、再起動はチェックボックスを選択して上のボタンでできますが、docker-composeのYMLを編集できないの難点です。いろいろ情報を漁っていますが、なかなか解決方法は見つかりません。

    著:湊川あい, 著:DQNEO
    ¥2,208 (2025/04/01 17:15時点 | Amazon調べ)
    著:リック・ウマリ, 翻訳:吉川邦夫
    ¥3,247 (2025/04/01 17:15時点 | Amazon調べ)

    追記(2023年7月20日)

    今度は別のリポジトリで次のようなエラーがSourceTreeで出て、何もリポジトリの中を参照できなくなってしまいました。

    git status fatal: not a git repository (or any of the parent directories): .git

    さて、どうしましょう。これはリモートリポジトリの問題ではなくて、ローカルのリポジトリの問題のようです。

    仕方ないので、とりあえず再度リモートリポジトリからCloneしてみます。Pushしていないファイルもありますので、トラブルのあるリポジトリは名前を変えて残しておきます。

    結果としては、このとりあえずのCloneした対応がよかったようです。Cloneしたら元に戻りました。リポジトリの内容も参照できます。そして、Pushできなかったリモートリポジトリも元通りに正常になりました。どうしてか、よくわかりません。

  • Adobe Photoshopでgudeの名前の logファイルが生成されるのはバグだった話し

    いつしかgude-[日付].logというファイルができるようになりました。gitでコミットするととても邪魔です。削除しようとしても削除できません。Photoshopのアプリケーションがlogファイルを掴んでいるようで、削除するには一度Photoshopを終了させなければいけません。これはとても面倒です。なにかよい方法がないかGoogleさんに聞いてみます。

    photoshop gude log」で検索すると、一発で原因と対処方法がでてきます。原因はPhotoshopのバグだそうです。対処方法は、Photoshopを起動してからファイルを開けばいいそうです。しかし、これはDream Weaverで画像ファイルをオープンしているので、この対応は使えません。Adobeがバグを対応しなければ修正できないようです。それか前のバージョンに戻すくらいでしょうか。Adobeの対応待ちです。

    まあ、Adobe様のやることなので、こちらは待つしかないようです。

    続きはこちらから

  • 知らない間にSnoreToastというプログラムがインストールされていた話し

    Windows11のスタートボタンを押したら、おすすめのところにSnoreToastが最近追加されたと表示されていた。SnoreToastなんてインストールした覚えがないので気持ち悪い。

    気になってGoogleさんに聞いてみたら、何やらSnoreToastは通知アプリらしい。そしてGithubで公開されているオープンソースらしい。

    SnoreToastがどこにインストールされているかというと、Windows11のProgram Filesフォルダではなくて、node.jsをインストールしたフォルダの\node_modules\node-notifier\vendor\snoreToastだった。何でもnode-notifierをインストールすると、SnoreToast.exeもインストールされるらしい。Gulpのgulp-notifyをインストールすると、node-notifierもインストールされる。

    以上で、SnoreToastは怪しくないプログラムであるということがわかったけど、ちょっと気持ち悪いけど、いいことにしておいた。何か不正にアクセスされたかと思ったわ。

  • DreamweaverをいつでもやめてもいいようにVisual Studio Codeの環境を作ってみた話し。でも、まだDreamweaverはやめないけどね。

    いつでもDreamweaverをやめてもいいように、その替わりにVisual Studio Codeにできるように環境を作ってみた。でもまだDreamweaverは便利だからやめないけどね。

    現在作業しているサイト更新の案件では、大まかには以下のような流れで利用している。

    1. Redmineでチケットを発行する。
    2. git-flowのブランチで作業開始する。
    3. Dreamweaverで作業する。
    4. テストサイトにアップする。
    5. テストサイトでお客さんに確認してもらう。
    6. git-flowのブランチで作業完了する。
    7. 本番サイトにアップする。

    Redmineは普通にブラウザで行って本番アップも今まで通り、あとはVS Codeで完結したい。今まではDreamweaverのテンプレート機能に依存している作業があったが、それがなくなったのでDreamweaverを使わなくても作業ができるようになった。次の通りにVisual Studioの拡張機能を使ってDreamweaverでの作業の替わりの設定をしてみる。

    Gitは、コマンドを使わずに今までSourceTreeで行っていた。GItはあらかじめVS Codeで用意されているが、もっと便利にGitを使うためにも、以下の拡張機能をインストールしておく。

    ただし、いまメンテナンスをしているサイトのHTMLファイルは、文字コードがUTF-8ではなくシフトJISなのでGitで差分を見ると文字化けしてしまう。これは昔からやっているサイトなのでどうしようもない。UTF-8にしようと提案したけど、あえなく却下された。だってページがとても多いからコストがかかるからだってさ。

    git-flowも簡単に行うために次の拡張機能を利用する。同じ名前の拡張機能がいくつかあるので注意。

    結局はSource Treeのほうがわかりやすくて便利なことが確かである。Gitの作業はどれでやってもやることは同じなのであまり気にしないようにする。本当に難しい作業は、Gitのコマンドを叩かなければいけない。

    DreamweaverでもリアルタイムにプレビューしながらHTMLファイルを作成していくので、次の拡張機能をインストールしておく。

    HTMLファイルのプレビューの拡張機能はたくさんあるけど、こちらがよさそうだった。ただし、作業しているサイトのHTMLファイルは、共通のヘッダやメニュー、フッダにSSIを使っているので、SSIをサポートされていないので完璧にはプレビューできない。何か他によいプレビューの拡張機能があったら紹介して欲しい。でも、いまどきSSIで作っているという、とても古いサイトなのである。

    テストサイトのアップは、次のSFTPの拡張機能を使っている。

    Dreamweaverに合わせてアップロードのショートカットキーは、Ctrl+Shift+uに設定しておく。ショートカットキーを揃えるのは、マクロキーボードを使っているからである。このショートカットをキー一つに登録できるマクロキーボードは便利である。

    テストサイトにアップした後、すぐにテストサイトをプレビューできるように以下の拡張機能をインストールしておく。テストサイトのページのURLをお客さんに伝える必要あるので、すぐにテストサイトにアクセスできてアドレスをコピペできることが重要である。この拡張機能が見つからなかったら、自分で作るしかないかと思っていた。Visual Studio Codeの拡張機能はたくさんあるので目的のものはあるもんだなと思った。

    こちらもブラウザプレビューのショートカットキーとしてDreamweaverにあわせてF12にしておく。設定ファイルを次のようにすると、HTMLファイルの編集ウィンドウでF12を押せばChromeが起動して、テストサーバーにアップされたページが表示される。HTML Previewでできなかった細かい確認はここで行う。Chromeのアドレスに表示されたテストページのURLをお客さんに伝えて確認してもらう。

    {
      "open-php-html-js-in-browser.selectedBrowser": "Chrome",
      "open-php-html-js-in-browser.urlToOpen": "custom",
      "open-php-html-js-in-browser.documentRootFolder": "C:/<ドキュメントルート>",
      "open-php-html-js-in-browser.customUrlToOpen": "https://<テストサイトのドメイン>/${relativeDirnameDocumentRoot}/${fileBasename}"
    }

    以上で、Dreamweaverの代替でVS Codeで使うようにする設定は完了。

    しかし、Dreamweaverは、まだまだHTMLファイルの作成にとても楽だから、まだまだ使っていくつもりである。リンクのアドレスとか、テーブルの処理とか、最終更新日の自動記入とか、まだまだ細かいHTMLは断然Dreamweaverのほうが使い勝手がよい。この辺りのHTMLエディタとしては、Visual Studio Codeは頑張っても勝てない。

    アドビ税とかアンチでDreamweaverを嫌っている尖った人たちが何だが多いけど、便利なものはお金を支払っても使っていこうと思う。ちなみに、Dreamweaverは単体で契約している。あとPhotoShopも単体で契約している。

    追記(2021年5月11日)

    DreamweaverとPhotoshopを単体で契約していたけど、アマゾンでAdobe Creative Cloud コンプリートが安かったので買ってしまった。単体と200円も毎月違わなかったから即買いだった。

    追記(2021年6月3日)

    SFTPでファイルのアップロードがNo such fileのエラーでできなくなっていた。対処方法を調べてみると、行き当たったのはこちらのサイト。

    このサイトの記事通りにsftp.jsに一行追加したらアップロードできるようになった。

  • 本日は作業環境のEmergency dayとした話し

    昨日はPCでブルースクリーンが出てもう駄目かと思ったけど、復活してよかった。

    しかし、万が一に備えて本日はエマージェンシーデイとした。要は、メインのPCが壊れても、そのまま作業が続けられるように、サブのノートPC(ThinkPad)でも同じ環境で作業できるようにしておく。

    メインのPCにつなげている4KのDELLのディスプレイをThinkPadにHDMIでつなげる。ディスプレイの設定でマルチディスプレイの「複数のディスプレイ」を「表示画面を拡張する」にして、ディスプレイの配置を上下並べるといい感じである。

    細かい作業をThinkPadの内蔵ディスプレイで行い、ブラウザやこのようなブログの書き込みは、外部の4Kディスプレイで行うととてもよい。贅沢を言えば、ThinkPadのディスプレイがタッチパネル対応だったら良かったにと思った。ディスプレイに関してはメインのPCよりも捗りそうである。

    ポインティングデバイスは、いつもはロジクールのM570というトラックボールを使っているが、今回は持ち出し用の小さなブルーレイマウスである。マススはトラックボールよりも手首に負担がかかるので、いつもの作業では使いたくないが、トラックボールを接続し直すのも面倒なのでマウスで行く。

    使っていくうえで問題なのはキーボードである。ThinkPadのキーボードを使うのがが、普段つながっている東プレのREALFORCEのキーボードに比べると明らかに入力ミスが多い。REALFORCEのキーボードをThinkPadに繋ぎ変えてしまえば問題なくなるのだが、こちらも我慢できる限りThinkPadの内蔵キーボードに慣らしていく。

    ちょっと良かったのは、この9キーボードである。

    Dream Weaverの機能のファイル保存・サーバーアップ・ブラウザプレビューや、切り取り&スケッチでのWin+Shift+s、PhotoShopの解像度の変更など、よく使うがキーの組み合わせが面倒なものをそれぞれのキーに割り当てている。このキーボードは、ソフトウェアではなくキーボードにキーの割り当てが保存されているので、ThinkPadにつなぎ替えればそのまま使えた。プログラム機能を持ったキーボードであるから、当たり前であるが気づいたら便利である。

    アプリケーションはメインのPCと同じものをインストールしておくことにしする。よく使うアドビやマイクロソフトのソフトののライセンスは、2台でも利用できるので問題ない。最近はPC1台しかインストールできないアプリケーションが少なくなっているのはありがたい。

    データはクラウドストレージで共有しておく。利用しているのは、DropboxとEvernoteである。こちらは同期を取っておけば特に問題ない。

    IMEは、ATOKからGoogle日本語入力に移行しているが、こちらは辞書や学習の同期ができないのはしかたない。辞書の学習は鍛えていくしかなさそうである。

    作業で必要なファイルは、GitLab経由でGitを使ってPull/Pushで同期をしているので全く問題ない。すなわち、一人共同作業である。ただし、メインのPCでの作業中にフリーズしてなんともできなかった場合に、Pushしてしていなかったら悲しいことになる。

    あとはGmail, Redmine, WordPressなどのWeb上のサービスは、PCが変わっても全く問題はない。こんなときのWebサービスは便利である。特にメールは、POPとかでメールを受信していると面倒になる。Webメールを使うか、最低限でもIMAPでメールをサーバーに保存しておいて参照にし行ったほうが、後々幸せになる。

    なにげに同期されて便利なのは、ChromeやEdgeの設定の同期である。拡張機能とかブックマークなどの設定が同期されて、どのPCでも同じ環境で利用できるのはすばらしい。Chromebookでも同じであろうから、Chromebookを使ってみても良いかもしれない。

    以上で、今日一日がんばってサブPCのThinkPadで頑張ってみようと思う。何か作業に支障をきたしたら対応をして、万が一に備えておく。

    続きはこちらから

  • Bitbucketの支払い明細がよくわからないからGitLabに乗り換えた話し

    今の仕事でPDFファイルとか画像ファイルがたくさんあるサイトの世話をしているのだけど、このサイトをgitでバージョン管理している。プログラムソースではなく、HTMLファイルとか画像もgitでバージョン管理していると何かと便利なのである。やはり、先祖返りを起こさない(複数でサイトアップしてしまっているから、厳密には難しいけど)し、昔のページに戻してとかの話しもたまにあるので、gitで管理するのはいいのである。

    さて、今まで使っていたのはアトラシアンのBitbucketだった。LFSで4GB近くのバイナリもレポジトリに入れていた。そうなると、無料プランでは無理で、有料のStandardプランのライセンスを購入していた。特にBitbucketの機能には不満はない。サーバーの運用も任せられるので安心して利用していた。

    しかし、メールで送られてくる支払いの明細をみたら疑問が出てきた。支払いのメールアドレスとBitbucketのログインのアドレスと違っていた。こちらは、運用のアドレスと請求のアドレスが別に登録されているかと思ったら違っていた。こちらは自分が悪いのだけど、2つのアドレスをBitbucketに登録していた。不思議なのは、請求のあったアカウントには有料プランのWorkspacesを所有していない。請求されていない方のアカウントに有料プランを登録しているWorkspacesが存在している。これはどうしてか?

    この辺りのWorkspacesって何かから調べて、アトラシアンのサポート担当者に聞いてみる。翌日の早い回答をくれたが、その回答はよくわからない内容だった。何かWorkspacesとクレジットカード記入と契約担当者の関係とかの、自分では理解できない難しいことを言っていた。

    この辺りは、既に理解不能に陥っている。そもそも、Bitbucketに登録したときにはWorkspacesなんてなかったので(昔だとTeam?)、Workspacesと課金の関係から理解しなければいけないようだ。でも、課金の体系が変更になるのであれば、丁寧に説明してくれないと困る。

    また別件の話しになるのだが、請求は毎月$15されている。レポジトリに5人のアカウントで使っていたので、$3×5人で$15だと思っていたら、実は違っていたようだった。アトラシアンのサポート担当者によると、Standardプランの最低限価格は$15ドルだそうだ。

    しかし、こちらのWorkspacesの設定からリンクされている料金表を見て1ユーザー$3と思い込んでいた。

    サポート担当者の説明だと、本来ならこの表の上にスライダーで人数を入力して価格シミュレーターがある価格表があるのだそうだ。価格シミュレーターだと1~5人でも$15になるそうだ。こちらを見てくれと言われた。

    おいおい、これはよくわからないぞ。重要な情報である価格表でこれでいいのか? 価格に関するすべてのページに、この価格シミュレーターが必要ではないか? だったら、大元の価格表だけにしないと、自分みたいな勘違いする輩が出るのではないのか?

    ついでに請求書もわかりにくい。Workspacesごとに有料プランに登録できるらしいけど、請求書の明細には有料プランではないWorkspacesも載っている。しかも、なぜかすべてのWorkspacesは載っていないという訳のわからなさ。どういった理由でWorkspacesを選択しているのか?

    だんだんBitbucketを使っていくのはめげてきた。課金体系には明確さが重要である。アトラシアンには不信感が残ってしまった。

    ということで、Gitのレポジトリサービスなんて、Bitbucket以外にもいろいろあるしねということになった。どのGitのレポジトリサービスにしようかと考えたら、QNAPのコンテナサービスにGitLabのDockerコンテナで実現することにした。こちらはGitLab公式のコンテナを使って簡単に動かした。最初からGitLabをインストールするなんてRubyの云々でいろいろトラブル起こすのが目に見えているので、簡単確実にGitLab公式のコンテナを何も変更せずに利用する。レポジトリの移行は、BitbucketからPullしてGitLabにPushすれば、こちらも簡単である。

    移行後は、Bitbucketの有料プランのWorkspacesに登録しているレポジトリを削除してStandardプランをFreeプランに忘れずに変更しておく。アトラシアンのサポートによると、これをやっておかないとユーザーをWorkspacesから削除してもそのまま課金されるそうだ。ただし、Workspacesの削除の仕方がわからなかったので、何もレポジトリが存在しないWorkspacesをそのままにしている。

    課金以外のBitbucketは満足していたけど、今回の件は残念だった。海外のサービスを自分のようなヤツが使うのは難しいのは実感した。だけどEvernoteとかDropboxとか使っているけどな。

    だけど、自分のところのQNAPでGitLabを動かすと、メンテナンスとか自分でやらないとけいけないので大変なのである。もっとわかりやすい料金体系のGitのサービスを探そうかな。

  • レポジトリのLFS対応を完了した話し

    こちらの記事の続きです。

    プログラムのソースというかHTMLのページがたくさんあるサイトをGitでバージョン管理しているのだが、レポジトリのサイズが1G超えてBitbacketのフリープランは扱いきれなくて、しかたないのでGitを自分のところのサーバーにインストールして使っていたけど、どうも遅くてストレス溜まるので対応してみた。

    サイズが大きいのは、何も考えずにPDFとかZIP、PSDファイルをレポジトリにぶち込んでいたのが原因で自分のせい。そもそもこのサイトはアホみたいにPDFファイルがあるからサイズが大きくなってしまう。

    そろそろGitのLFSでも使って見ようということで設定してみる。このリポジトリを始めた頃はLFSなんてなかったしな。やろうやろうと思って随分時間が経ってしまった。GitクライアントでSourceTreeを使っているけど、応答が遅くなってきた。

    参考にしたのは次のサイト。詳しい移行方法はサイトを見てね。

    Git の履歴からファイルを完全に削除する – git filter-branch | EasyRamble

    EasyRamble

    git filter-branchで過去の全てのcommitから画像ファイルの追加/変更をなかったことにしてリポジトリを軽量化する – dskd

    dskd

    git filter-branchでlfsに管理してもらうバイナリファイルの履歴を削除する。これでリポジトリのサイズが4分の1以下に減った。どれだけバイナリファイルをリポジトリに入れていたのやら・・・。

    これをBitbacketのレポジトリにpushしてお終いと思ったら、LFSの領域が1G越えた。Bitbacketのプランを課金してStandardにして対応。無事に完了。自分でサーバーを管理するのは辛いので、外に任せた方がいいわね。

    応答が速くなったかいうと、まだマシになったくらい。これってSourceTreeのWindows版のせいなのかな? コマンドでGitやるのは面倒だしな・・・。

    著:湊川あい, 著:DQNEO
    ¥2,208 (2025/04/01 17:15時点 | Amazon調べ)
    著:リック・ウマリ, 翻訳:吉川邦夫
    ¥3,247 (2025/04/01 17:15時点 | Amazon調べ)