Git on ポンコツ地方エンジニアの技術ブログ

VS Code での Git Worktree の使い方

Mon, 13 Jul 2026 00:00:00 +0900

環境

Ubuntu 22.04
Visual Studio Code 1.128.0

事前準備

VS Code の設定で、git.detectWorktrees を ON にします。

ワークツリーの作成だけなら OFF の状態でもできましたが、ワークツリーを切り替えたり削除したりするには ON にする必要がありました。

ワークツリーの作成

ソース管理タブのリポジトリ横のメニューから作成できます。

ブランチの作成と、フォルダの場所を入力します。
デフォルトでは以下のようなフォルダ構成になります。

リポジトリ名
リポジトリ名.worktrees
 └── ブランチ名

ワークツリーが作成されたのが確認できます。

ワークツリーを作業ツリーで開く

作成したワークツリー横のメニューから「現在のウィンドウで作業ツリーを開く」または「新しいウィンドウで作業ツリーを開く」を選択します。

あとはいつも通り変更してコミットなどを行います。

ワークツリーの削除

ソース管理タブのリポジトリにて、ワークツリー横のメニューから作成できます。
（右クリックからでもいけます）

該当のワークツリーを作業ツリーで開いている場合は削除できませんので、その場合はメインリポジトリに切り替えてから削除する必要があります。

OCI の Ubuntu インスタンスの初期設定

Fri, 29 May 2026 00:00:00 +0900

swap の設定

以下のように、Ubuntu のイメージにはスワップがありません。

$ free -m
 total used free shared buff/cache available
Mem: 954 343 225 4 538 610
Swap: 0 0 0

2GB のスワップファイル（Swap）を追加します。
すべてのコマンドは、管理者権限（sudo）を付けてターミナルで実行します。

1. スワップファイルの作成

dd または fallocate コマンドで 2GB のファイルを作成します。ここでは確実かつ高速な fallocate を使用します。

sudo fallocate -l 2G /swapfile

⚠️ 警告

もし「fallocate failed: Operation not supported」のようなエラーが出た場合は、以下の dd コマンドを代わりに試してください。
sudo dd if=/dev/zero of=/swapfile bs=1M count=2048

2. 適切な権限の設定

セキュリティのため、スワップファイルは root ユーザーのみが読み書きできるように権限を 600 に制限します。

sudo chmod 600 /swapfile

3. スワップ領域の初期化

作成したファイルをスワップ領域としてフォーマットします。

sudo mkswap /swapfile

4. スワップの有効化

システムにスワップファイルを認識させ、有効化します。

sudo swapon /swapfile

5. 設定の確認

スワップが正しく有効化されたか確認します。2GB（約 2.0GiB）のスワップが表示されていれば成功です。

sudo swapon --show
# または
free -h

6. 再起動後も自動で有効化する設定

上記の設定だけでは、インスタンスを再起動するとスワップが解除されてしまいます。再起動後も自動的に有効化されるよう、/etc/fstab に追記します。

6-1. fstab のバックアップ（推奨）

念のため、設定ファイルをバックアップしておきます。

sudo cp /etc/fstab /etc/fstab.bak

6-2. 設定の追記

以下のコマンドを実行して、/etc/fstab の末尾に設定を追記します。

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

【おまけ】カーネルパラメータの最適化（推奨）

Linux には、メモリがどれくらい減ったらスワップを開始するかを決める swappiness という値があります。
初期値は 60 であることが多いですが、クラウド環境（特に SSD ストレージ）では **10〜20** 程度に下げて、できるだけ物理メモリを優先して使うように設定するのが一般的です。

1. 現在の swappiness を確認

cat /proc/sys/vm/swappiness

2. 一時的に `10` に変更

sudo sysctl vm.swappiness=10

3. 永続的に反映

再起動後もこの設定を維持するため、/etc/sysctl.conf の末尾に追記します。

echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

これで 2GB のスワップ設定はすべて完了です！

タイムゾーンの変更

# 現在のタイムゾーンを確認
timedatectl
# JST に変更
sudo timedatectl set-timezone Asia/Tokyo
# 変更されたことを確認
timedatectl

nano のインストール

sudo apt update
sudo apt install -y nano

git のインストール

sudo apt update
sudo apt install -y git

glab のインストールと認証

諸事情で GitHub ではなく GitLab を使っているので、glab をインストールします。

1. ダウンロード

apt でインストールできるバージョンは古いので、公式リリースからダウンロードしてインストールします。

詳細は以下を参照してください。

https://blog.ponkotools.com/posts/2026/05/10/glab/

2. GitLab でのアクセストークン（PAT）の発行

CLI から GitLab にアクセスするために、事前にブラウザ側（GitLab のウェブ画面）で Personal Access Token（個人用アクセストークン）を発行しておく必要があります。
WSL を使っているからか、web での認証ではうまくいきませんでした。

GitLab にログインします（SaaS 版の gitlab.com または社内などのオンプレミス版）。
面左上の自分のアイコン＞ Preferences（設定）＞左メニューの Access Tokens の順に開きます。
Add new token をクリックし、以下のように入力します：
Token name: 任意の名前（例: oci-ubuntu-cli）
Expiration date: 空欄（無期限）または任意の有効期限
Scopes（権限）: CLI をフル活用するために、api と write_repository以下にチェックを入れます。

