はじめに
- 第4回でGitの基礎コマンドを実⾏して、イメージの確認を⾏いました。
- 今回は、第3回の続きの作業となります。
- 分散型バージョン管理の良さ、開発チームでの運用を理解いただけるようなシナリオでお届けします。
※本記事を印刷してご覧になりたい場合は、iWorld会員向けに公開しているPDF版「VS CodeでGitを触ってみよう(3) 基礎学習編」をご利用ください。
本記事におけるシナリオの前提
- future-x ブランチは、Aさんの作業ブランチ
- future-y ブランチは、Bさんの作業ブランチ
Aさん作業
1.新規ブランチ作成とcheckout

git checkout
ブランチの概念については、第3回「VS CodeでGitを触ってみよう(1) 基礎学習編」をご参照ください。
まずは、前回までのブランチの状況のイメージ確認です。
現在は、mainブランチしかなく、ローカルリポジトリとリモートリポジトリは全く同じ管理環境にあります。
それでは、新規でブランチを作成していきます。まずは、左下にあるmainのブランチを押下してください。

新しいブランチを以下から作成…を選択します。

ブランチの作成元として、HEAD(現在、作業をしているローカルブランチの先頭を示すポインター)を選択します。

作成先ブランチの名前は、future-xとします。

左下のローカルリポジトリが参照しているブランチが変更されました。

イメージ図の確認(1)
ここまでのイメージ図は、以下の通りです。

2.future-xブランチでソースを修正し、リモートリポジトリへブランチ展開
ソース修正
以下の通り、hello.rpgleのソースを修正します。
dcl-proc main; dcl-pi *n; #message char(30); end-pi; dsply ('こんにちは!' + #message); dsply ('追加修正') end-proc;
git add/commitをする
git addの操作をし、ステージングを行った後、commitコメントを追記し、コミットボタンを押下します。

リモートリポジトリへ新しいブランチを公開する
- 現在、ローカルリポジトリにのみfuture-xブランチが存在している状況です。リモートリポジトリにもfuture-xブランチを公開します。
- Branchの発行ボタンを押下してください。

GitHubのブラウザーを開き、リモートリポジトリに新しいブランチが展開されていることを確認します。

イメージ図の確認(2)
ここまでのイメージ図は、以下の通りです。

Bさん作業
3.mainブランチからfuture-yブランチを作成、ソース編集
続いて、再度左下の現在のブランチfuture-xを押下し、ローカルリポジトリのmainブランチからfuture-yブランチを作成します。


ソース修正
以下の通り、hello.rpgleのソースを修正します。ポイントは、future-xの修正と同じ行を修正している点です。
**free ctl-opt dftname(hello); ctl-opt dftactgrp(*no) main(main); //--------------------- // main処理 // CALL PGM(XXXLIB/HELLO) PARM(('iWorld' (*CHAR 30))) //--------------------- dcl-proc main; dcl-pi *n; #message char(30); end-pi; dsply ('こんにちは!' + #message + '修正2'); end-proc;
git add/commitをする
git add操作後、commitコメントを追記し、コミットボタンを押下します。

イメージ図の確認(3)
ここまでのイメージ図は、以下の通りです。

Aさん作業
4.リモートリポジトリでマージをする main←future-x
GitHubのブラウザー上でpull requestを作成する
リモートリポジトリのmainブランチにfuture-xブランチをマージしていきます。とはいえ、レビューなしでマージというのはなかなかにリスクがあります。
そこで登場するのが、pull request(PR)です。
- Pull request(PR) は、GitHubのリモートリポジトリで使われる機能で、「自分の作業ブランチ(例:future-x)の変更を、メインのブランチ(例:main)に取り込むため、変更内容のレビューと承認を行ってもらうための仕組みです。チーム開発では必須のプロセスです。
- 使う場面
- 新しい機能を追加したとき
- バグを修正したとき
- 他の人にレビューしてもらいたいとき
それでは、Compare & pull requestのボタンを押下します。

