• Home
• コーポレートブログ
• 業務を効率的に進めるためのよく使用するGitとDockerコマンド

原田です。今回は私が業務でよく使用するGitとDockerコマンドとこれらのコマンドに関連するアプリ（GUI）について書きます。

業務でDockerやGitをよく使います

私の最近の業務はDockerコンテナを使用して新たなサービスを展開しようと試行錯誤を重ねています。サービスを構築するために前回のブログでご紹介しましたAWS CDKを使用しています。弊社ではDockerfileやCDKのコード、その他Webコンテンツなど、社内で作成した物の大半をGitHubのプライベートリポジトリで管理していますので、必然的にGitコマンドを使用しています。

よく使用するコマンドのご紹介

GitやDockerを使用されている方の中には「そのコマンドはよく知っている」とおっしゃる方がおられるかもしれません。私は毎日同じコマンドを打ち込んでいても便利だなと感心します。

git fetch origin（リモートリポジトリ） --prune

弊社では以下のような運用（一部抜粋）をしています。皆さんも同様の運用をされているのではないかと思います。

1. 社員Aは自身のローカルリポジトリにブランチ（ローカルブランチ）を作成する
2. 社員Aはローカルブランチに追加・変更・削除をcommitする
3. 社員Aはoriginに対してローカルブランチをpushする
4. 社員B（レビュワー）は自身のローカルリポジトリにoriginの最新内容を取得する
5. 社員Bは社員Aが作成したリモートブランチ（ブランチA）のレビューを実施する
6. （レビューで問題がなければ）社員Bはoriginのmain（master）ブランチにブランチAをmergeする（リポジトリの運用によっては社員Aが実施する場合もあるようです）
7. 社員BはブランチAを削除する（同上）

originの最新内容を入手したい時（私の場合は上記1・4）にgit fetch origin --pruneを実施します。--pruneオプションですが、上記7でリモートブランチが削除されたことをローカルリポジトリで把握するために付加しています。

% git fetch origin --prune
From https://<リモートリポジトリURL>
 - [deleted]         (none)     -> origin/issue-59652
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), 647 bytes | 323.00 KiB/s, done.
   b5894a4..1c4190d  main     -> origin/main
%

git rebase main（or master or ブランチ名）

Gitを使用していると以下の状況に遭遇することがあると思います。

1. ローカルブランチAはローカルリポジトリのみに存在している（リモートリポジトリには一度もpushしていない）
2. git fetch originを実施
3. mainブランチが更新されていたので、git checkout mainとgit pullを実施
4. （ローカル）ブランチAはこれからgit push origin ブランチAするので、最新のmainブランチに対してrebaseしたい

この場合は以下のようにgit rebase mainを実施してブランチAのコミットログをmainブランチ以降に綺麗に並べることができます。

% git checkout branch-a
Switched to branch 'branch-a'
% git rebase main
Successfully rebased and updated refs/heads/branch-a.

ただし上記手順ではgitコマンドを2回打ち込むことになります。ローカルブランチが多数存在する場合は、git checkoutでチェックアウトするブランチ名を都度入力（またはコピー＆ペースト）することになり大変手間な作業になります。私はgitコマンドと以前のブログで少しご紹介しましたGitUpを併用することで少しですが手間を省いています。

• git checkoutはGitUpで行う
• git rebaseはzshのコマンド履歴を使用して極力入力しない（ブランチ名を指定する時はgit statusを実施してブランチ名をコピー&ペースト）

（rebase派とmerge派の論争もあるようですけど）私はrebaseとmergeを以下のように使い分けています。

• リモートブランチにpushしていないコミットに対してはgit rebaseを使用（ローカルブランチのコミットのハッシュ値は変更されますけど、まだpushしていないのでリモートブランチには影響無し）
• リモートブランチにpush済のコミットに対してはgit mergeを使用（この状態でgit rebaseを実施すると、Gitは新しいコミットを生成します。変更前のコミットはそのまま残ってしまい同じ変更差分のコミットが追加されます）

Dockerイメージとボリュームの削除（GUIの使用をオススメします）

Docker（Docker Compose）を使い続けると以下のような状況になることがあります。 （私はdocker-compose build/up/downを使用します）