Create personal access token をクリックします。

画面に一度だけトークン（glpat-xxxx…）が表示されるので、必ずコピーして手元に控えておきます。（画面を閉じると二度と見られなくなります）

3. CLI の認証設定（ログイン）

OCI の Ubuntu ターミナルに戻り、以下のコマンドを実行して対話型セットアップを開始します。

glab auth login

実行すると、いくつか質問されるので以下のように回答していきます。

┃ What GitLab instance do you want to sign in to?
┃ > gitlab.com
┃ GitLab Self-Managed or GitLab Dedicated instance

gitLab.com（本家）を使っている場合は、そのまま gitLab.com を選択して Enter。
自社サーバーなどの場合は GitLab Self-Managed or GitLab Dedicated instance を選択し、その後 URL（例: https://gitlab.example.com）を入力します。

- Signing into gitlab.com
┃ How would you like to sign in?
┃ > Token
┃ Web

Token を選択します。

- Signing into gitlab.com
┃ What domains does this host use for the container registry and image dependency proxy?
┃ > gitlab.com,gitlab.com:443,registry.gitlab.com

そのまま Enter を押します。

The minimum required scopes are 'api' and 'write_repository'.
Generate a personal access token at https://gitlab.com/-/user_settings/personal_access_tokens?scopes=api,write_repository
┃ Paste your authentication token:
┃ >

先ほど GitLab 画面でコピーしたトークン（glpat-xxxx…）を貼り付けて Enter を押します。

┃ Choose default Git protocol:
┃ SSH
┃ > HTTPS
┃ HTTP

HTTPS を選択します。

セットアップが完了したら、以下のコマンドで無事にログインできているか確認します。

glab auth status

ご自身のユーザー名や「Logged in to gitlab.com」といったステータスが表示されれば、GitLab CLI の設定はすべて完了です！

tmux のインストール

セッションが切れても実行中のプログラムが停止しないよう tmux を使うためにインストールします。

sudo apt update
sudo apt install -y tmux

docker のインストール

1. インストール

公式ドキュメントの Install using the apt repository に従って最新版の docker をインストールします。

https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository

2. docker の権限を設定 (sudo を不要にする)

sudo gpasswd -a $(whoami) docker
sudo chgrp docker /var/run/docker.sock

不要なサービスの停止

参考: https://qiita.com/ynott/items/4312cb34611d2e462779

systemctl | grep running で稼働中のサービス一覧を出力し、そのうち不要なものを AI に尋ねた結果が以下です。

確実に停止・無効化して良いサービス

サービス名	役割と停止して良い理由
`ModemManager.service`	3G/4G/5G などのモバイルモデムを管理するサービス。クラウドのサーバーでモデムを使うことはないため、完全に不要です。
`fwupd.service`	マザーボードやデバイスのファームウェアをアップデートするデーモン。仮想マシン（VM）のファームウェアは OCI 側が管理するため不要です。
`rpcbind.servicerpcbind.socket`	NFSv3（ネットワークファイルシステム）などで使われる古いポートマップサービス。NFS でストレージをマウントする予定がなければ不要です。
`iscsid.serviceiscsid.socket`	iSCSI ストレージに接続するためのクアドラント。OCI のブロック・ボリュームを iSCSI 経由で直接マウント（手動アタッチなど）していない限り、標準の準仮想化（Paravirtualized）アタッチであれば不要です。
`udisks2.service`	主にデスクトップ環境で USB メモリなどのディスクを自動認識・マウントするためのサービス。サーバー用途では不要です。

停止・無効化のコマンド例
単に stop するだけだと再起動時にまた動いてしまうので、disable –now で自動起動の解除と停止を同時に行います。

sudo systemctl disable --now ModemManager fwupd rpcbind rpcbind.socket iscsid iscsid.socket udisks2

条件付きで停止・削除できるサービス（効果大）

環境によっては不要、あるいは別の手段に切り替えることで大幅に軽量化できる重要ポイントです。

`snapd.service` / `snap.oracle-cloud-agent...` （メモリ節約効果：大）

Ubuntu のパッケージ管理システム「Snap」と、OCI の管理エージェントです。

判断基準
OCI のダッシュボードからインスタンスのメトリック（CPU使用率のグラフなど）を見たり、OS の診断機能を使ったりしない、かつ自分で snap コマンドを使ったアプリ（Nextcloud などの Snap版）を動かす予定がない場合。

解説
oracle-cloud-agent は便利ですが、メモリが 1GB 以下の環境ではかなりの重荷になります。これらを Snap ごと削除すると、数十MB〜100MB 以上のメモリが浮きます。

完全に削除する場合のコマンド

sudo snap remove oracle-cloud-agent
sudo apt purge snapd -y

メモリ使用量の変化

上記のサービスをすべて停止した場合の比較です。

サービス停止前

$ free -h
 total used free shared buff/cache available
Mem: 954Mi 360Mi 72Mi 4.9Mi 677Mi 594Mi
Swap: 2.0Gi 21Mi 2.0Gi

サービス停止後

$ free -h
 total used free shared buff/cache available
Mem: 954Mi 299Mi 313Mi 4.9Mi 483Mi 655Mi
Swap: 2.0Gi 10Mi 2.0Gi

GitHub CLI (gh auth login) で Git の HTTPS 認証を安全にする

