新卒社員が初めてやってみた！GitHub編（Trying GitHub for the First Time as a New Graduate!）

こちらは次のオンラインイベントの公開資料になります。
＜イベントページ＞
https://ibm-developer.connpass.com/event/368322/

＜概要＞
本セミナーでは、新卒社員が体験した「初めてのGitHub」のリアルなエピソードを交えながら、GitHubの基本操作やつまずきポイント、解決のコツを共有します。 これからGitHubを使い始める方にとって「最初の一歩」を踏み出すきっかけとなる1時間です。

Transcript

1. 日本アイ・ビー・エム株式会社 テクノロジー事業本部 クライアントエンジニアリング 安田大輝、林萌英 新卒社員が初めてやってみた！ GitHub編
2. 2 1. 自己紹介・概要説明 2. GitHubってなに？ 3. ブランチ・マージ・コンフリクトの考え方 4. プルリクエスト(PR)・レビュー依頼の流れ 5. つまずきポイント＆Tips 6. まとめ・アンケート案内 7. 質疑応答・アンケート記入 目次
3. 3 1. 自己紹介・概要説明 2. GitHubってなに？ 3. ブランチ・マージ・コンフリクトの考え方 4. プルリクエスト(PR)・レビュー依頼の流れ 5. つまずきポイント＆Tips 6. まとめ・アンケート案内 7. 質疑応答・アンケート記入 目次
4. 4 自己紹介 林萌英 IBM（2025入社） クライアントエンジニアリング AIエンジニア 安田大輝 IBM（2025入社） クライアントエンジニアリング AIエンジニア 音楽ライブ！ 野球観戦！ 旅行！ アニメ！
5. 5 参加対象 • 新しくGitHubを学び始めたい新卒・若手エンジニア • GitHubを使ったチーム開発に向けて準備をしたい方 ゴール • GitHubによるチーム開発の最初のステップを踏み出せるようになる • 新人目線のつまずきポイントとその解決策を知る 注意点 • Gitの詳細なコマンドの説明は行わない • GitHubの画面操作やtipsを中心に解説する 本TechXchange Dojoの概要
6. 6 1. 自己紹介・概要説明 2. GitHubってなに？ 3. ブランチ・マージ・コンフリクトの考え方 4. プルリクエスト(PR)・レビュー依頼の流れ 5. つまずきポイント＆Tips 6. まとめ・アンケート案内 7. 質疑応答・アンケート記入 目次
7. 7 チーム開発で必要なGitHubの基礎概念を理解する！ 前半のゴール
8. 8 1. 自己紹介・概要説明 2. GitHubってなに？ 3. ブランチ・マージ・コンフリクトの考え方 4. プルリクエスト(PR)・レビュー依頼の流れ 5. つまずきポイント＆Tips 6. まとめ・アンケート案内 7. 質疑応答・アンケート記入 目次
9. 9 • Git: ファイルの変更履歴やバージョンを記録・管理するツール • GitHub: その履歴やバージョンをオンラインで保管・共有するサービス GitとGitHub PC内でバージョン管理 オンライン上で共有 個人作業 チーム開発 Git GitHub
10. 10 • ファイルや変更履歴をまとめて管理する”貯蔵庫” (保存場所) リポジトリ ローカルリポジトリ →自分のPC上 リモートリポジトリ →GitHub上 ファイルを共有 最新状態を取得
11. 11 Gitの基本フロー • 基本操作はadd、commit、push、pull ローカル リポジトリ リモート リポジトリ push pull ワークツリー (作業場所) インデックス (一時置き場) add commit
12. 12 GitHubの基本画面 ↑ タブ一覧 ←リポジトリ名 コミット履歴→ ファイル一覧→ README →
13. 13 Q1. エンジニアのYさんは友達と一緒に行く万博のしおりを作っています。 勉強のためにGitで変更を管理していて、 現状の変更はローカルリポジトリに記録済です。 この内容を友達に共有するには、次のどの操作が必要でしょう? A. add B. commit C. push クイズ1 (問題)
14. 14 クイズ1 (答え) Q1. エンジニアのYさんは友達と一緒に行く万博のしおりを作っています。 勉強のためにGitで変更を管理していて、 現状の変更はローカルリポジトリに記録済です。 この内容を友達に共有するには、次のどの操作が必要でしょう? A. add B. commit C. push : 変更を記録候補としてインデックスに載せる :ローカルリポジトリに変更記録を残す :ローカルの記録をGitHubに送り、友達と共有できる！
15. 15 1. 自己紹介・概要説明 2. GitHubってなに？ 3. ブランチ・マージ・コンフリクトの考え方 4. プルリクエスト(PR)・レビュー依頼の流れ 5. つまずきポイント＆Tips 6. まとめ・アンケート案内 7. 質疑応答・アンケート記入 目次
16. 16 ブランチ • ひとつのコミット履歴を”枝分かれ”させ、独立した作業ラインを作成 • 「main」では直接作業せず、必ずブランチを切ってから作業すること main (公開版) Aさんのブランチ ※安定版を汚さないこと！ • 他人の変更の影響なし • 複数機能を並行開発 Bさんのブランチ
17. 17 ブランチ (GitHub) 現在のブランチ→
18. 18 ブランチ (GitHub) ドロップダウンで 切り替え可能！
19. 19 ブランチ (GitHub) 新しいブランチ→
20. 20 マージ • 別々のブランチの内容を取り込んで統合する • 複数の作業をひとつにまとめ、mainなど統合先を最新の状態に保つ main (公開版) マージ1 マージ2 Aさんのブランチ Bさんのブランチ
21. 21 • 同じファイルの同じ箇所に異なる変更が加えられたときに起こる • どちらの変更を採用すべきかわからず、自動でマージできない状態 コンフリクト main (index.html) <h1>Expo Site</h1> Aさんのブランチ (index.html) <h1>大阪万博</h1> Bさんのブランチ (index.html) <h1>Osaka Expo</h1> マージ コンフリクト 発生！
22. 22 Q2. Yさんと友達のFさんは別のブランチでしおり作りを進めていました。 あるとき2人の変更をマージしようとするとGitがエラーを出しました。 考えられる原因として最も適切なものはどれでしょうか？ A. 万博の概要ファイルと世界各国の料理ファイルをそれぞれ編集した B. 同ページの「気になるパビリオンリスト」の行をそれぞれ編集した C. Yさんが最寄駅の名前を「夢島」(実際は夢洲) と誤って記載した クイズ2 (問題)
23. 23 Q2. Yさんと友達のFさんは別のブランチでしおり作りを進めていました。 あるとき2人の変更をマージしようとするとGitがエラーを出しました。 考えられる原因として最も適切なものはどれでしょうか？ A. 万博の概要ファイルと世界各国の料理ファイルをそれぞれ編集した B. 同ページの「気になるパビリオンリスト」の行をそれぞれ編集した C. Yさんが最寄駅の名前を「夢島」(実際は夢洲) と誤って記載した クイズ2 (答え) コンフリクトは同じファイルの同じ箇所に異なる 変更が加えられたときに起こる!
24. 24 • GitHub: Gitの変更履歴をオンラインで共有する場 • 基本操作: add、commit、push、pull • ブランチ: 複数人で安全に並行開発できる仕組み • コンフリクト: 同じ箇所に異なる変更がある状態で マージすると発生するエラー 前半のまとめ 後半ではいよいよ実践的なGitHubチーム開発を学びます！
25. 25 GitHubでプルリクエストとレビューの流れを理解し、 チーム開発で安全に変更を反映できるようになる！ 後半のゴール
26. 26 1. 自己紹介・概要説明 2. GitHubってなに？ 3. ブランチ・マージ・コンフリクトの考え方 4. プルリクエスト(PR)・レビューとは 5. つまずきポイント＆Tips 6. まとめ・アンケート案内 7. 質疑応答・アンケート記入 目次
27. 27 何のためにプルリクエスト・レビューをする？ • バグやコンフリクトの早期発見・防止 • mainブランチの品質と安定性を保つ • 変更内容をチームで確認・承認する • チーム内の透明性と合意形成を促進する • 不特定多数からの貢献を安全に受け入れる 開発者 コンフリクト/ バグ発生 利用者 push 開発者 プルリクエスト レビュー・マージ担当者 マージ レビューする バグが 起こりにくい 目的
28. 28 プルリクエストとは • 開発者のローカルリポジトリでの 変更を他の開発者に通知する機能 プルリクエスト・レビューって何？ レビューとは • 他のメンバーが変更を確認し、 改善提案や承認を行うプロセス 開発者 プルリクエスト レビュー・マージ担当者 マージ 〇〇を変更しました mainに取り込んで もらえますか？ フィードバック: ××を修正 してください OKです！
29. 29 プルリクエスト(PR)・レビューの流れ 開発者 レビュー・マージ担当者 ①開発 ②push ③プルリクエスト作成 ④レビュー ⑤修正が 必要か？ 修正は不要 ⑥マージ PRは不要 ⑦Close
30. 30 プルリクエスト(PR)・レビューの流れ 開発者 レビュー・マージ担当者 ①開発 ②push ③プルリクエスト作成 ④レビュー ⑤修正が 必要か？ 修正は不要 ⑥マージ PRは不要 ⑦Close ③を 解説します
31. 31 プルリクエストの操作
32. 32 プルリクエストの操作 注意 マージ先を間違えないように！ ターゲットブランチ： プルリクエストを マージする 対象のブランチ プルリクエストブランチ： マージしてもらうブランチ
33. 33 プルリクエストの操作 タイトル 説明文
34. 34 プルリクエストの操作 ＜説明文の書き方（例）＞ 行程表修正しました。 確認お願いします。 @Yasuda（確認して欲しい人） ### 目的・背景（Why） - イタリアパビリオンが10:00に予約取れず、12:00に予約できた ### 変更内容（What） - 昼食 12:00→11:00 - イタリアパビリオン 10:00→12:00（予約確定） ### 影響範囲 (Impact) - 集合場所・朝のスケジュールに変更なし - 昼食時間が11:00 に変更 - イタリアパビリオンの見学が昼食後に移動 ### 関連Issue #123 ### 動作確認方法 - `expo_schedule.md` を開き、以下を確認 ---以下省略---- 悪い例 良い例
35. 35 プルリクエスト(PR)・レビューの流れ 開発者 レビュー・マージ担当者 ①開発 ②push ③プルリクエスト作成 ④レビュー ⑤修正が 必要か？ 修正は不要 ⑥マージ PRは不要 ⑦Close
36. 36 レビューの操作（修正が必要な場合） 修正箇所をクリック
37. 37 レビューの操作（修正が必要な場合） コメントを入力
38. 38 レビューの操作（修正が不要な場合） マージする
39. 39 レビューワーのチェックポイント • 要件を満たしているか • 可読性（変数名・関数分割） • 安全性 • テストの有無 コメントのポイント！ 優先順位をつけてコメントするとわかりやすい
40. 40 レビューを受けたら（開発者側） レビュー内容確認 修正 →コミットとプッシュ プルリクエスト
41. 41 • プルリクエストとは： ローカルリポジトリでの変更を他のメンバーに通知する機能 • レビューとは： 他のメンバーが変更を確認し、改善提案や承認を行うプロセス ＞＞レビューを通して品質を高め、mainブランチの安定性を 守ることができる！ （ex. コンフリクトやバグの発生を防ぐ） プルリクエスト、レビューのまとめ
42. 42 Q3. Yさんは万博のしおりの、昼食の場所を変更しました。 変更をFさんにレビューしてほしいのですが、プルリクエスト説明文に 最低限書くべきことは何でしょう？ A. 「よろしくお願いします」だけ B. 何を変えたか／なぜ変えたか C. 参加者全員の自己紹介 クイズ3 (問題)
43. 43 Q3. Yさんは万博のしおりの、昼食の場所を変更しました。 変更をFさんにレビューしてほしいのですが、プルリクエスト説明文に 最低限書くべきことは何でしょう？ A. 「よろしくお願いします」だけ B. 何を変えたか／なぜ変えたか C. 参加者全員の自己紹介 クイズ3 (答え) @Yasuda（確認して欲しい人） ### 目的・背景（Why） - イタリアパビリオンが10:00に予約取れず、12:00に予約できた ### 変更内容（What） - 昼食 12:00→11:00 - イタリアパビリオン 10:00→12:00（予約確定） ### 影響範囲 (Impact) - 集合場所・朝のスケジュールに変更なし - 昼食時間が11:00 に変更 - イタリアパビリオンの見学が昼食後に移動 ### 関連Issue #123 ### 動作確認方法 - `expo_schedule.md` を開き、以下を確認 ---以下省略---- 先程紹介した、説明文の例→
44. 44 • プルリクエストとは： ローカルリポジトリでの変更を他のメンバーに通知する機能 • レビューとは： 他のメンバーが変更を確認し、改善提案や承認を行うプロセス ＞＞レビューを通して品質を高め、mainブランチの安定性を 守ることができる！ （ex. コンフリクトやバグの発生を防ぐ） プルリクエスト、レビューのまとめ もしコンフリクトしてしまったら、どうすればいいの？
45. 45 1. 自己紹介・概要説明 2. GitHubってなに？ 3. ブランチ・マージ・コンフリクトの考え方 4. プルリクエスト・レビュー依頼の流れ 5. つまずきポイント＆Tips 6. まとめ・アンケート案内 7. 質疑応答・アンケート記入 目次
46. 46 つまずきポイント＆Tips • コンフリクトの対処法 • よくある勘違い • プルリクエストという名前について
47. 47 コンフリクトの対処法 シナリオ： ブランチAとブランチBがどちらもmainブランチからしおりを編集 • ブランチA • イタリア：12:00 • 昼食：11:00 • ブランチB（別案） • イタリア：12:00 • 昼食：11:30 • タイムライン • ブランチA を先に main へマージ • 続いて ブランチB がPRを出すと、コンフリクト発生
48. 48 コンフリクトの対処法
49. 49 コンフリクトの対処法 コンフリクトの対処法（起きたら） • 何が衝突？→ ファイル/行と意図を確認（PR説明・Issueを読む） • 採用方針を決める：Aを採用 / Bを採用 / 内容を統合 • PRのResolve conflictsで編集 → マーカーを完全に削除 → 保存 コンフリクトの防止法（起きにくくする） • 編集範囲を分ける • 開発の粒度を分けて被らないように • ブランチ分けて開発 • 担当の明確化 →チームでルールを決めて開発しよう！
50. 50 つまずきポイント＆Tips • コンフリクトの対処法 • よくある勘違い • プルリクエストという名前について
51. 51 プルリクエスト ＝自分の環境へのpullをリクエストする？ ＝管理者に自分の変更を取り込んでもらう （管理者があなたの変更をpullして mainに取り込む） という依頼 なぜプルリクエストって名前なの？ ローカル リポジトリ リモート リポジトリ pull ブランチ main 管理者 変更しました 問題ないので 取り込みます
52. 52 GitHubの基本 • GitHub ： Gitの変更履歴をオンラインで共有する場 • 基本操作 ： add、commit、push、pull • ブランチ ：複数人で安全に並行開発できる仕組み • コンフリクト：同じ箇所に異なる変更がある状態でマージすると 発生するエラー チーム開発をするために • プルリクエストとは： ローカルリポジトリでの変更を他のメンバーに通知する機能 • レビューとは： 他のメンバーが変更を確認し、改善提案や承認を行うプロセス 全体のまとめ
53. 53 • Git公式ドキュメント https://git-scm.com/book/ja/v2 参考
54. 54 アンケート 本勉強会のご感想を 右のQRコードからご回答お願いします。 今後聞きたいテーマも募集しておりま すので、ご意見をお聞かせください。
55. 55 Q&A
56. 56 ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報 提供の目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またIBM製品やサービスがお 客様に適用ある特定の法令に適合することを保証するものでもありません。本講演資料に含まれている情報については、完全性と正確性を期するよう努 めておりますが、「現状のまま」提供され、明示または黙示にかかわらず、商業性、特定の目的への適合性、非侵害性を含め、いかなる保証も伴わない ものとします。本講演資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害が生じた場合も、IBMは責任を負わない ものとします。 本講演資料で言及されるIBM製品、プログラム、またはサービスは、IBMがビジネスを行っているすべての国・地域でご提供可能なわけ ではありません。本講演資料で言及される将来の展望（製品リリース日付や製品機能を含む）は、市場機会またはその他の要因に基づいてIBM独自の決 定権をもっていつでも変更できるものとし、将来の製品または機能が使用可能になること、もしくは特定の結果を確約することを意図するものではあり ません。本講演資料は、言及される IBM製品またはサービスに適用ある契約条件を変更するものでも、追加の表明または保証を意図するものでもありま せん。 本講演資料に含まれている内容は、参加者の活動によって特定の結果が生じると述べる、または暗示することを意図したものでも、またそのような結果 を生むものでもありません。 パフォーマンスは、管理された環境において標準的なIBMベンチマークを使用した測定と予測に基づいています。ユーザー が経験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、ストレージ構成、 および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで述べられているものと 同様の結果を得られると確約するものではありません。記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、ま たそれらのお客様が達成した結果の実例として示されたものです。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。 • IBM、IBM ロゴ、ibm.comは、 世界の多くの国で登録されたInternational Business Machines Corporationの商標です。他の製品名お よびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストについては、 www.ibm.com/legal/copytrade.shtmlをご覧ください。