さて前回の Git導入に続き、第3回ではIBM i開発でよく使われるバッドノウハウを解決していきましょう。そしてGit は1人で利用しても、その恩恵に預れることをお伝えしていきたいと思います。
前回書いた3つのバッドノウハウを簡単な言葉にすると、以下のように推察されます。
（1） ソースコードを改変した時に、元に戻せないと不安。
（2） 大規模修正では最悪の事態も考えて、スナップショットがほしい。
（3） ソースコードの改変で差分や履歴がわからなくなる。
確かに、これら3つの事象をはPDM や SEU だけでは解決できません。そのため前回お話したようなバッドノウハウが次第に横行することになり、秩序のないソースコードが生まれます。これらの課題を Git を使って解決していきましょう。
Gitでソース管理する単位を「リポジトリ」と言います。これにはチーム開発などでメンバーが最終的にソースの変更を上げてくる種類のリポジトリ（リモート・リポジトリ、セントラル・リポジトリなどと呼びます）と、自分自身の変更を管理しているローカル・リポジトリがあります。
今回はファースト・ステップなので、リモート・リポジトリは使わず、クライアントのソース管理はローカル・リポジトリで実行し、最終的なIBM iへのソース配置は、SSHのファイル転送（VSCodeのSSHFS）を利用します。当然ながらチーム開発の場合は、 リモート・リポジトリで運用する必要があります。
それではバッドノウハウ を解決する前に、準備を始めます。これまでに、GitをIBM iにも PC にも導入しているので、どちらでもGit コマンドは利用できる状態になっています。
今回の準備
（1）まず前回のソースを一度削除し、ディレクトリ内を.gitignoreのみとしたクリーンな状況にします。
（2）次にリポジトリに初期状態を記録します。この操作で、前回利用した.gitignoreファイルだけをcommitすることになり、コメントとしてfirst commitとします。
PC上でGitリポジトリを管理する場合は、VS-Code上の左側のサイドバーより Git を選択し、 [変更]の＋マークをクリックし、[すべての変更をステージ] にします。
PC上で管理するメリットは、IBM iとオフライン状態でも開発を進められることです。PCで開発後、IBM iのIFSにアップロードしてコンパイル作業を行います。
ただしPC上にしか最新ソースが存在しないため、バックアップ等の管理を別途行う必要があります。
次に、[メッセージ(‘masterでコミット…)]のボックス内にコメントを登録し 、commitします。
commitに問題がない場合、 Git Graph により視覚的に履歴を確認できます。
IBM iでgitリポジトリを管理する場合
IBM i上で Gitリポジトリ を管理する場合は、SSH（QP2TERMでも可能ですが、ここでは割愛します）で接続し、シェルでGitコマンドを操作します。
IBM i上で管理するメリットは、すべてのソース管理がIBM iに統合されるため、IFS のバックアップ運用がそのまま適用され、ソース・ファイルのアップロード作業も不要になる点です。
SSH FS の [Open Remote SSH Terminal] を実行すると、下の **[ターミナル]**ペインで、IBM i のIFSソース保管ディレクトリへ移動できます。
次に Git リポジトリの初期化を行うコマンドの例を記載します。
# リポジトリの初期化
git init
# リポジトリの状態確認
git status
# ↓ .gitignore が編集されているが、git管理に追加されていない状態
Untracked files:
(use “git add <file>…” to include in what will be committed)
.gitignore
# .gitignore をgit管理に追加する
git add .
# リポジトリの状態確認
git status
# ↓ .gitignore git管理に追加されているが、commit されていない状態
Changes to be committed:
(use “git rm –cached <file>…” to unstage)
new file: .gitignore
# 変更をコミット
git commit -m “first commit”
# コミット履歴の確認
git log
commit f09ef17a2946dadcd443b5a3d85284dd79a236bb (HEAD -> master)
Author: Yoshiki Ushida <ushida@cscweb.jp>
Date: Tue Mar 30 03:03:17 2021 +0900
first commit
これより先は、PC上に Git リポジトリを作成した例として解説します。
準備は整いました。それでは3つのバッドノウハウを解決していきましょう。
バッドノウハウ1
ソースメンバーを改変した時にバックアップメンバーを保存しておかないと心配系
以下は、我々が開発時によく見かけるメンバーのバックアップ例です。各企業によって文化は異なれど、今でもメンバーを複製するケースはよく見かけます。
このケースのデメリットの一例を以下に挙げてみます。
・QRPGSRC.AAA001 というメンバーを QRPGSRC.AAA001_1 、 QRPGSRC.AAA001@1 、 QRPGSRC.AAA001.B1 等へ、管理不要なメンバーを増殖させる
・ソース検索した時やシステム改修でノイズだらけでになる
・不要なソースをオミットするために、無駄な工数が生じる
・ソース検索→ワードがヒット→不要なソースとわかると、精神的にイライラする
以前にも言及しましたが、ここに挙げた例のように、このメンバー複製行為は、本番ソースに対するノイズとなり、システム変更時には大きな妨げになります。
このケースでは、VCS（Version Controll System）を使ってソースの世代管理がされていれば、いつでも履歴を参照できるので不要な行為となります。
それでは、実践していきましょう。前回用意したソースと同様のIMAG0001.rpgle を再度用意して、Git 管理上のディレクトリに保存します。
そして左のサイドバーよりGitを選択し、[すべての変更をステージ]しcommitします。
ここでもcommit に問題がない場合、 Git Graph により視覚的に履歴を確認できます。
それでは先ほどのソースに改修が発生したとのシナリオで、適当にIMAG0001.rpgle を変更します。変更を終えたら、再び左のサイドバーよりGitを選択し、[すべての変更をステージ] し commit します。
gitでソースの変更履歴を確認する
それでは先ほどのソースの修正差分を確認するために、Git Graphからcommit履歴を覗いてみましょう。
すると、ソースの変更した箇所だけが明確にわかるります。もう、複製したメンバーと現在のメンバーに CMPPFM コマンドを実行必要はありません。
gitでソースを過去に戻す
続けて先ほどのソースの修正の前に戻してみましょう。同様にGit Graphから操作します。ソースの状況を戻す方法はいくつかありますが、今回はcommitを打ち消すcommit を作成し、コミットを戻したという履歴を残すケースの revert を行います。
そしてソースは 、打ち消しcommitの履歴とともに、ソースも編集前に復元されています。
いかがでしょうか。メンバーの複製に比べてとてもスマートで、独りで運用しても十分にGit を利用するメリットが感じられませんか。
revert 以外にも過去の状態に戻す手段はいくつかあるので、みなさんも試してみてください。
バッドノウハウ2
大規模修正では改変前のソース環境をまるごと保存系
修正前の環境に戻れるように、SAVLIB 等のコマンドでまるごとソース・ライブラリを保存するケースがあるかと思います（ほかにもSAVFや保存媒体に保管するケースもあるでしょう）。
結果的にこれもソースの2重管理であり、しかも保管先媒体やネーミングルールを含めて、人間系での管理となります。
確かに大規模にソースを変更する際には、「いつでも過去のソース環境を戻したい」という欲求があります。そのようなケースもGitのbranch機能を利用して、いつでも過去ソース環境の状態に切り替えられます。
それでは、 Git Graph から Create Branch を実行します。ブランチ名は newPJ とでもしておきましょう。
新しく branch を切り、 checkout することにより、これ以降の作業はnewPJ ブランチに反映され、masterブランチは最終コミット時点で止まったままとなります。従って、いつでも master ブランチが指し示すcommit 時点に戻せます。
それではnewPJ ブランチにソースを追加したり、修正したり、あらゆる操作を試みてください。
そして過去に戻りたくなった場合はmaster ブランチをcheckout しましょう。Git Graphから、branch名のラベルをダブルクリックするか、右クリックで[Checkout Branch]をするだけで、タイムマシーンに乗れたはずです。
そして新たに改修終了後には、作成したnewPJブランチをオリジナルのmasterブランチに合流することもできます。
バッドノウハウ3
ソースコードの改変が不安だから、ソースコード内に大量のコメントとして改変前のソースコピーを残す系
我々はたびたび、次のようなソースコードを見かけます。
このようなケースも、これまで進めてきた Git 活用で、不要な行為になることを読者の皆様ならすでにお気づきでしょう。
Git Graph は視覚的であり、Gitコマンド を意識させない、とても便利なツールですが、もちろんGit diff などのGitコマンド を活用して、現在と過去のソースを簡単に比較することもできます。
さらに、パッチの差分のファイルも作成できます。
IBM iをリモート・リポジトリとする
それでは最後に、これまで開発してきたPC上のローカル・リポジトリのソースを、IBM iをリモート・リポジトリとして、push してみましょう。
IBM iをリモート・リポジトリとすることにより、各開発者はIBM iより最新のソースをPC上へcloneできます。
手順は次のとおりです。
1 IBM i側の処理
IBM i側の処理は次のとおりです。
・IBM iにSSHで接続する
・リモート・リポジトリ用のディレクトリを作成する
・以下の Gitコマンド でリモート・リポジトリを作成する
# ディレクトリを作成
mkdir remote
# ディレクトリへ移動
cd remote
# リポジトリの初期化
git init –bare –shared=true
# 内容確認
ls -la
$ /home/ushiday/src/ushiday@hack/remote% ls -la
total 84
drwxrwsr-x 7 ushiday qsecofr 8192 2021-03-31 03:50 .
drwxr-xr-x 4 ushiday qsecofr 8192 2021-03-31 03:48 ..
-rw-rw-r– 1 ushiday qsecofr 23 2021-03-31 03:50 HEAD
drwxrwsr-x 2 ushiday qsecofr 8192 2021-03-31 03:50 branches
-rw-rw-r– 1 ushiday qsecofr 145 2021-03-31 03:50 config
-rwxrwxr-x 1 ushiday qsecofr 73 2021-03-31 03:50 description
drwxrwsr-x 2 ushiday qsecofr 12288 2021-03-31 03:50 hooks
drwxrwsr-x 2 ushiday qsecofr 8192 2021-03-31 03:50 info
drwxrwsr-x 4 ushiday qsecofr 8192 2021-03-31 03:50 objects
drwxrwsr-x 4 ushiday qsecofr 8192 2021-03-31 03:50 refs
2 PC 側の処理
PC側の処理は次のとおりです。
・Git Graph で + Add Remote を行う。
・リモート・リポジトリへpushする。
これでリモート・リポジトリに最新のソースが配置されたので、別の開発者はいつでもソースをIBM i上からclone することが可能です。
また IFS のバックアップが行われていれば、自然とソースのバックアップもされることになります。
以下はclone コマンドの例です。
# リモートリポジトリよりクローン
git clone ssh://ushiday@hostname/home/ushiday/src/ushiday@hack/remote
Cloning into ‘remote’…
remote: Counting objects: 15, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 15 (delta 4), reused 0 (delta 0)
Receiving objects: 100% (15/15), done.
Resolving deltas: 100% (4/4), done.
# ソースを確認
ls -la
drwxr-xr-x 1 ushida 197121 0 3? 31 04:23 ./
drwxr-xr-x 1 ushida 197121 0 3? 31 04:23 ../
drwxr-xr-x 1 ushida 197121 0 3? 31 04:23 .git/
-rw-r–r– 1 ushida 197121 141 3? 31 04:23 .gitignore
-rw-r–r– 1 ushida 197121 629 3? 31 04:23 IMAG0001.rpgle
-rw-r–r– 1 ushida 197121 620 3? 31 04:23 IMAG0002.rpgle
さて4回にわたり、1人でもGit とIBM iの yum を活用して Gitのメリットを十分に享受できることをお伝えしてきました。とくに最後のIBM iでの リモート・リポジトリ運用は、当社でも大活躍しています。
ぜひみなさんも Git や yum パッケージを利用して、開発効率を向上させてください。では、次のHackでお会いしましょう。
［i Magazine・IS magazine］
ushiday@Hackな日々
第1回 テーマはyum
第2回 yumでGitを使おう ～その１
第3回 yumでGitを使おう ～その２
第4回 yumでGitを使おう ～その３
第5回 ncdu ～ディスク使用量を調査する便利コマンド