Mon, 11 May 2026 00:00:00 +0900

環境

Ubuntu 24.04

きっかけ

git remote -v を眺めていたら、Personal Access Token (PAT) が remote URL に丸ごと埋め込まれている状態になっていました。

origin https://ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx@github.com/USER/REPO.git (fetch)
origin https://ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx@github.com/USER/REPO.git (push)

.git/config はリポジトリに含まれないため「push しても外には出ない」ものの、ローカルで露出する経路は意外と多くあります。

シェル履歴 (~/.bash_history ~/.zsh_history)
エディタや CI のログ、画面共有・スクリーンショット
うっかり配布した dotfiles リポジトリ
マルウェアやリモートアクセスで .git/config が読まれる

しかも classic PAT はスコープが粗く、repo 権限があれば private リポジトリ全体の閲覧・書き換え、強制 push による履歴破壊、GitHub Actions secrets の窃取まで可能になります。攻撃者は奪った瞬間には何もせず静かに watch することもできるため、「使われた形跡がない」では安心できません。

これを機に、PAT を URL に埋めず GitHub CLI (gh) の credential helper に任せる構成に切り替えました。

ゴール構成

remote URL は素の https://github.com/USER/REPO.git
認証は gh が credential helper として処理 (トークンは OS のセキュアストア管理)
devcontainer を作り直しても再ログイン不要

手順

1. 露出したトークンを revoke (最優先)

remote URL を書き換える前に、まず GitHub 側でトークンを無効化します。

classic PAT: https://github.com/settings/tokens
fine-grained PAT: https://github.com/settings/personal-access-tokens

該当トークンを Delete した瞬間に無効になります。順序として これを先にやる ことが大切です。後の手順を待っている間に古いトークンが他経路で使われるリスクを断ちます。

2. `gh` をインストール

devcontainer 環境なら ghcr.io/devcontainers/features/github-cli feature で gh がすでに入っています。

ホスト (Ubuntu 24.04) に入れる場合は、以下の記事を参考にしてください。

GitHub CLI (gh) のインストールと基本的な使い方

3. `gh auth login` で認証

gh auth login

対話で以下のように選びます。

? Where do you use GitHub? GitHub.com
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser

Authenticate Git with your GitHub credentials? → Yes が肝で、これが git config --global credential.helper を gh 経由に書き換えてくれます。以後 git push のたびに gh が裏でトークンを取り出して認証してくれます。

devcontainer のようなヘッドレス環境ではブラウザは自動で開きません。表示される 8 桁のワンタイムコードをコピーし、ホスト側のブラウザで https://github.com/login/device に貼って承認します。

✓ Authentication complete.
✓ Logged in as USER

4. remote URL からトークンを除去

git remote set-url origin https://github.com/USER/REPO.git
git remote -v

トークン部分が消えていれば OK です。git fetch origin がパスワードを聞かれずに通れば認証は機能しています。

5. シェル履歴の残骸を確認

revoke 済みでも、ローカル履歴に残ったトークン文字列は気持ちが悪いものです。

grep -rn 'ghp_' ~/.bash_history ~/.zsh_history 2>/dev/null

ヒットしたら該当行を削除します (history -d <行番号> でメモリ上を消した後、ファイルも編集しておきます)。

devcontainer での認証共有

gh の認証情報は ~/.config/gh/hosts.yml (と OS のセキュアストア) に保存されます。devcontainer をリビルドすると ~/.config/gh が消えて再ログインが必要になるため、ホストの設定を bind mount で共有します。

.devcontainer/devcontainer.json:

"mounts": [
 "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind,consistency=cached",
 "source=${localEnv:HOME}/.claude.json,target=/home/vscode/.claude.json,type=bind,consistency=cached",
 "source=${localEnv:HOME}/.config/gh,target=/home/vscode/.config/gh,type=bind,consistency=cached"
]

前提として ホスト側に ~/.config/gh ディレクトリが存在している必要があります (なければ bind mount に失敗します)。ホストにも gh を入れて gh auth login 済みにしておくのが一番シンプルです。事情があってホスト側で gh を使わない場合でも、空ディレクトリだけ作っておけばマウント自体は通ります。

mkdir -p ~/.config/gh # ホスト側で実行

設定変更後は VSCode の Dev Containers: Rebuild Container でリビルドすると反映されます。

補足: SSH 鍵にしないのか

SSH 鍵認証もアリですが、

鍵ファイル自体の管理 (~/.ssh のパーミッション、複数マシン間の同期) が発生します
GitHub Actions など他用途で gh をどのみち使うことが多いです

そのため、個人開発の HTTPS なら gh auth login ひとつに寄せた方がメンテが楽だと感じています。複数アカウントの切替も gh auth switch で済むのが良いところです。

まとめ

PAT を URL に埋めるのは「公開リポジトリに含まれない」だけでローカル経路の露出リスクは大きいです。露出に気付いた時点で revoke が最優先となります。
gh auth login で credential helper を任せれば URL からトークンを排除でき、トークンは OS のセキュアストアに隔離されます。
devcontainer ではホストの ~/.config/gh を bind mount しておくと、リビルドのたびに再ログインしなくて済みます。

ターミナルから GitLab を操る：公式 CLI「glab」導入・活用ガイド

Sun, 10 May 2026 00:00:00 +0900

