12月23日PCゼミ
PCは本来はマウスなしで操作できる(キーボードのみで操作できる)。

ctrl + a 全選択

ctrl + f 検索　コマンドプロンプトでも使える　find

ctrl + d 上のセルを複製

ctrl + r リロード

ctrl + b 太文字

ctrl + w ブラウザのタブを閉じる

windows + v 過去の履歴からペースト

ctrl + shiht + v 書式を合わせてペースト
ctrl + enter 送信

ctrl + shift + t 閉じたブラウザを復元

ctrl + t タブを増やす

F4 直前の作業を繰り返す

Esp 編集状態にあるものをなかったことにできる

windows + shift + s 選択してスクリーンショット

shift + tab tabキーの反対側へ

alt + tab ウィンドウを移動

windows + ctrl + ←→　デスクトップを移動

gitでのペーストは shift + ins

これは、Visual Basic Advent Calendar 2020とSpreadsheets/Excel Advent Calendar 2020の23日目の記事となります。

はじめに

今の会社に転職して早3年が経ちました。多数のExcelファイルと秘伝のタレ的なマクロツールで業務が回っており、入社当初は「絶対にマクロを駆逐してやる！」とExcel撲滅を心に誓ったものですが、Excelマクロ開発を効率化するライブラリ作っちゃたり、VBAソースコードを簡単にGit管理する仕組みを作っちゃったりしているうちに、益々Excelマクロツールが増えてしまいました。
Excelマクロツールの増加に伴い、問題となるのがツールの管理。ユーザーに配布したツールのバージョンアップは頭痛の種。「バージョンアップしてね」とアナウンスしても、実際にユーザーがツールを使うまでバージョンアップする人はいないので、使う頃にはアナウンスのことなんか忘れており「なんか動かないんですけど」「それ古いバージョン使ってるからや」みたいなやり取りが頻繁に。
あまりにもExcelマクロツールの管理がしんどいので、バージョン管理や配布を効率的にやる方法を編み出してしまいました。

どうやるの？

基本的なアイデアは下記3点。
1. Excelマクロのロジック部分をアドイン化(*.xlamファイル化)し、ツール本体からはアドインを呼び出すだけの構成にする
2. 共有フォルダ上にアドインフォルダを作成してアドインファイルを格納、配布したツール本体から参照させる
3. アドインフォルダをGitで管理し、git pullで最新版を行う

つまり、Excelマクロツールを画面（＝ツール本体）と裏側のロジック部分（＝アドイン）に物理的に分離し、ロジックのみの更新時にツール本体の配布を不要にしよう、という作戦です。
以下、具体的な手順を書きます。

Excelマクロのロジック部分をアドイン化

Excelマクロをアドイン化する手順自体は複雑ではありません。ファイル保存時に拡張子を「Excel Add-in (*.xlam)」にするだけです。

ただし、アドイン化する際に注意点があります。

1. VBAプロジェクト名をツール名（もしくはツールのアドインであると分かる名前)に変更する。

VBAプロジェクト名は、後述するツール本体からアドインの参照設定を行う際、アドインの名称になります。

2. ツール本体にコードを極力残さないようにする（特にSheetモジュール）

ツール本体に残ったコードの修正時にツール本体の配布が必要になってしまうので、できる限りアドインの方に移してしまいましょう。せいぜいWorkbook_OpenやxxxButton_Clickなどのイベントトリガーと、その内部でのアドイン呼び出しやSheetからのツール設定値取得程度のコードのみ残すくらいに抑えましょう。

3. アドイン内でのThisWorkbookプロパティ参照が適切か注意する（大抵はActiveWorkbookの方が適切）

複数のExcelブックを取り扱うマクロでは、ツール本体のシートへの参照を確実に取得するためにSet sh = ThisWorkbook.Worksheets("Sheet1")とすることがありますが、このコードをアドインファイルに引っ越しさせるとThisWorkbookプロパティはアドインファイルを指すので、コードの動きが変わってしまいます。ツール本体のWorkbookオブジェクトはActiveWorkbookプロパティを使って取得するように変更しましょう。

4. アドインのバージョンをツール本体から参照できるようにする

ユーザーからの問い合わせの際にアドインのバージョンを報告してもらうなど、ツール本体からアドインのバージョンを確認できる手段を用意したほうがよいです。
まず、アドインにバージョンを記述するために、下記のようなAddinInfoモジュールをアドイン内に作成し、アドインのバージョンを定数で取得できるようにします。

