Skip to content

Git

  • in Git, GitLab
  • 7 min read

有効期限切れになったGitLabのGPG鍵を更新する

Amazon Linux 2023へGitLabをリポジトリからインストールして利用しています。ですが、更新しようとしたところ以下のエラーになりました。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# dnf check-update
gitlab_gitlab-ee                                               346  B/s | 833  B     00:02
gitlab_gitlab-ee                                               7.2 kB/s | 3.1 kB     00:00
gitlab_gitlab-ee                                                16 kB/s | 7.0 kB     00:00
gitlab_gitlab-ee                                               2.7 kB/s | 3.8 kB     00:01
gitlab_gitlab-ee                                               286  B/s | 833  B     00:02
Error: Failed to download metadata for repo 'gitlab_gitlab-ee': repomd.xml GPG signature verification error: Bad GPG signature
(snip)
Error: Failed to download metadata for repo 'runner_gitlab-runner-source': repomd.xml GPG signature verification error: Bad GPG signature
Ignoring repositories: gitlab_gitlab-ee, gitlab_gitlab-ee-source, runner_gitlab-runner, runner_gitlab-runner-source
Last metadata expiration check: 1 day, 15:27:18 ago on Thu Feb 26 17:00:09 2026.

今回は「GitLabのGPG鍵が有効期限切れになっていた」ことが原因でした。これを解消し、GPG鍵を更新する手順をメモしておきます。

  • in Git
  • 1 min read

トランクベースでGit運用する際のコミットメッセージ例

トランクベースでGitを運用する際、コミットメッセージに付与する接頭詞の例をメモしておきます。Geminiに生成してもらいました。

分類 Prefix 意味・内容 具体的な使用例
メイン feat 新機能の追加 feat: ログイン機能の実装
fix バグ修正 fix: 入力フォームのバリデーションエラーを修正
コード改善 refactor リファクタリング（挙動を変えない整理） refactor: 重複したロジックを共通関数に抽出
style フォーマット、空白、セミコロンなど（見た目のみ） style: インデントを2スペースに統一
perf パフォーマンス向上のための変更 perf: 画像読み込みの遅延実行を導入
非機能的変更 docs ドキュメントのみの変更 docs: READMEにインストール手順を追記
test テストコードの追加・修正 test: ユーザー登録のユニットテストを追加
chore 雑用（ライブラリ更新、ビルド設定など） chore: npmパッケージのアップデート
ci CI設定（GitHub Actionsなど）の変更 ci: デプロイ用ワークフローの修正
特殊 wip 作業中（Work In Progress） wip: 決済機能の実装（途中保存）
revert 前のコミットの打ち消し revert: feat: ○○ のコミットを取り消し
feat! 破壊的変更（互換性がなくなる変更） feat!: APIレスポンスのデータ構造を刷新
  • in Git
  • 5 min read

ForkでGitflowする

Gitを使った開発フローには「GitFlow」や「トランクベース開発」、「GitHubフロー」などがあるそうです。

Gitflow ワークフロー

Gitflow とは、元来は Git ブランチを管理するための破壊的で斬新な戦略のレガシー Git ワークフローです。Gitflow の需要は落ち込み、トランク ベースのワークフローが利用されるようになっています。現在ではこれが最新の継続的なソフトウェア開発のベスト プラクティスおよび DevOps プラクティスと見なされています。Gitflow はまた、CI/CD と使用することも困難な場合があります。この投稿では、歴史的な目的で Gitflow の詳細をご説明します。

トランク ベース開発

最初に普及した Gitflow は、特定の個人だけがメイン コードへの変更を承認できる、非常に厳格な開発モデルです。そのため、コードの品質が維持されてバグの数が最小限に抑えられます。トランク ベース開発は、すべての開発者がメイン コードにアクセスできる、よりオープンなモデルです。そのため、チームはすばやく反復処理を実行して CI/CD を実現できます。

GitHub フロー

GitHub フローは、軽量のブランチ ベースのワークフローです。 GitHub フローは、開発者だけでなくすべてのユーザーに役立ちます。

各々の特徴を一覧にすると以下です。

特徴 GitFlow GitHub Flow トランクベース
複雑さ 高い 低い 非常に低い
リリースの頻度 数週間〜数ヶ月に一度 毎日〜週に数回 1日に何度も
主な用途 堅牢なパッケージソフト Webサービス、SaaS 高速な継続的デプロイ

これらの違いは赤帽エンジニアブログさんのトランクベース開発についてで分かりやすく違いが説明されています。今回はGitクライアントであるForkを使ってGitflowを試してみました。尚、「ひとり開発」を前提にしています。