ブラウザを開かずに Issue を確認したり、MR（マージリクエスト）を作成したり、CI/CD パイプラインの状況を監視したりできるため、エンジニアの生産性を大きく向上させてくれます。

1. インストール方法

devcontainer を使っていない場合は、ホスト側に glab をインストールして使います。devcontainer を使う場合は、コンテナイメージに glab をインストールしておくか、devcontainer の Dockerfile / devcontainer.json で導入しておきます。

一般的な手順としては、Dockerfile に curl で glab の公式パッケージを取得して apt install するか、apt リポジトリからインストールする形です。コンテナ内で glab --version を実行して、インストールが正しくできていることを確認してください。

OS ごとの主要なインストールコマンドは以下の通りです。

OS	インストールコマンド
macOS	`brew install glab`
Windows (winget)	`winget install glab`
Windows (scoop)	`scoop install glab`
Linux (Ubuntu/Debian)	`sudo apt install glab`（※公式リポジトリ推奨）

インストール後、glab --version で正常にインストールされたか確認しましょう。

バージョンが古かったり、上記でインストールできない場合は、公式リリースからダウンロードしてインストールします。

https://gitlab.com/gitlab-org/cli/-/releases

例えば以下です。

cd /tmp
wget https://gitlab.com/gitlab-org/cli/-/releases/v1.97.0/downloads/glab_1.97.0_linux_amd64.deb
sudo dpkg -i glab_1.97.0_linux_amd64.deb

2. 初期設定（認証）

インストールが完了したら、GitLab アカウントと連携させます。

glab auth login

実行すると対話形式で以下の項目を聞かれます：

GitLab インスタンスの種類: GitLab.com か自前運用のサーバー（Self-Managed）かを選択。
認証方法: Web を選択するとブラウザが開いて簡単に認証できます。
プロトコル: SSH または HTTPS を選択。

設定が完了すると、~/.config/glab-cli/config.yml に設定が保存されます。

3. devcontainer での認証情報共有

glab の認証情報は ~/.config/glab-cli/config.yml に保存されます。devcontainer をリビルドするとコンテナ内の ~/.config/glab-cli が消えて再ログインが必要になるため、ホスト側の設定を bind mount で共有しておくと便利です。

一般的には、.devcontainer/devcontainer.json の mounts にホストの ~/.config/glab-cli を追加します。例:

"mounts": [
 "source=${localEnv:HOME}/.config/glab-cli,target=/home/vscode/.config/glab-cli,type=bind,consistency=cached"
]

もし gh など別の CLI も devcontainer 内で使うなら、同じように ~/.config/gh を共有することもできます。

ホスト側に ~/.config/glab-cli が存在していれば、ホストで一度 glab auth login しておけばコンテナ側でも同じ認証を使えます。ホストにディレクトリがない場合は、mkdir -p ~/.config/glab-cli で空ディレクトリを作成しておけばマウントが通ります。

このようにしておけば、glab の認証設定をホストと devcontainer で共通化し、コンテナ再構築後も再ログイン不要で作業を続けやすくなります。

4. よく使う基本コマンド集

glab のコマンド体系は glab <リソース名> <アクション> という形式で、gh と非常に似ています。

■ Merge Request (MR) を操作する

開発のメイン作業となる MR 操作です。

MR の一覧表示: glab mr list
MR の作成: glab mr create --fill（現在のブランチから自動入力で作成）
MR の詳細表示: glab mr view <id>
MR を承認: glab mr approve <id>
MR をマージ: glab mr merge <id>

■ Issue (課題) を管理する

Issue 一覧: glab issue list
Issue 作成: glab issue create -t "タイトル" -description "内容"

■ CI/CD パイプラインを確認する

glab 独自の強力な機能の一つが、CI パイプラインのリアルタイム監視です。

パイプラインの状態表示: glab pipeline status
実行中のログをリアルタイム表示: glab pipeline ci view
失敗したジョブの再実行: glab ci retry

4. `gh` と `glab` の主な対応表

GitHub CLI に慣れている方向けのクイック比較です。

機能	GitHub (`gh`)	GitLab (`glab`)
認証	`gh auth login`	`glab auth login`
PR / MR 作成	`gh pr create`	`glab mr create`
PR / MR チェックアウト	`gh pr checkout <id>`	`glab mr checkout <id>`
リポジトリ作成	`gh repo create`	`glab project create`
CI 監視	`gh run watch`	`glab pipeline ci view`

5. 自社運用の GitLab (Self-Managed) で使うコツ

glab は GitLab.com だけでなく、会社などで独自に立てている GitLab サーバーでも使えます。その場合、環境変数でホストを指定しておくと便利です。

export GITLAB_HOST=gitlab.example.com

まとめ

glab を導入することで、「コードを書く → プッシュする → ブラウザで MR を作る → CI の完了を待つ」という一連の流れをターミナルから一歩も出ずに行えるようになります。

まずは glab mr list から始めて、快適な GitLab ライフを送りましょう！

参考リンク:

GitHub CLI (gh) のインストールと基本的な使い方

Sat, 09 May 2026 00:00:00 +0900

GitHub CLI (gh) は、GitHub が公式に提供しているコマンドラインツールです。

ブラウザを開かなくても、リポジトリの clone、Issue の確認、Pull Request の作成、GitHub Actions の実行状況確認などをターミナルから操作できます。Git と組み合わせて使うと、日常の GitHub 作業をかなり短い導線にできます。