AddinInfo.bas

Option Explicit
Public Const MODULE_VERSION As String = "2.2"

次に、ツール本体側にアドインのバージョンの定数を表示する機能を実装します。自分の場合は、下記のようにツール本体のシート上にアドインのバージョンを表記するようにし、Workbook_Openで自動更新するようにしています。

ThisWorkbook.cls

Option Explicit

Private Sub Workbook_Open()
    ThisWorkbook.Worksheets("Tool").Range("module_version").Value = AddinInfo.MODULE_VERSION
End Sub

アドインをGit管理

アドインファイルを作成したらGitHubやAzure DevOps上にGitリポジトリを作成し、アドインファイルをcommitしましょう。README.mdにアドインの使い方やリリースノートも書くようにすると良いです。
また、GitHub/Azure DevOps上でソースコードのDiffを見たりレビューしたりできるように、VBAのソースコードもcommitするとステキです。手前味噌で恐縮ですが、Azure PipelinesやGit ActionsのようなCI/CDの仕組みを使ってVBAソースコードを自動抽出・自動commitするようにすると楽ちんです。

ExcelマクロのVBAソースコードをAzure DevOpsでバージョン管理する方法

共有フォルダ上にアドインフォルダを作成

共有フォルダ上にアドインフォルダを作る時は、GitHub/Azure DevOps上のリモートリポジトリをgit cloneすればよいです。

powershell

cd <共有フォルダ上のアドイン置き場>
git clone <リモートリポジトリのURL>

アドインフォルダを作成した後に、1つやるべきことがあります。それはアドインファイル(*.xlam)を読み取り専用にすること。

アドインファイルは、それを参照するツール本体のExcelブックが開かれた時に、編集ロックがかかってしまいます。編集ロックがかかった状態だとアドインファイルの更新ができなくなってしまうので、ロックがかかるのを防止するために予め読み取り専用にしておきます。
アドインファイルが複数ある場合は、下記のようなPowershellコマンドを実行すればOKです。

アドインフォルダ配下の*.xlamを一括して読み取り専用にする

Get-ChildItem -File -Recurse <アドインフォルダのパス> -Include "*.xlam" | Set-ItemProperty -Name IsReadOnly -Value $true

逆に、読み取り専用属性を外す時はSet-ItemPropertyに渡す値を$falseにすればOKです。

アドインフォルダ配下の*.xlamから一括して読み取り専用を解除する

Get-ChildItem -File -Recurse <アドインフォルダのパス> -Include "*.xlam" | Set-ItemProperty -Name IsReadOnly -Value $false

ツール本体から共有フォルダのアドインを参照させる

ツール本体にアドインを組み込むには、Visual Basic Editorのメニューから[ツール]-[参照]を選択し、参照設定ダイアログで[参照]ボタンからアドインファイルを選択すればOKです。

ファイル選択ダイアログで、右下のファイルタイプのプルダウンから*.xlamを指定すれば、アドインファイルを選択できます。

アドインを追加すると、Visual Basic Editorのプロジェクトエクスプローラー上に表示されます。

git pullでアドインの最新化

アドインを最新版にアップデートする際は、共有フォルダ上のアドインフォルダにてgit pullすればよいです。
ただし、git pullの前後に読み取り専用属性の解除・再設定が必要なので、以下のような手順になります。

powershell

cd <共有フォルダ上のアドイン置き場>
Get-ChildItem -File -Recurse . -Include "*.xlam" | Set-ItemProperty -Name IsReadOnly -Value $false
git pull
...
Get-ChildItem -File -Recurse . -Include "*.xlam" | Set-ItemProperty -Name IsReadOnly -Value $true

上記手順を毎回タイプするのは煩雑なので、自分は以下のようなスクリプトを作って一括実行してます。

up2date.ps1

Param(
    [String]$Branch = "main"
)
$ADDIN_DIR = "."
Get-ChildItem -File -Recurse $ADDIN_DIR -Include "*.xlam" | Set-ItemProperty -Name IsReadOnly -Value $false
git checkout $Branch
git pull
Get-ChildItem -File -Recurse $ADDIN_DIR -Include "*.xlam" | Set-ItemProperty -Name IsReadOnly -Value $true

開発時と配布時でツール本体からの参照先を切り替える

