これから始めたい人集合！ ゼロから学ぶGit_GitHub入門

第11回とことんDevOps勉強会で登壇した際のスライドです。

Transcript

1. これから始めたい人集合！ ゼロから学ぶGit/GitHub入門 日本仮想化技術株式会社 VirtualTech.jp 2023/04/27 1
2. 2 自己紹介
3. Gitとは？ 3
4. Gitとは • ソースコードなどの変更履歴を記録・追跡するためのバージョン管理システムの1つ ◦ Subversion(SVN)のアーキテクチャを集中型と表現とし、Gitは分散型と言われている • Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発 ◦ 現在のメンテナは濱野純という方で、2005年7月から担当 • ローカルリポジトリとインデックスと呼ばれる領域の考え方があるのが特徴の1つ 4
5. GitHubとは？ 5
6. GitHubとは • Gitの仕組みを使用してリモートリポジトリの機能を提供するサービスの1つ ◦ 類似サービス：GitLabやBitBucket、CodeCommit(AWS)など • 複数のメンバーと開発を行う時はリモートリポジトリが必要 • 最近の主なニュース： ◦ 2023/01に1億人ユーザー突破 ◦ Subversionのサポートを2024/01で完全に終了すると発表 6
7. Visual Studio Codeとは？ 7
8. • Visual Studio Code=VS Code、code • 主な機能 ◦ シンタックスハイライト、スニペット、インテリセンス、リファクタリング、デバッグ、テスト • 元々はHTML5ベースのWebブラウザーで動くエディター&ツールフレームワークとして開発 ◦ Internet Explorer(IE)やMicrosoft EdgeのF12開発者ツール など • ブラウザー版で一定の成功を納めたのち、より高みを目指してデスクトップ版の開発にも着手 ◦ Electron上で構築 • 2015年04月 Build 2015(Microsoftの開発者向けカンファレンス)でプレビュー版が発表 ◦ 「Code editing, redefined」(コードエディターの再定義)のスローガンを掲げている ◦ 統合開発環境(IDE)とテキストエディターの中間的な位置付け • 2015年11月にオープンソースとして公開 ◦ オープンソースな場で開発を行い、ブランド製品としてリリースしている(Chromiumと同じようなスタイル) ◦ Visual Studioからより高速に開発サイクルを回すために機能を絞って軽量なエディターとして作られた • 拡張機能から拡張APIを通じてほぼすべての機能にアクセス可能 • リリースサイクルは、毎月第1金曜あたり。 ◦ Youtubeでリリースパーティがライブ配信される Visual Studio Codeとは？ 8
9. ツールはCLI派？GUI派？ 9
10. GUIツールとCLIツールはどちらを使うべき？ GitやGitHubの作法に慣れるまではGUIツールを使うことをおすすめ 慣れてくるとより高度な操作や効率化などがやりたくなってきてからCLIのマスターも目指す 10
11. ① 0から新しく開発プロジェクトを開始 (ローカル→リモート) ② 既存の開発プロジェクトに途中から参加 (リモート→ローカル) まず覚えたい2つの流れ 11
13. ① 0から新しく開発プロジェクトを開始 13
15. プロジェクトの作成 15
17. プロジェクトの作成 17 • 『mkdir sample-project』 ◦ 任意のディレクトリにプロジェクト用のディレクトリを作成 • 『cd sample-project』 ◦ 作成したディレクトリに移動 • 『git init』 ◦ https://git-scm.com/docs/git-init ◦ 空のGitリポジトリを作成
18. First Commit 18
19. First Commit 19 • 空のリポジトリを作成したあとに初めてのコミットのこと • 特別な意味を持ってコミットされることもあり、何をコミットするかは諸説ある 空コミットで始めるのは？ A： 最初のコミットを取り消せないなどの一部操作に制限があるため回避策として用いられやすい 取り消す可能性の低いREADME.mdや.gitignoreなどのファイル追加でコミットする方がベター 最終手段として空コミットを使用する気持ちで 『git commit --allow-empty』
20. .gitignoreテンプレートの活用 20 https://github.com/github/gitignore
21. VS Codeの拡張機能 ① 21
23. ブランチを作成 23
24. ブランチを作成 • ブランチを作成してそのブランチに対して変更を行う • 開発サイクルを回していく中でmainブランチに直接変更をPushすることはない ◦ 緊急や急ぎだからといって例外パターンは避ける ◦ GitHubやVS Codeの設定でmainに直接Pushすることを抑止することも可能 24
25. git checkout vs switch 新しく覚えるのであれば、git swtichコマンドで覚える • git checkoutは非常に大きな役割を持つ機能で課題を抱えていた • Git 2.23から実験的な機能として新たにgit switchとgit restoreが追加 ◦ ブランチを変更する操作とファイルを変更する操作という形で明確に分けられる • 『git switch <ブランチ名>』 ◦ 既存のブランチに切り替える • 『git switch --create <新しいブランチ名>』 ◦ 新しくブランチを作成する 25
28. ブランチ名は？ 28
29. ブランチ名は？ ブランチ名はどうしたらいいのか？ A： Git-FlowやGitHub-Flowなど広く知られたモデルの採用をまず検討する。独自化は今後のオンボーデ ィングや文化醸成などの仕組み作りやコストなども踏まえてメリットが大きければ。 大体のプロジェクトは、前任者が居なくなると謎なブランチングとして負債になりがち 29
33. git add / commit / push 33
35. git add • コミットしたいファイルをステージエリアに追加 • 『git add -A』 ◦ 全てのファイル※1 を追加 • 『git add .(ドット)』 ◦ 指定したディレクトリ配下の全てのファイル※1 を追加 git commit • オプションなしで省略して実行可能 • 『git commit -a』 ◦ 全てのファイル※1 を自動的にステージエリアに追加 git push ◦ ローカルで作成したコミットをリモートに反映 ※1 新規作成または変更・削除されたファイル git add / commit / push 35
37. コミット後に追加で直前のコミットに追加したい時は？ A： 『git commit --amend』を実行することでPush前の直前コミットに対して、 ・コミットメッセージの修正 ・コミット内容の追加 のみ可能 コミットの修正① 37
38. 直前のコミットを取り消してやり直したい場合は？ A： 『git reset --soft HEAD^』を実行して 直前のコミットをgit addしたあとの状態に戻す コミットの修正② 38
39. GitHubのリポジトリを作成 39
40. GitHubのリポジトリ作成 • アカウントが必要 • リポジトリの公開範囲に注意 40 https://github.com/new
41. • リモートリポジトリを作成したらローカルで追加が必要 • 『git remote add origin <追加したいリポジトリのURL>』 ◦ 意図して変更しない場合は、デフォルトで「origin」を指定 リモートリポジトリの追加 41
42. git add 〜 リポジトリ作成まで 42
43. 有効化したいおすすめの設定 43
44. マージ済みのブランチを削除 • 同じブランチを使いまわさずに1回の機能開発で使い捨てることが多い • マージ後に削除することが一般的でGitHubでも自動削除する機能がサポートされている ◦ 完全に削除されないため、後で復元可能 44
45. 脆弱性アラート • GitHubの標準機能としてDependabotアラートが提供されている • 推しツールがなければ、とりあえず有効化して関心を持つことから始める ◦ GitHub標準以外のツールやサービスもご紹介可能 45
46. ブランチプロテクション(有料プランのみ) 46 ←マージ時にプルリク必須 ↓マージ時にすべてのステータスチェックの成功必須
47. ② 既存の開発プロジェクトに 途中から参加 47
49. リポジトリをクローン 49
50. リポジトリをクローン • cd ~/Documents/dev ◦ 開発関連のファイルをまとめたいディレクトリに移動 • git clone <リポジトリのURL> ◦ 任意のディレクトリ上で実行するとリポジトリ名でディレクトリが作成される • cd <リポジトリ名> ◦ プロジェクトに移動 50
51. リポジトリをクローン(VS Code編) 51
52. HTTPSやSSHなどいくつか手段があるがどれを使えばいいのか？ A： 意思を持って使用することを除き、HTTPS方式で接続することをおすすめします。 ・所属組織などで通信環境の制限を受けにくい ・比較的セットアップが容易(gh auth loginの使用を前提) HTTPS vs SSH 52
53. プルリクエストとコードレビュー 53
54. プルリクエストの作成 • 開発者が実装したソースコードのレビューはプルリクエスト機能を使用 • 原則的にプルリクエストを作成しないマージはNG • タイトル欄： ◦ コミットした変更内容から簡潔に概要を書く • 説明欄： ◦ 変更した内容(特に前提や経緯など) ◦ バグや不具合などは再現方法や動かし方の手順 ◦ など 54
55. コードレビュー • ソースコードの行レベルでディスカッションや指摘、修正提案などが行える • 威圧的なコメントは控える • FYI、IMO、LGTMなどの略語もカジュアルに ◦ FYI：参考までに ◦ IMO：私の意見では ◦ LGTM：いいと思う 55
56. シングルラインとマルチラインでコメント コメントしたい行の左端の＋ボタンをクリック 56 コメントしたい行の左端の＋ボタンから開始か ら終了までをカーソルをドラッグ
57. 返信テンプレート 57
58. 変更を提案 58
59. おわり 59