この記事では、Windows と Ubuntu で gh をインストールし、最初に覚えておくと便利な基本コマンドをまとめます。

gh でできること

gh を使うと、たとえば以下のような作業をターミナルから実行できます。

GitHub へのログイン
リポジトリの clone / 作成 / 表示
Issue の一覧表示 / 作成 / 表示
Pull Request の一覧表示 / 作成 / checkout / merge
GitHub Actions の workflow / run の確認
ブラウザで現在のリポジトリや PR を開く

GitHub の画面を見に行く回数を減らせるので、コードを書いている流れを止めにくいのが大きなメリットです。

インストール

Windows にインストールする

Windows では、公式手順として WinGet を使う方法が一番簡単です。

PowerShell または Windows Terminal を開いて、以下を実行します。

winget install --id GitHub.cli

インストール後、ターミナルを開き直して確認します。

gh --version

バージョン情報が表示されればインストール完了です。

アップデートする場合は以下です。

winget upgrade --id GitHub.cli

もし WinGet を使わない場合は、GitHub CLI の Releases ページから MSI インストーラーをダウンロードして導入することもできます。

Ubuntu にインストールする

Ubuntu では、標準の apt リポジトリからそのままインストールできます。

まずパッケージ情報を更新してから、gh をインストールします。

sudo apt update
sudo apt install gh

確認します。

gh --version

アップデートする場合は、通常の apt パッケージと同じです。

sudo apt update
sudo apt install gh

もし apt で見つからない場合や、GitHub CLI の最新版を追いたい場合は、GitHub CLI 公式リポジトリを追加する方法もあります。

type -p wget >/dev/null || (sudo apt update && sudo apt install wget -y)
sudo mkdir -p -m 755 /etc/apt/keyrings
wget -nv -O /tmp/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg
sudo cp /tmp/githubcli-archive-keyring.gpg /etc/apt/keyrings/githubcli-archive-keyring.gpg
sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg
sudo mkdir -p -m 755 /etc/apt/sources.list.d
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update
sudo apt install gh

通常利用なら、まずは sudo apt install gh で十分です。

初期設定: GitHub にログインする

インストールできたら、GitHub アカウントでログインします。

gh auth login

対話形式でいくつか質問されます。個人利用で GitHub.com を使うなら、だいたい以下の選択で問題ありません。

? Where do you use GitHub? GitHub.com
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser

ポイントは、Authenticate Git with your GitHub credentials? で Yes を選ぶことです。これにより、gh だけでなく通常の git push や git fetch の HTTPS 認証も gh に任せられます。

ブラウザが開いたら GitHub にログインして認証します。WSL やサーバー上などブラウザを開きにくい環境では、表示されたワンタイムコードを手元のブラウザで入力して認証します。

ログイン状態は以下で確認できます。

gh auth status

普通の git コマンドでも gh の認証情報は使われる？

使われます。ただし、gh auth login の途中で以下を選んでいることが前提です。

? Authenticate Git with your GitHub credentials? Yes

この設定を有効にすると、gh が Git の credential helper として設定されます。そのため、以下のような普通の Git コマンドでも、gh でログインした認証情報が利用されます。

git fetch origin
git pull
git push origin main

確認するには、Git の credential helper 設定を見ます。

git config --global --get credential.helper

環境によって表示は少し違いますが、gh auth git-credential を使う設定になっていれば OK です。

注意点として、この仕組みが使われるのは基本的に HTTPS の remote URL です。

git remote -v

remote URL が以下のようになっていれば、HTTPS 経由です。

origin https://github.com/OWNER/REPO.git (fetch)
origin https://github.com/OWNER/REPO.git (push)

一方で、git@github.com:OWNER/REPO.git のような SSH の remote URL を使っている場合は、Git の認証は SSH key 側で行われます。この場合でも gh コマンド自体の GitHub API 操作には、gh auth login の認証情報が使われます。

よく使う基本コマンド

ここからは、最初に覚えておくと便利なコマンドです。

リポジトリ操作

リポジトリを clone します。

gh repo clone OWNER/REPO

たとえば GitHub CLI 本体のリポジトリなら以下です。

gh repo clone cli/cli

現在のリポジトリをブラウザで開きます。

gh repo view --web

新しいリポジトリを作成します。

gh repo create

対話形式で公開範囲やローカルディレクトリの扱いを選べます。スクリプト化したい場合は、--public や --private などのオプションを付けて実行できます。

gh repo create my-app --private --source=. --remote=origin

Issue 操作

Issue の一覧を表示します。

gh issue list

Issue の詳細を表示します。

gh issue view 123

Issue を作成します。

gh issue create --title "ログイン画面の文言を修正する" --body "ボタンの表記を変更する"

ブラウザで Issue を開きたい場合は --web を付けます。

gh issue view 123 --web

Pull Request 操作

Pull Request の一覧を表示します。

gh pr list

現在のブランチから Pull Request を作成します。

gh pr create

コミットメッセージやブランチ情報からタイトル・本文を自動入力したい場合は --fill が便利です。

gh pr create --fill

Pull Request の詳細を表示します。

gh pr view 123

Pull Request のブランチをローカルに checkout します。

gh pr checkout 123

レビューや CI の状態を確認します。