アドインの修正を行う際は、GitHub/Azure DevOps上のリモートリポジトリ→開発用PCのローカルにgit cloneして修正を行いますが、テスト用のツール本体のアドイン参照設定をローカルのアドインファイルに変更する必要があります。
ここでハマりポイントがあるのですが、あるアドインファイルの参照設定を別のパスにある同じ名前のアドインファイルに変更しても、ツール本体を開き直した時になぜか参照先が元に戻ってしまいます。
例えば、MyAppアドインをM:\VBA_Addin\myapp\MyApp.xlamからC:\work\myapp\MyApp.xlamに変更した場合、ツール本体を開き直すと、MyAppアドインの参照先がM:\VBA_Addin\myapp\MyApp.xlamに戻ります。

回避方法は以下のように「アドインの参照を一度外してツール本体を保存・終了する」というステップを挟むとよいようです。

1. アドインの参照を一旦外してツール本体を保存→Excelを終了させる
2. ツール本体を再度開き、アドインの参照を変更先のアドインファイルに設定しなおす

毎回上記手順を行うのは煩雑なので、以下のようなBuildスクリプトを作ると楽です。

build.ps1

Param(
    [String]$TargetFile = ".\MyTool.xlsm",
    [String]$AddinDir = "."
)
# Key=アドインのプロジェクト名、Value=アドインのファイル名
$addins = @{
    "MyApp" = "MyApp.xlam"
}

$TargetFilePath = Convert-Path ($TargetFile.Replace('[', '`[').Replace(']', '`]'))

Write-Output "Build Excel Macro"
Write-Output "Target File: $TargetFilePath"
Write-Output "Addin Dir: $AddinDir"
Write-Output "Addins:"
foreach ($key in $addins.keys) {
    Write-Output "  $key : $($addins[$key])"
}
Write-Output "Remove old references ..."
$excel = New-Object -ComObject Excel.Application
$excel.Visible = $false
$excel.EnableEvents = $false
Write-Output "Open $TargetFilePath ..."
$book = $excel.Workbooks.Open($TargetFilePath)
$excel.EnableEvents = $true

foreach ($ref in $book.VBProject.References) {
    if ($addins.Contains($ref.Name)) {
        $addinName = $ref.Name
        Write-Output "Remove $addinName"
        $book.VBProject.References.Remove($ref)
    }
}
# 古い参照設定を削除するために、一旦Bookを保存してExcelを終了させる
$book.close($true)
$excel.quit()

