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]