gh pr checks 123

マージします。

gh pr merge 123

GitHub Actions 操作

workflow の一覧を表示します。

gh workflow list

実行履歴を表示します。

gh run list

最新の workflow run を確認します。

gh run view

実行中の workflow を待ちます。

gh run watch

失敗したジョブのログを確認する場合は、まず gh run list で run ID を確認してから以下を実行します。

gh run view RUN_ID --log-failed

便利な使い方

現在のページをブラウザで開く

現在のリポジトリを GitHub 上で開きます。

gh browse

Issue や PR の URL を組み立てる必要がないので、地味に便利です。

自分に関係する状況をまとめて見る

自分に関連する Issue、PR、レビュー依頼などを確認できます。

gh status

朝の作業開始時に一度実行すると、見るべきものをざっと把握できます。

エイリアスを作る

よく使うコマンドは短い別名を付けられます。

gh alias set prs 'pr list --author @me'
gh prs

この例では、自分が作成した Pull Request 一覧を gh prs で表示できます。

Windows と Ubuntu で共通して気をつけること

ターミナルを開き直す

Windows ではインストーラーが PATH を更新します。gh が見つからない場合は、Windows Terminal や PowerShell を開き直してください。

Ubuntu でも、インストール後にシェルがコマンドの場所をキャッシュしている場合があります。うまく認識されないときは、ターミナルを開き直すか hash -r を実行します。

Git の認証方式をそろえる

gh auth login で HTTPS を選び、Git の認証にも gh を使う設定にした場合、リモート URL も HTTPS にしておくと扱いやすいです。

git remote -v
git remote set-url origin https://github.com/OWNER/REPO.git

SSH を使いたい場合は、gh auth login の対話で SSH を選び、SSH key の登録も gh に任せることができます。HTTPS と SSH のどちらでも使えますが、チームや自分の環境で片方に寄せておくとトラブルシュートが楽です。

GitHub Enterprise Server を使う場合

会社などで GitHub Enterprise Server を使っている場合は、ホスト名を指定してログインします。

gh auth login --hostname github.example.com

通常の GitHub.com とは認証先が別になるため、gh auth status でどのホストにログインしているか確認しておくと安心です。

まとめ

gh を入れておくと、GitHub 上の操作をターミナルから自然に扱えるようになります。

まずは以下の流れだけ覚えておけば十分です。

gh auth login
gh repo clone OWNER/REPO
gh issue list
gh pr list
gh pr create --fill
gh run list

慣れてきたら gh pr checkout、gh pr checks、gh run watch あたりを使うと、Pull Request と CI の確認がかなり楽になります。

参考 URL

Redmine に Git のリポジトリを追加したら internal error が表示される

Fri, 13 May 2022 00:00:00 +0900

私の場合ですが、タグ名に日本語を使っていたのが原因のようでした。

環境は以下です。

Redmine 3.4.2
Git 1.8.3.1

ちょっと古いバージョンなので最新バージョンではわかりませんが、この環境下では、ブランチやタグの名前に日本語を使っていると internal error となるようです。
Redmine のログを見ていてタグの表示でエラーになっているっぽかったので気が付きました。

参考 URL

https://plugins.co.jp/2015/05/git%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%81%AB%E6%97%A5%E6%9C%AC%E8%AA%9E%E5%90%8D%E3%82%92%E3%81%A4%E3%81%91%E3%82%8B%E3%81%A8redmine%E3%81%AE%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA/

Redmine に Git のリポジトリを追加したら 404 エラーが表示される

Thu, 12 May 2022 00:00:00 +0900

まずはファイルパスが正しいかを疑うべきですが、それが正しい場合はアクセス権が原因の可能性があります。

例えば、私の場合、/home/username/xxxx.git という場所にベアリポジトリを作成していたのですが、xxxx.git のアクセス権しか変更していませんでした。

$ sudo chmod o+rx xxxx.git

しかし、その一つ上の /home/username にアクセス権が設定されていなかったため、Redmine からは見ることができなかったようです。
以下のように設定変更すれば解決しました。

$ sudo chmod o+rx /home/username

参考 URL

https://www.pistolfly.com/weblog/2010/11/redminegit.html

GitLab でプライベートリポジトリの分も草を生やす

Mon, 02 May 2022 00:00:00 +0900

GitLab のプロフィールに表示されるコミットグラフですが、デフォルトでは自分以外の人からは Public なリポジトリの分しか見えません。

Private なリポジトリのコミット分も見えるようにするには、以下の設定を変更します。

Preferences > Profile > Private contributions

参考 URL

https://www.igorkromin.net/index.php/2018/09/13/gitlab-finally-shows-private-project-contributions-in-the-profile-commit-graph/

TortoiseGit で過去のコミットの作者（コミッター）を修正する

Wed, 13 Apr 2022 00:00:00 +0900

間違ったアカウント（メールアドレス）でコミットしてしまった場合に、後から TortoiseGit で修正する方法です。

TortoiseGit で過去のコミットメッセージを変更する方法を以下の記事にまとめていますが、

TortoiseGit でコミットメッセージを変更する

コミットメッセージではなく、コミッターの情報を変更したい場合、ここにもう少し手順が必要です。

まずはコミットメッセージを修正する画面を表示する

上記のページを参考に、まずはコミットメッセージを修正する画面を表示します。