Write-Output "Import addins ..."
$excel = New-Object -ComObject Excel.Application
$excel.Visible = $false
$excel.EnableEvents = $false
$book = $excel.Workbooks.Open($TargetFilePath)
$excel.EnableEvents = $true
foreach ($addin in $addins.keys) {
    $addinFile = Convert-Path ($AddinDir + "\" + $addins[$addin]).Replace('[', '`[').Replace(']', '`]')
    Write-Output "Import $addin from $addinFile ..."
    [void]$book.VBProject.References.AddFromFile($addinFile)
}

Write-Output "Update $TargetFilePath ..."
$book.close($true)
$excel.quit()

Write-Output "Build completed!"
exit 0

なお、上記スクリプトを実行するには、予めExcelのマクロ設定を変更し、プログラムによるVBAプロジェクトの参照を許可する必要があります。
やり方は、Excelメニューの[ファイル]から[オプション] – [セキュリティ センター] – [セキュリティ センターの設定] – [マクロの設定]を開き、VBA プロジェクト オブジェクト モデルへのアクセスを信頼するにチェックを入れればよいです。

雑感

ツールのロジック部分をアドイン化するようにしてから、メンテナンスがかなり楽になりました。ただ、まだ数十個近くあるツールのいくつかをアドイン化して運用している状況なので、手作業でのgit pullによるアドイン更新が回っていますが、全ツールをアドイン化した際には、アドイン更新漏れが発生するかもしれません。その際には、Azure PipelinesでSelf-Hostedエージェントを使った自動リリースとかやってみようかなーと思ってます。

GitHub Desktopを愛用しています。
すごく便利なツールなのですが、困ったことが起きました。
それは、GitHubで作ったリポジトリをクローンしようとしたときに、お目当てのリポジトリではなく、ほかのリポジトリがクローンされてしまうということなのです。

GitHub Desktopのバージョンは2.6.1です！

この症状は、以下のケースで起きるようです。

• GitHubにAというリポジトリを作り、それをクローン
• ローカルのAを削除
• GitHubのAをBにリネーム
• 新しくGitHubにAを作り、それをクローン
• なぜかAではなくBがクローンされる

この症状の原因がGitHub側にあるのかGitHub Desktopにあるのか切り分けるために、GitのCLIで同様のことをやってみましたら、問題なく期待どおりの動作となりました。
するとGitHub Desktopに何らかの問題があると推測できます。
ワールドワイドで使われているアプリケーションに、このようなベーシックな問題があるとは考えにくいのですが、ここは理性的に立ち向かうことにしました。

試行錯誤の末たどりついた仮説は、こんな感じです。

• GitHub Desktopは、リポジトリ名に何らかの識別子を作っている
• リポジトリ名が同じなら同じ識別子となる
• 識別子ごとに、GitHub側のリポジトリとURLを何らかの形で記憶している
• この対応は変更されない
• 同じリポジトリ名＝識別子なら、常に最初に記憶されたGitHubリポジトリ名とURLを使う

識別子ではなく、リポジトリ名でも同じかもしれません。
つまり最初に、「このリポジトリ名だったら、GitHubのこのリポジトリを引っ張ってくるからね！」というのが決まっていて、それはあとになっても変わらないのではないか？ということなのです。

いろいろ解決の策を練りましたが、手っ取り早いのはGitHub Desktopをアンインストールして、%%Profile%%AppData¥Roaming¥GitHub Desktop以下に残っているファイルもすべて削除、ということです。
根本的な解決にはなっていませんが、これでお目当てのリポジトリを無事クローンできました。

Aというリポジトリを作って試行錯誤的に作業していたけど、だいたいうまくいくようになったので改めてやり直したい。だけど保険のためにAを残しておきたいので、とりあえずBにリネーム、Aを新しく作り直す、というのはわりとあり得るケースだと思います。

もしかしたら同じくはまっている人がいるかも？ということで書いておきました。

記事が見つからなかったため備忘録。

gitで特定のファイルの差分の確認

$ git diff --FileName

特定のファイルだけのパッチファイル作成

$ git diff --FileName > name.patch

特定のファイルだけのdiffファイル作成

diffファイルだとファイル名などに依存しないためパッチを当てやすくて便利。

$ git diff --FileName > name.diff

パッチを当てる

$ patch -p1 < name.diff

はじめに

Git GitHubとは？

Gitとはファイルのバージョン管理ツールです。わかりやすく言うと、ゲームのセーブ機能みたいなもんだと思ってください！
そして、GitHubとはそのGitの情報をインターネット上にアップロードし、共有、編集がしやすいようにするサービスです。
どちらも今後コードを書いていく上で、とても便利ですのでぜひ活用してください。

GitHubはすべて英語ですがこの記事では、写真も豊富に付けているので問題なく進めていけると思います。

注意点

個人開発、初心者レベルの使い方を説明してます。
チーム開発や中級者以上で使うコマンド（branchやmargeなど）はこの記事では取り扱いませんのでご了承ください。
とにかく動かせることに重点を置いています。Gitの概念などの説明は省いております。
最下部の参考に細かい説明のリンクを張っていますので詳しく理解したい方はご覧ください。

Gitのダウンロード

さっそく使っていきましょう！
MacとWindowsでGitのダウンロード方法が異なります！

Macの場合

$ cd
$ brew update
$ brew install git

上記の手順が終わったら、以下のコマンドでインストールできているかどうかを確認します。

$ git --version

これで以下のような何かしらのバージョンが表示されたら大丈夫です！

git version 2.24.3 (Apple Git-128)

以上でgitのインストールは終わりです！

Windowsの場合

こちらの記事を参考に進めてください！
https://eng-entrance.com/git-install

GitHubの使い方

アカウントの作成
https://github.com/

いくつか質問されますが、適当で構いません！

この画面まで来たら

メールが来てるはずなので認証しましょう。

リポジトリの作成

create a repositoryをクリック！

もし、上記の画面が出てこない場合は右上の＋ボタンからNew repositoryを選択してください

リポジトリの名前は好きなように！
ただし、公開されます。
そのほかの設定は触らずにCreate repository

とりあえずここまで来たらオッケーです！

初回設定

そしたら、自分のアプリケーションフォルダにターミナルorコマンドプロンプトで入りましょう！
間違ってもdesktopなどでコマンドを実行しないようにしましょう。
自分のPCのフォルダが全世界に公開されてしまいます。。。

$ cd your_app_name

そのフォルダ内で下記を実行します。
push時にはGitHubへのログインを求められますので、ユーザー名とパスワードを入力してください！
（ちなみにパスワードは画面上に表示されませんが裏では入力されています）

$ git init
$ git add -A
$ git commit -m "first commit"
$ git branch -M main
$ git remote add origin YOUR REPOSITORY URL
$ git push -u origin main

YOUR REPOSITORY URLには自分自身のGitHubのURLが入ります。

ここからコピーできます。

以上で、GitHubへのコードアップロードが完了しました。
改めてリポジトリのページをリロードすると以下のように自分のコードが表示されているはずです！

2回目以降の公開方法

最初の設定は大変でしたが
今後、Gitへアップロードしたい時は以下の三つのコマンド（add, commit, push）を実行すればオッケーです！

$ git add -A
$ git commit -m "自由にわかりやすいメッセージ"
$ git push origin main

こまめにキリのいいところでpushしておくと、あとあと自分を救うことになりますよ！

新しいアプリケーションを公開したい

リポジトリの作成から始めてもらえればOKです！

活用法

他の人にコードを見てもらいたい！

いちいちファイルのスクショ何枚も送るなんて面倒ですよね！
そのままURLを送りつけちゃってください！他の人も同様にコードを見ることができます。

いろいろ機能付けたけど、上手く動かなくなってしまった。。。元に戻したい

addする前

$ git checkout .

add した後

$ git checkout HEAD 

commitしたあと

$ git revert HEAD

pushした後

$ git revert HEAD
$ git push origin main

まとめ

以上お疲れ様でした！
コードのバージョンをGitで管理し、GitHubでアップロード、共有する流れがなんとなく理解できていればオッケーです。
よきGitライフを！！！

参考

Gitを触り始めてからGitHubにpushするまでの流れを誰よりも丁寧に説明する
【Git入門】サルでも分かるGit入門の前に！Git使い方高速入門編【入門は5分で十分だと思います】
Git で変更を取り消して、元に戻す方法 (事例別まとめ)

Node-RED Advent Caldendar 2020 12/18の記事です。

Node-REDのフロー管理、どうしていますか？
私はフローファイルをgit管理するように最近なりました。

@high-uさん Node-RED Advent Caldendar 2018記事: Node-RED で git 使ってる？

そしてこれを毎回同じ品質で検証環境を立ち上げたいという主旨で、
もうやってるよ！という方もいらっしゃると思いますが軽くまとめて行こうと思います。

Gitレポジトリの準備

レポジトリは2つにしました。
1つのレポジトリにFlowを置いても良いのですが、今回はNode-REDで動くロボット学習キットのTJBotのVirtual版、VirtualTJBotプロジェクトの派生版で、ローカルで動くVirtualTJBot-starter-containerをサンプルに紹介します。

repository	説明
https://github.com/tjbotfan/virtual-tjbot-handson/	Node-REDプロジェクトのレポジトリ
https://github.com/tjbotfan/virtual-tjbot-starter-container	DockerFileを置いたレポジトリ

DockerFileを置いたレポジトリの準備

https://github.com/tjbotfan/virtual-tjbot-starter-containerでは、DockerFileの他にgit submoduleでNode-REDプロジェクのトレポジトリをリンクしています。

submoduleとすることでgit cloneしたときには手元に一緒に中身がダウンロードされるけれど、
git checkout時にはsubmodule内に影響されないという点が便利です。（Node-REDのフローはあくまでも別プロジェクトであり管理は別）

Submoduleと一緒に手元にレポジトリを持ってくるときは

$ git clone --recursive  https://github.com/tjbotfan/virtual-tjbot-starter-container

とします。

取得したあとのレポジトリは以下のようになります。

$ cd virtual-tjbot-starter-container/
$ ls -lR
.:
合計 8
-rw-rw-r-- 1 phadmin phadmin 1069 12月 23 02:17 Dockerfile
-rw-rw-r-- 1 phadmin phadmin  196 12月 23 02:17 README.md
drwxrwxr-x 2 phadmin phadmin  112 12月 23 02:18 node-red-settings

./node-red-settings:
合計 44
-rw-rw-r-- 1 phadmin phadmin   228 12月 23 02:18 README.md
-rw-rw-r-- 1 phadmin phadmin 29165 12月 23 02:18 flow.json
-rw-rw-r-- 1 phadmin phadmin     1 12月 23 02:18 flow_cred.json
-rw-rw-r-- 1 phadmin phadmin  1087 12月 23 02:18 package.json

あとはDockerfile上でCOPYを使ってflow.jsonをコピーするようDockerfile内に記述をしておくことで、
docker buildするたびにコンテナはNode-REDレポジトリからFlowを持ってきてくれます。

さいごに

Node-REDというよりもコンテナよりな記事でしたが、
Node-REDフローをプロジェクト化することで、バージョン管理がしやすくコンテナ化するときも便利に使えるということが、
まとまった記事って見かけないなと言うことで書いてみました。

欲を言うと、コンテナで起動したNode-REDからもNode-REDプロジェクトとして参照している状態に出来たらなどとも考えていますが、
これらはおいおいチャレンジして見たいと想います。

前提

タイトル通りbrew updateをしようとするとhomebrew-coreがshallow cloneだと出て動かなかった。
エラー文の解釈と解決方法についてのメモまとめたので以下に載せていく。
※筆者も勉強中のため間違いがありましたらご指摘いただけると幸いです！

Homebrewのバージョン

$ brew --version
Homebrew 2.6.1
Homebrew/homebrew-core (git revision 6ba53; last commit 2020-12-09)
Homebrew/homebrew-cask (git revision 02bd60; last commit 2020-12-10)

発生事象

brew updateをしようとすると下記のエラーが発生し出来ない。

$ brew update
Error: homebrew-core is a shallow clone. To `brew update` first run:
git -C "/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core" fetch --unshallow
This restriction has been made on GitHub's request because updating shallow
clones is an extremely expensive operation due to the tree layout and traffic of
Homebrew/homebrew-core. We don't do this for you automatically to avoid
repeatedly performing an expensive unshallow operation in CI systems (which
should instead be fixed to not use shallow clones). Sorry for the inconvenience!

エラーを解決

ここまで読んで「理屈はともかく早く治したい！」と言う方はエラー文にある通り下記のコマンドを打てば解決です。

-- 時間かかる...
$ git -C "/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core" fetch --unshallow

エラーの解釈

homebrew-core is a shallow clone. To brew update first run

『homebrew-coreはshallow cloneです。先に(下記のスクリプトを)走らせてください。』とあります。

shallow cloneとはGitの機能でこれを使えば最新版のコミットのみpull¹して来ることが出来ます。

(より正確に言えば任意の深さ(バージョン)の所までpull出来る機能です。)

※参考：How to Use Git Shallow Clone to Improve Performance

This restriction has been made on GitHub's request because updating shallow
clones is an extremely expensive operation due to the tree layout and traffic of
Homebrew/homebrew-core.

続きます。『この制限はGitHuBのリクエストによるものです。というのもshallow cloneの実行はツリーレイアウトやHomebrew/homebrew-coreのトラフィック量を考えるとかなりの高コストな処理になってしまうためです。』

ここからshallow cloneがダメになったのはGitHuBからの要請なのだ、と理解できます。

これについてはWhy shallow clone is expensive to perform?というGitHuB Discussion内に挙げられているリンク先の中でのコメントでより詳細に説明されています。下記にて筆者が重要だと思った箇所のみ抜粋します。

most of the initial clones are shallow, meaning that not the whole history is fetched, but just the top commit. But then subsequent fetches don't use the --depth=1 option. Ironically, this practice can be much more expensive than full fetches/clones, especially over the long term. It is usually preferable to pay the price of a full clone once, then incrementally fetch into the repository, because then Git is better able to negotiate the minimum set of changes that have to be transferred to bring the clone up to date.

一度shallow cloneしても後々のfetchで(depth=1オプションが使われることはないので)結局ドカンと全体が落とされる。それよりも最初にgit cloneでリポジトリ全体を取ってきて徐々にgit fetchで変化を埋めていく方がGitは得意だし負荷も低くなるとのこと。

さて、最後のエラー文を読んでいきます。

We don't do this for you automatically to avoid
repeatedly performing an expensive unshallow operation in CI systems (which
should instead be fixed to not use shallow clones). Sorry for the inconvenience!

『今回上記の措置をユーザーのため自動的に行わなかったのはCI(継続的インテグレーション)システムの中で繰り返し高コストなunshallowの処理を行うことを避けるためです。ご迷惑おかけしております<(_ _)>.』

自動で実行すると逆に負荷が大きいから手動でやってね、とのことでした。

---

1. pullとは簡単に言うと「リモートからローカルにコミットやファイルを引っ張ってしかもワークツリーにマージまでしてくれる」gitのコマンド ↩

本記事はZennにも筆者本人が転載済みです。

前提

タイトル通りbrew updateをしようとするとhomebrew-coreがshallow cloneだと出て動かなかった。
エラー文の解釈と解決方法についてのメモまとめたので以下に載せていく。
※筆者も勉強中のため間違いがありましたらご指摘いただけると幸いです！

Homebrewのバージョン

$ brew --version
Homebrew 2.6.1
Homebrew/homebrew-core (git revision 6ba53; last commit 2020-12-09)
Homebrew/homebrew-cask (git revision 02bd60; last commit 2020-12-10)

発生事象

brew updateをしようとすると下記のエラーが発生し出来ない。

$ brew update
Error: homebrew-core is a shallow clone. To `brew update` first run:
git -C "/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core" fetch --unshallow
This restriction has been made on GitHub's request because updating shallow
clones is an extremely expensive operation due to the tree layout and traffic of
Homebrew/homebrew-core. We don't do this for you automatically to avoid
repeatedly performing an expensive unshallow operation in CI systems (which
should instead be fixed to not use shallow clones). Sorry for the inconvenience!

エラーを解決

ここまで読んで「理屈はともかく早く治したい！」と言う方はエラー文にある通り下記のコマンドを打てば解決です。

-- 時間かかる...
$ git -C "/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core" fetch --unshallow

エラーの解釈

homebrew-core is a shallow clone. To brew update first run

『homebrew-coreはshallow cloneです。先に(下記のスクリプトを)走らせてください。』とあります。

shallow cloneとはGitの機能でこれを使えば最新版のコミットのみpull¹して来ることが出来ます。

(より正確に言えば任意の深さ(バージョン)の所までpull出来る機能です。)

※参考：How to Use Git Shallow Clone to Improve Performance

This restriction has been made on GitHub's request because updating shallow
clones is an extremely expensive operation due to the tree layout and traffic of
Homebrew/homebrew-core.

続きます。『この制限はGitHuBのリクエストによるものです。というのもshallow cloneの実行はツリーレイアウトやHomebrew/homebrew-coreのトラフィック量を考えるとかなりの高コストな処理になってしまうためです。』

ここからshallow cloneがダメになったのはGitHuBからの要請なのだ、と理解できます。

これについてはWhy shallow clone is expensive to perform?というGitHuB Discussion内に挙げられているリンク先の中でのコメントでより詳細に説明されています。下記にて筆者が重要だと思った箇所のみ抜粋します。

most of the initial clones are shallow, meaning that not the whole history is fetched, but just the top commit. But then subsequent fetches don't use the --depth=1 option. Ironically, this practice can be much more expensive than full fetches/clones, especially over the long term. It is usually preferable to pay the price of a full clone once, then incrementally fetch into the repository, because then Git is better able to negotiate the minimum set of changes that have to be transferred to bring the clone up to date.

一度shallow cloneしても後々のfetchで(depth=1オプションが使われることはないので)結局ドカンと全体が落とされる。それよりも最初にgit cloneでリポジトリ全体を取ってきて徐々にgit fetchで変化を埋めていく方がGitは得意だし負荷も低くなるとのこと。

さて、最後のエラー文を読んでいきます。

We don't do this for you automatically to avoid
repeatedly performing an expensive unshallow operation in CI systems (which
should instead be fixed to not use shallow clones). Sorry for the inconvenience!

『今回上記の措置をユーザーのため自動的に行わなかったのはCI(継続的インテグレーション)システムの中で繰り返し高コストなunshallowの処理を行うことを避けるためです。ご迷惑おかけしております<(_ _)>.』

自動で実行すると逆に負荷が大きいから手動でやってね、とのことでした。

---

1. pullとは簡単に言うと「リモートからローカルにコミットやファイルを引っ張ってしかもワークツリーにマージまでしてくれる」gitのコマンド ↩

この記事について

初学者による、UNIX・Git基本コマンドのメモです。
Ruby on Rails チュートリアル学習前の整理です。

• 【Progate】Command Line学習コース
• 【Udemy】 Git：はじめてのGitとGitHub

UNIX基本コマンド

ファイルの作成

touch ファイル名

ファイルの中身を表示する

cat ファイル名

ディレクトリを作成

mkdir ディレクトリ名

作業ディレクトリの移動

cd ディレクトリ名

# 1つ親のディレクトリに移動
cd ..

# ホームディレクトリに移動
cd

カレントディレクトリの確認

pwd

ディレクトリの中身を表示

ls

# 隠しファイルを含めたディレクトリの全中身を表示
ls -a

ファイル・ディレクトリの移動

# ファイルを移動
mv 移動させたいファイル名 移動先のディレクトリ名

# ディレクトリごと移動
mv 移動させたいディレクトリ名 移動先のディレクトリ名

名称を変更

# ファイル名を変更
mv 現在のファイル名 新しいファイル名

# ディレクトリ名を変更
mv 現在のディレクトリ名 新しいディレクトリ名

コピー

# ファイルコピー
cp コピーするファイル名 新しいファイル名

# ディレクトリコピー
cp -r コピーするディレクトリ名 新しいディレクトリ名

削除

# ファイルの削除
rm 削除するファイル名

# ディレクトリの削除
rm -r 削除するディレクトリ名

Git基本コマンド

共同開発の流れ

Step	作業	命令	コード場所
1	コードを変更	git add	ステージングエリアへ
2	共有準備	git commit	ローカルリポジトリへ
3	共有	git push	リモートリポジトリへ

【Gitで大事なこと】
共同開発では自分が行った変更を把握し
相手に共有すべき部分を選択できるようになることが大事

Gitの準備：ローカルリポジトリの新規作成

git init
initialize = 初期化

リポジトリ
ファイルやディレクトリの状態、変更履歴を記録する場所
"git init"コマンドでリポジトリを新規作成(gitディレクトリが作成される)
この中にファイルやファイルの変更履歴の情報が溜められていく

共有するファイルを選択

git add ファイル名

# 共有する全てのファイルを選択する
git add .

選択したファイルを記録する：コミットする

git commit
git commit -m "コミットメッセージ"

変更にメッセージに付けてリポジトリに記録するのがコミット
コミットすることで変更がリポジトリ内に時系列で記録される
ひとつの作業ごとに1コミット
（どの作業を何のためにしたのか、すぐ振り返られるようにしておく）

コミットメッセージ
ほかのメンバーが「何をどうして変更したのか」
分かりやすいメッセージを付ける

一行目：変更内容の要約（端的にわかりやすく）
二行目：空行
三行目：変更した理由

コミットしてしまったファイルを管理から外す

# ファイルごとGitの管理から削除
git rm ファイル名

# ディレクトリも一緒に削除
git rm -r [ディレクトリ名]

# ファイルは残す場合(gitignoreにも追記)
git rm --cached [ファイル名]

共有の仕組み

「リモート」という共有ファイルの置き場を使う
リモートにファイルをアップロードしたり
リモートからファイルをダウンロードすることで
開発者同士がファイルを共有することができる仕組み

リモート(GitHub)に登録する

リモートにアップロードするにはリモートのURLを登録する
リモートを登録する際には名前を付ける必要がる
一般的には「origin」とすることが多い

git remote add リモート名(origin) URL
# 「origin」という名前で登録される

リモートにファイルをアップロードする：プッシュする

git push origin master
# 「origin」は「git remote add」の時に付けたリモート名

リモートのファイルをダウンロードする：プルする

git pull gorigin master

変更したファイルを把握する

git status
# 変更があったファイルは「赤色」で表示される

変更内容を把握する：ローカルとステージの変更差分

ファイルの変更差分を表示する
add,commmitする前に確認するために利用
変更したものに本当に間違いがないかを確認して変更をcommit

git diff
# 追加されたコードが「緑」で表示
# 変更されたコードは、変更前「赤」、変更後「緑」で表示

git diff --staged
# テージとコミットの変更差分

git diff HEAD
# ローカルとステージ、ステージとコミット両方の変更差分

addしたファイルを確認する

git status
# addされたファイル　「緑」
# addされていないファイル　「赤」

コミット履歴を表示する

git log
# リポジトリにコミットされたログを確認

logオプション

git log --oneline      # 一行で表示する
git log -p             # ファイルの変更差分を表示す
git log -n 3           # 最新のログを3件のみ表示する
git log --oneline -n 3 # 組み合わせも可能

管理しないファイルをGitの管理から外す

gitignore
gitignoreに指定することでGitの管理から外すことができる

• 自動生成されるファイル(metaデータ)
• パスワードなどセキュリティ上、共有したくないファイル 　等々

gitignoreファイルの書き方
- #から始まるコメント
- ファイル名
- ディレクトリ
- ファイルの種類