• Dockerイメージの再ビルド
• Dockerコンテナの起動・停止を意図的に実施

上記を繰り返していると、Dockerイメージやボリュームの残骸が溜まっていきます。PCのストレージ容量に多少なりとも影響しますので、毎日の業務終了時には削除するよう心掛けています。

% docker images
REPOSITORY                                                        TAG       IMAGE ID       CREATED        SIZE
<none>                                                            <none>    636a862c409d   4 days ago     572MB
app-apache                                                        latest    3dc9ea38bfac   5 days ago     1.01GB
app-fluentd                                                       latest    3f9fc8f0f6c5   5 days ago     67.5MB
<none>                                                            <none>    0360082501e6   5 days ago     1.01GB
<none>                                                            <none>    931e18a5f20d   7 days ago     490MB
<none>                                                            <none>    67b7d740e142   8 days ago     1.01GB
...
public.ecr.aws/amazonlinux/amazonlinux                            2023      dae5a17b8297   3 weeks ago    144MB
%

不要なDockerイメージはREPOSITORYやTAG欄に<none>が記載されているもので、docker rmi [IMAGE ID]を実施することで削除できます。

% docker volume ls
DRIVER    VOLUME NAME
local     83b3a08dd7d029becf854b436450f40ba820767d1556ea2a1700a3839ede8d67
local     f76d9162b076ab9cd0d8a6de0455c4b3f9a690309a58dcc3cd12ffa6f67bda20
local     f2263df561903886539d1c93e31f82e4a9c08517934483563135aaece5c0e728
...
local     vscode
%

Dockerボリュームの場合は上記画面を見ただけではどのボリュームが不要（未使用）なのか分かりません。以下のようにJSONデータで詳細情報を出力することで使用中のボリューム（Labelsに値が設定されているもの）を把握することが可能です。（Dockerイメージも同様に--formatオプションを付加してJSONデータで詳細情報を出力できます）

% docker volume ls --format json
{"Availability":"N/A","Driver":"local","Group":"N/A","Labels":"","Links":"N/A","Mountpoint":"/var/lib/docker/volumes/1b0f427b783a09f6f1f58f97b86b9690d919743405ba09c9c173cd5e9a41dc47/_data","Name":"1b0f427b783a09f6f1f58f97b86b9690d919743405ba09c9c173cd5e9a41dc47","Scope":"local","Size":"N/A","Status":"N/A"}
{"Availability":"N/A","Driver":"local","Group":"N/A","Labels":"com.docker.compose.project=app-apache,com.docker.compose.version=2.18.1,com.docker.compose.volume=var_log_share_apache","Links":"N/A","Mountpoint":"/var/lib/docker/volumes/app-apache_var_log_share_apache/_data","Name":"app-apache_var_log_share_apache","Scope":"local","Size":"N/A","Status":"N/A"}
...
%

上記のDockerコマンド以外で効率的に削除する方法がないのかと思って調べていたところ、Dockerコマンドを2つ組み合わせることで未使用のイメージやボリュームが削除できることを知りました。

% docker rmi $(docker images -qf 'dangling=true')

% docker volume rm $(docker volume ls -qf 'dangling=true')

しかしこのようなコマンドを使用するより、Docker Desktop（GUI）を使用すると未使用イメージやボリュームが把握でき削除も簡単です。コマンドよりGUIの使用をオススメします。

まとめ

（ここに記載していないものも含めて）現在使用しているコマンドにも（私が知らないだけで）ベストな使い方はあると思います。GUIはコマンドより使いやすいものが多く、コマンドと併用することで効率的に業務が進めることができます。これからもコマンドやGUIをいろいろ試しながら自分のものにしたいです。最後に「（理解するのは大変だけど）私はGUIよりコマンドが好き」です。

【スタッフ募集中】
弊社ではAWSを活用したソリューションの企画・設計・構築・運用や、Ruby on Rails・JavaScriptフレームワークなどを使用したアプリケーション開発を行うスタッフを募集しています。採用情報の詳細
弊社での勤務に関心をお持ちの方は、知り合いの弊社社員・関係者を通じてご連絡ください。

---