そしたら、「コミットを編集/分割する」にチェックを入れて「Amend」をクリックします。

すると、通常コミット時と同じ画面が表示されるので、「作者を設定」にチェックを入れ、右の欄にユーザー名とメールアドレスを入力してコミットします。

「他のコミットを追加しますか？」という画面が表示されますが、コミッターの修正だけであれば「いいえ」を選択します。

他のコミットも編集する場合は同様に修正していきます。
以上です。

git で clone する場合に 503 エラーが表示される

Tue, 12 Apr 2022 00:00:00 +0900

ローカルネットワークにある GitLab からクローンをしようとした際、503 エラーが表示されました。

ググってみるとプロキシ設定が原因という記事が出てきますが、一応プロキシ設定はしているつもりでした。

しかし、どうやら Git はワイルドカードを使ったプロキシ設定を認識してくれないようです。

今回、環境変数 no_proxy に 192.168.1.* のように設定していたのですが、これを 192.168.1.2 のように指定すると正しく表示されました。

git-svn の使い方

Sat, 03 Jul 2021 00:00:00 +0900

社内で未だに SVN で開発しているプロダクトがあるので、git-svn を使ってみました。

環境

Ubuntu 20.04
git 2.25.1
svn 1.13.0

インストール

$ sudo apt install git-svn

クローン

SVN リポジトリを指定してクローンを行います。

$ git svn clone --prefix=svn/ <SVNリポジトリのURL>

--prefix は SVN のブランチに接頭辞をつけるオプションで、一般的に付けたほうがよいとされています。

SVN リポジトリが標準的な構成(trunk, branch, tag) になっている場合は -s オプションを付けます。
標準的な構成になっていない場合は --trunk branches --tags を使用する。
今回はルートが trunk になっており、ブランチも作成していなかったため、以下のように指定しました。

$ git svn clone --trunk=/ --prefix=svn/ <SVNリポジトリのURL>

試しにブランチを表示してみると、以下のようになっていました。

$ git branch -a
* master
 remotes/svn/trunk

コミット

コミットは普通に git を使ってやるのと同じです。

SVN リポジトリにコミットを反映する

git でのプッシュに該当する操作として、SVNにコミットを行います。
コミット前にリベースで git のコミットをまとめておいたほうがいいかもしれません。

$ git svn dcommit

SVN リポジトリから最新のデータを取得

リベースを行うことになるみたいです。

$ git svn rebase

尚、これを行うにはワークディレクトリ内の全ての変更がコミットされている必要があるみたいです。コミットしていない変更があった場合、以下のようなエラーが表示されます。

/workspace/hoge: needs update
update-index --refresh: command returned error: 1

参考 URL

git でコミットを一つにまとめる

Fri, 02 Jul 2021 00:00:00 +0900

Ｗindows 環境では TortoiseGit を使っているので GUI で出来るのですが、Ubuntu で使っている RabbitGit では出来なさそうだったので、コマンドでやりました。

TortoiseGit でのやり方は以下です。

https://kuttsun.blogspot.com/2018/09/tortoisegit.html

環境

Ubuntu 20.04

まずログを確認

$ git log --oneline

以下のように表示されます。

5418fe (HEAD -> master) fuga
f3896f7 piyo
af6639b hoge
b1da633 initial commit

ここで３つのコミット（hoge、piyo、fuga のメッセージのやつ）を一つにまとめてみます。

リベースの開始

まとめたいコミット群の一つ前のコミットに対してリベースを行います。

$ git rebase -i HEAD~3

HEAD~3 は HEAD~~~ やハッシュ値でも構いません。

すると、テキストエディタで編集画面が表示されます。
私の場合は nano で表示されました（vi じゃなくてよかった）。

pick af6639b hoge
pick f3896f7 piyo
pick c5418fe fuga

# Rebase b1da633..c5418fe onto b1da633 (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# . create a merge commit using the original merge commit's
# . message (or the oneline, if no original merge commit was
# . specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

-i オプションを指定したので、この画面では Rebase を使って現在と過去の間に残ってるコミットをどう処理するかを聞かれています。

最新以外の pick の箇所を s または squash に変更します。

変更前

pick af6639b hoge
pick f3896f7 piyo
pick c5418fe fuga

変更後

pick af6639b hoge
s f3896f7 piyo
s c5418fe fuga

保存して終了すると、コミットメッセージの編集画面が開きます。
必要に応じて編集し、終了します。

参考 URL

RabbitVCS のインストール

Thu, 01 Jul 2021 00:00:00 +0900

Windows では TortoiseSVN と TortoiseGit を使っていたので、Linux でも GUI で良いのがないかなと探していたら、RabbitVCS というのが Tortoise に似た感じだったので、インストールしてみました。

環境

Ubuntu 20.04

インストール

以下に説明があります。

http://wiki.rabbitvcs.org/wiki/install/ubuntu

以下のコマンドを実行するだけでインストールできました。

$ sudo apt install rabbitvcs-nautilus

これ一つで RabbitVCS SVN RabbitVCS Git RabbitVCS Hg が使えるようになるっぽい。

あとはファイル比較用の Meld とかいうツールも勝手に入ってました。

再起動後には Tortoise と同じように、フォルダにアイコンが表示されるようになっていました。

所感

