Gitの事前準備
RDi の開発でGitを使用する手順を解説していくが、まずは事前準備として以下を実施しておく。
今回はサンプルとして、IBM i 上で SEU／PDM を使用して開発している架空のシステム「slack 連携システム」をGit管理する手順を説明する。
ライブラリー：contoslack
ソースファイル：QCLLESRC、QCLSRC、QDDSSRC、QRPGSRC、QRPGLESRC
プッシュ先LIB：slackogawa（事前に作成しておく）
EGit のインストール
RDiでGitを操作するには、EGitプラグインを使用する。RDi導入時、もしくは導入後に IBM Installation Managerから「Eclipse Git Teamプロバイダー」をインストールしておこう。
RDi でGitパースペクティブが表示される場合は、 EGit はインストール済みである。
バージョン管理の前準備
RDiで開発する場合は、リモート・システム・エクスプローラー（以下、RSE）を使って IBM iに接続した状態で作業するケースが多いだろう。RSEはIBM iのソースファイル内のメンバーを直接操作する必要があるからだ。
しかしGitでバージョン管理するには、ソースコードをローカルのディスク内に置く必要がある（図表3）。
① ソースコードをダウンロードする場所
② Git リポジトリ
③ ダウンロードしたコードをコミット
そのため、Gitでバージョン管理するのはRSE経由ではなく、以下のいずれかを選択して構成および作業する。
iプロジェクト
PC に配置したソースコードを管理し、事前に定義した接続設定を使用してIBM iのソースファイルのメンバーにコードをプッシュする。定位置形式のコード（RPG Ⅲ、ILE RPG）のバージョン管理を実施したい場合はこちらを選択する（以降は、iプロジェクトを例に解説する）。
IFSプロジェクト
PCに配置したソースコードを管理し、事前に定義した接続設定を使用してIBM iのルート・ファイル・システムにコードをプッシュする。RPG Ⅲ で開発しない場合は、こちらの選択も可能である。
それではiプロジェクトの使用を例に取って、以下に事前準備を解説していく。
iプロジェクトの事前準備
まずは、Gitでバージョン管理したいソースファイルをPC上にコピーする。ここでは、RDi でワークスペース（ワークスペース名は iMagazine）を起動し、IBM iへの接続も作成および接続済みであることを前提に進める（図表4）。
バージョン管理に不要な情報を除去
IBM iソースファイルのレコードは、以下の3つのフィールドで構成される。
1. 順序番号（SRCSEQ）
2. 日付（SRCDAT）
3. ソースコード（SRCDTA）
1と2はSEU が使用する項目であり、Gitで管理する必要はないので、ダウンロード時に除去するように設定する（図表5）。
ユーザー名とメールアドレスの登録
コミットするユーザーを特定するためのユーザー名とメールアドレスを登録する。ウィンドウ→設定で設定ウィンドウを開き、チーム→Git→構成と進む。エントリーの追加をクリックし、以下のキーと値を指定して登録する（図表6）。
ユーザー名：user.name
メールアドレス：user.email
iプロジェクトの作成
iプロジェクトを作成し、事前に作成した接続を使用して、IBM i上でバージョン管理を開始したいソースファイルをPCにインポートする。プロジェクト名は、ソースライブラリー名と同じにしておくとわかりやすい。
ファイル→新規→その他と選択して、「ウィザードを選択」画面を表示する。ウィザード欄にIBMと入力して、その下でローカルの「IBM i プロジェクト」を選択し、「次へ」をクリックする（図表7）。
プロジェクト名に「contoslack」、デフォルト・ロケーションの使用のチェックを外してロケーションを指定する。ロケーションは任意のディレクトリを指定可能だが、今回はわかりやすいようにC:¥contoslackと指定して、「次へ」をクリックする（図表8）。
iプロジェクト・プロパティーの接続は事前に構成した接続を選択し、関連ライブラリーはプッシュ先ライブラリーを指定して、「終了」をクリックする（図表9）。
iプロジェクト・パースペクティブを開くか聞いてくるので、「はい」をクリックする（図表10）。
ソースコードのインポート
作成したiプロジェクト（実態はc:¥contoslackディレクトリ）に、バージョン管理対象のソースコードをインポートする。ソースファイルはディレクトリとして、ソースコードはテキストファイルとして、それぞれインポートする。
iプロジェクト・パースペクティブの左上のiプロジェクト・ビュー内で右クリックし、リモート・ソースのインポートをクリックする（図表11）。
ライブラリーの処理にて取り込むソースファイルのライブラリーCONTOSLACKを指定する（図表12）。
表示されたCONTOSLACKを展開し、すべてのソースファイルを選択してOKをクリックすると、ソースコードがダウンロードされる（図表13）。
ソースコード内に連続したシフト文字がある場合は、その旨の通知が表示されるので、通常は「はい」（ブランクで置き換える）で進む（図表14、図表15）。
iプロジェクト・ビュー内のcontoslackを展開して、ソースコードがダウンロードされていることを確認する（図表16）。
Gitリポジトリの作成
次に、iプロジェクト内にバージョン管理で利用するGitのリポジトリを作成する。
iプロジェクト・ビュー内のcontoslackで右クリックし、チーム→プロジェクトの共有を選択し、リポジトリー・タイプでGitを選択して「次へ」をクリックする（図表17）。
すると、Gitのリポジトリをどこに作成するかの指定画面が表示される。今回は先に作成したiプロジェクトのロケーション内に作成するので、「プロジェクトの親フォルダのリポジトリーを使用するか作成します」のチェックボックスにチェックを入れる（図表18）。
表示されたプロジェクト（ロケーションがC:¥contoslackの行）をクリックして、左下のリポジトリの作成ボタンをクリックする（図表19）。
リポジトリが作成（:¥contoslackフォルダ内に.gitフォルダが作成）されたら、「終了」をクリックする（図表20、図表21）。
ソースコードをGitリポジトリにコミット
ここまでで、IBM i からローカルにソースコードをダウンロードし、バージョン管理するための Gitリポジトリを作成できた。しかし現在の状態は「HEADなし」、つまりワークツリーの内容のコードはバージョン管理されていない。そこで次に必要なのは、現在のコードをGitリポジトリにコミットすることである。
RDiでGit 関連の処理を行う場合は、Gitパースペクティブを使用する。まず、RDiの右上のパースペクティブを開くアイコンをクリックし、Gitを選択してOKをクリックし、Git パースペクティブを開く（図表22、図表23）。
それから左側のGitリポジトリ・ビュー内のcontoslackを選択し、Git ステージング・ビュー内の未ステージの変更の全ファイルを選択し（どれか1つを選択してCtrl＋A）、ステージ済みの変更欄にドラッグ＆ドロップで移動する。
続いてコミット・メッセージに「最初のコミット」と入力して、右下のコミットボタンをクリックすると、選択したファイルがリポジトリにコミットされる（図表24）。
Gitリポジトリ・ビューのリポジトリで右クリックし、表示→履歴とクリックすると、履歴ビューにコミット情報が表示される。IDには、コミットID（40桁）の先頭7文字が表示されている（ほとんどの場合、この7文字だけでコミットを一意に識別できる）（図表25）。
リモート・リコンサイラーの設定
iプロジェクトで修正・保管したタイミングで、自動的にIBM iにプッシュするにはリモート・リコンサイラーを利用する。
プッシュする先のソースファイルを複数人で共有していると、プッシュ時に競合が発生する可能性があるので、できれば個人のライブラリーにプッシュするように設定しておきたい。
その際に重要なのは、ソースコードをSEUで修正しないこと。その場合も競合が発生する可能性が高く、またSEUでの修正は明示的にローカルにコピーしないとバージョン管理対象にならない。
まず、右上のiプロジェクト・アイコンをクリックして、iプロジェクト・パースペクティブを開く（図表26）。
下に表示されているリモート・リコンサイラー・タブをクリックする。状況のローカル変更は、まだリモートにプッシュしていない修正があることを意味する（図表27）。
リソースcontoslackで右クリックし、プッシュ／プル設定→保存時にプッシュをクリックすると、iプロジェクト・プロパティーの関連ライブラリーに指定したライブラリーにソースが転送される（フォルダと同名のソースファイルがない場合は自動的に作成される）（図表28）。
転送が完了すると、状況欄が空欄になる。
リモート・リコンサイラーを構成すると、IBM iに接続した状態での作業が基本となる。未接続のままでソースを更新した場合は、あとでまとめて送信する必要がある。
チームで連携して作業する場合
IBM iの基幹システムはチーム開発がほとんどであろう。その場合は、プロジェクト管理者とメンバーとで、Git の初期作業に違いがある。
まず、先ほどまでの作業（コードのダウンロード、リポジトリの作成、初期コミット）は管理者が実行する。管理者はその後、他のメンバーがアクセス可能なサーバーにリモート・リポジトリを作成し、ローカルのリポジトリの内容をプッシュする。
プロジェクトのメンバーは、サーバーにあるリポジトリをローカルにコピーする。この作業を「クローンする」という。
実際の手順は用意するサーバーの種類によって異なるので、ここでは割愛するが、これは IBM iに依存しない作業であり、インターネット上に多くの情報があるので積極的に活用してほしい。
先ほどのリポジトリをオンプレミスで構成したGitLabにプッシュした直後のイメージは、図表29のとおりである。
以下では、リモート・サーバーにオンプレミスのGitLabを使用し、プロジェクト・メンバーはリポジトリのクローンが完了しているところから説明を進める。
著者｜
小川 誠氏
ティアンドトラスト株式会社
常務取締役
1989年、エス・イー・ラボ入社。その後、1993年にティアンドトラストに入社。システム/38 から IBM i まで、さまざまな開発プロジェクトに参加。またAS/400 、IBM i の機能拡張に伴い、他プラットフォームとの連携機能開発も手掛ける。IBM i 関連の多彩な教育コンテンツの作成や研修、セミナーなども担当。2021年6月から現職。
［i Magazine・IS magazine］