画面上部を確認すると、base:main ← compare:future-x と表示されているので、想定したPRとなっていることが分かります。
pull requestの中身を書いていきます。

サンプルは以下の通りです。何を変更し、なぜ変更を加えたかを記載するようにすることをおすすめします。書き終えたら、Create pull requestを押下します。
(今回はセルフレビューのため、ReviewersやAssigneesにメンバーをアサインしていません。通常の開発時は、メンバーアサインをお忘れなく)
# What - hello.rpgleのdsplyメッセージを追加 # Why - hello.rpgleのdsplyメッセージを追加する要件があった
PRが作成されると、Pull requestsのタブに1つPRがあることが分かります。レビュアーはReview changesを押下して内容を確認します。変更点を確認の上、承認を行います。

承認が終わると、レビューイまたはレビュアーが、以下のMarge pull requestを押下し、mainへMargeするという運用になります。

Marge pull requestにもコメントを書いて、Confirm mergeを押下します。

PRのステータスがMergedになりました。このタイミングで不要になったfuture-xのブランチは、Delete branchを押下して削除してしまいます。

イメージ図の確認(4)
ここまでのイメージ図は、以下の通りです。

Bさん作業
5.リモートリポジトリの最新情報をローカルリポジトリに反映させる
リモートリポジトリの最新情報を把握するには? git fetch
future-yは、mainから複製(分岐)して作成したブランチでした。その時から、リモートリポジトリのmainブランチにはfuture-xがマージされており、変更が発生しています。
Bさんは、pushをしてリモートリポジトリに変更がないかを確認します。
Ctrl + Shift + Pキーを押下し、git fetchコマンドを実行し、リモートリポジトリの最新情報を取り寄せます。
- git fetchコマンドは、リモートの最新情報を取得するだけで、ローカルの作業ブランチには自動で反映されません。必要に応じて merge や rebase を使って取り込みます。

変更があることが分かりましたので、origin/mainすなわち、リモートリポジトリのmainブランチの最新情報を取得します。変更の同期を押下してください。

OKを押下します。

ローカルリポジトリのmainブランチに、修正点が取り込まれたことを確認しました。

checkoutをして、future-yブランチに切り替えます。

イメージ図の確認(5)
ここまでのイメージ図は、以下の通りです。

Bさん作業
6.future-yブランチをリモートリポジトリへ展開、分散型バージョン管理でトラブル回避
ローカルリポジトリでマージを行う main←future-y
リモートリポジトリのmainの変更をローカルリポジトリに取り込んだので、続いて、ローカルリポジトリ内でmain←future-yをmergeさせます。
Ctrl + Shift + Pキーを押下し、git merge入力、今回はGit Stage All Mearge Changesを選択します。

マージ元は、ローカルリポジトリのmainブランチを選択します。

すると、同じ行に対して修正を加えていたため、conflictが発生し、どちらを「正」とするかを判断します。
- conflictとは、複数の変更が同じ場所に入ってしまい、どちらを採用すべきかGitが判断できない状態のことです。Gitが「ここがコンフリクトしているよ」と教えてくれるので、どちらを残すかを選択、あるいは両方をうまく統合して手動で修正します。
今回は両方の変更を取り込むを選択しました。


future-yにmainの変更点をマージできる準備が整いました。続行を押下し、マージを続行します。

git addをして、commitメッセージを入れ、変更を同期を押下します。

OKを押下します。

future-yのブランチがリモートリポジトリに公開されました。

ソースを確認すると、dsply命令の行が3行になっています。

イメージ図の確認(6)
最終的なイメージ図は、以下の通りです。

おわりに
- 今回は、VS Codeを使ってGitの基本操作を実践的に学びました。
- リモートとローカルの違い、Pull Requestの流れ、そしてコンフリクトの解消まで、チーム開発に欠かせない知識が身についたと思います。
- 次回はIBM i のソース管理について深掘りしていきます。
筆者
|
日本アイ・ビー・エム株式会社
Qiitaに、シュッとシリーズを投稿中 |