まだ全然使っていませんが、とりあえず最新のコードをプルしたりだとか、コミットログを見たりだとか、ファイルの差分を閲覧する分には困っていません。

参考 URL

git コマンドのメモ

Mon, 07 Jun 2021 00:00:00 +0900

普段は TortoiseGit を使っており、いざコマンドしか使えない環境のときに困るので、個人的によく使う基本的なコマンドについてメモしておきます。

適宜更新していきます。

設定

現在の設定を確認

$ git config --list

システム全体(system)、ユーザー全体(global)、対象リポジトリのみ(local)を確認したい場合はそれぞれ以下。

$ git config --system --list
$ git config --global --list
$ git config --local --list

ローカルのユーザーとメールアドレスを設定

$ git config --local user.name "My Name"
$ git config --local user.email myname@example.com

リモートリポジトリの情報

リモートリポジトリの名前を表示する

$ git remote

リモートリポジトリの名前と場所(URL）を表示する

$ git remote -v

指定したリモートリポジトリの詳しい情報を表示する

$ git remote show <リポジトリ名>

リモートリポジトリの追加・削除・変更

追加する

$ git remote add <リポジトリ名> <URL>

削除する

$ git remote rm <リポジトリ名>

URL の変更

$ git remote set-url <リポジトリ名> <変更先のURL>

開発中に使うコマンド

クローン

$ git clone <URL>

差分を表示

$ git status

-s を使えると簡略化して表示されます。

コミットの流れ

ステージング

$ git add ファイル名

コミット

$ git commit -m "コメント"

プッシュ

$ git push

最後のコミットのやり直し

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

変更の破棄

$ git checkout <filename>

全て破棄したい場合は以下

$ git checkout .

参考 URL

Git で HTTPS を使う場合のアカウント情報を記憶させる

Tue, 01 Jun 2021 00:00:00 +0900

毎回打つのが面倒なので。

Windows の場合

クローンするときにユーザー名とパスワードが聞かれますが、一度入力すると資格情報マネージャーに登録されるので、２回目以降はユーザー名とパスワードの入力が不要になります。
もし入力間違いをしてしまった場合は、資格情報マネージャーで削除すれば OK です。

Linux の場合

Ubuntu 20.04 で確認しました。
libsecret をインストールして、credential.helper に設定してやります。

sudo apt-get install libsecret-1-0 libsecret-1-dev
cd /usr/share/doc/git/contrib/credential/libsecret
sudo make
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

これで、一度ユーザー名とパスワードを入力したら、次回以降は入力不要になります。

Git on ポンコツ地方エンジニアの技術ブログ

VS Code での Git Worktree の使い方

環境

事前準備

ワークツリーの作成

ワークツリーを作業ツリーで開く

ワークツリーの削除

OCI の Ubuntu インスタンスの初期設定

swap の設定

1. スワップファイルの作成

2. 適切な権限の設定

3. スワップ領域の初期化

4. スワップの有効化

5. 設定の確認

6. 再起動後も自動で有効化する設定

6-1. fstab のバックアップ（推奨）

6-2. 設定の追記

【おまけ】カーネルパラメータの最適化（推奨）

1. 現在の swappiness を確認

2. 一時的に 10 に変更

3. 永続的に反映

タイムゾーンの変更

nano のインストール

git のインストール

glab のインストールと認証

1. ダウンロード

2. GitLab でのアクセストークン（PAT）の発行

3. CLI の認証設定（ログイン）

tmux のインストール

docker のインストール

1. インストール

2. docker の権限を設定 (sudo を不要にする)

不要なサービスの停止

確実に停止・無効化して良いサービス

条件付きで停止・削除できるサービス（効果大）

snapd.service / snap.oracle-cloud-agent... （メモリ節約効果：大）

メモリ使用量の変化

GitHub CLI (gh auth login) で Git の HTTPS 認証を安全にする

環境

きっかけ

ゴール構成

手順

1. 露出したトークンを revoke (最優先)

2. gh をインストール

3. gh auth login で認証

4. remote URL からトークンを除去

5. シェル履歴の残骸を確認

devcontainer での認証共有

補足: SSH 鍵にしないのか

まとめ

ターミナルから GitLab を操る：公式 CLI「glab」導入・活用ガイド

1. インストール方法

2. 初期設定（認証）

3. devcontainer での認証情報共有

4. よく使う基本コマンド集

■ Merge Request (MR) を操作する

■ Issue (課題) を管理する

■ CI/CD パイプラインを確認する

4. gh と glab の主な対応表

5. 自社運用の GitLab (Self-Managed) で使うコツ

まとめ

GitHub CLI (gh) のインストールと基本的な使い方

gh でできること

インストール

Windows にインストールする

Ubuntu にインストールする

初期設定: GitHub にログインする

普通の git コマンドでも gh の認証情報は使われる？

よく使う基本コマンド

リポジトリ操作

Issue 操作

Pull Request 操作

GitHub Actions 操作

便利な使い方

現在のページをブラウザで開く

自分に関係する状況をまとめて見る

エイリアスを作る

Windows と Ubuntu で共通して気をつけること

ターミナルを開き直す

Git の認証方式をそろえる

2. 一時的に `10` に変更

`snapd.service` / `snap.oracle-cloud-agent...` （メモリ節約効果：大）

2. `gh` をインストール

3. `gh auth login` で認証

4. `gh` と `glab` の主な対応表