Upgrade to Pro — share decks privately, control downloads, hide ads and more …

これから始めたい人集合!ゼロから学ぶGit/GitHub入門

 これから始めたい人集合!ゼロから学ぶGit/GitHub入門

就職や転職、新規プロジェクトへ参加など様々な変化が多いそんな季節になりました。期待と不安が入り混じる中、GitやGitHubを使うことになったけど、右も左も分からなくて困っている。また、スキルアップに向けてこれからGitを勉強していきたいけど、どこから手をつけていけばいいか分からない。そんな方に向けて、基本操作から実践的な内容まで幅広く網羅したGit/GitHub入門をお送りします。

とことんDevOps

April 28, 2023
Tweet

More Decks by とことんDevOps

Other Decks in Technology

Transcript

  1. これから始めたい人集合!
    ゼロから学ぶGit/GitHub入門
    日本仮想化技術株式会社
    VirtualTech.jp
    2023/04/27
    1

    View full-size slide

  2. 2
    自己紹介

    View full-size slide

  3. Gitとは?
    3

    View full-size slide

  4. Gitとは
    ● ソースコードなどの変更履歴を記録・追跡するためのバージョン管理システムの1つ
    ○ Subversion(SVN)のアーキテクチャを集中型と表現とし、Gitは分散型と言われている
    ● Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発
    ○ 現在のメンテナは濱野純という方で、2005年7月から担当
    ● ローカルリポジトリとインデックスと呼ばれる領域の考え方があるのが特徴の1つ
    4

    View full-size slide

  5. GitHubとは?
    5

    View full-size slide

  6. GitHubとは
    ● Gitの仕組みを使用してリモートリポジトリの機能を提供するサービスの1つ
    ○ 類似サービス:GitLabやBitBucket、CodeCommit(AWS)など
    ● 複数のメンバーと開発を行う時はリモートリポジトリが必要
    ● 最近の主なニュース:
    ○ 2023/01に1億人ユーザー突破
    ○ Subversionのサポートを2024/01で完全に終了すると発表
    6

    View full-size slide

  7. Visual Studio Codeとは?
    7

    View full-size slide

  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

    View full-size slide

  9. ツールはCLI派?GUI派?
    9

    View full-size slide

  10. GUIツールとCLIツールはどちらを使うべき?
    GitやGitHubの作法に慣れるまではGUIツールを使うことをおすすめ
    慣れてくるとより高度な操作や効率化などがやりたくなってきてからCLIのマスターも目指す
    10

    View full-size slide

  11. ① 0から新しく開発プロジェクトを開始
    (ローカル→リモート)
    ② 既存の開発プロジェクトに途中から参加
    (リモート→ローカル)
    まず覚えたい2つの流れ
    11

    View full-size slide

  12. ① 0から新しく開発プロジェクトを開始
    13

    View full-size slide

  13. プロジェクトの作成
    15

    View full-size slide

  14. プロジェクトの作成
    17
    ● 『mkdir sample-project』
    ○ 任意のディレクトリにプロジェクト用のディレクトリを作成
    ● 『cd sample-project』
    ○ 作成したディレクトリに移動
    ● 『git init』
    ○ https://git-scm.com/docs/git-init
    ○ 空のGitリポジトリを作成

    View full-size slide

  15. First Commit
    18

    View full-size slide

  16. First Commit
    19
    ● 空のリポジトリを作成したあとに初めてのコミットのこと
    ● 特別な意味を持ってコミットされることもあり、何をコミットするかは諸説ある
    空コミットで始めるのは?
    A:
    最初のコミットを取り消せないなどの一部操作に制限があるため回避策として用いられやすい
    取り消す可能性の低いREADME.mdや.gitignoreなどのファイル追加でコミットする方がベター
    最終手段として空コミットを使用する気持ちで
    『git commit --allow-empty』

    View full-size slide

  17. .gitignoreテンプレートの活用
    20
    https://github.com/github/gitignore

    View full-size slide

  18. VS Codeの拡張機能 ①
    21

    View full-size slide

  19. ブランチを作成
    23

    View full-size slide

  20. ブランチを作成
    ● ブランチを作成してそのブランチに対して変更を行う
    ● 開発サイクルを回していく中でmainブランチに直接変更をPushすることはない
    ○ 緊急や急ぎだからといって例外パターンは避ける
    ○ GitHubやVS Codeの設定でmainに直接Pushすることを抑止することも可能
    24

    View full-size slide

  21. git checkout vs switch
    新しく覚えるのであれば、git swtichコマンドで覚える
    ● git checkoutは非常に大きな役割を持つ機能で課題を抱えていた
    ● Git 2.23から実験的な機能として新たにgit switchとgit restoreが追加
    ○ ブランチを変更する操作とファイルを変更する操作という形で明確に分けられる
    ● 『git switch <ブランチ名>』
    ○ 既存のブランチに切り替える
    ● 『git switch --create <新しいブランチ名>』
    ○ 新しくブランチを作成する
    25

    View full-size slide

  22. ブランチ名は?
    28

    View full-size slide

  23. ブランチ名は?
    ブランチ名はどうしたらいいのか?
    A:
    Git-FlowやGitHub-Flowなど広く知られたモデルの採用をまず検討する。独自化は今後のオンボーデ
    ィングや文化醸成などの仕組み作りやコストなども踏まえてメリットが大きければ。
    大体のプロジェクトは、前任者が居なくなると謎なブランチングとして負債になりがち
    29

    View full-size slide

  24. git add / commit / push
    33

    View full-size slide

  25. git add
    ● コミットしたいファイルをステージエリアに追加
    ● 『git add -A』
    ○ 全てのファイル※1
    を追加
    ● 『git add .(ドット)』
    ○ 指定したディレクトリ配下の全てのファイル※1
    を追加
    git commit
    ● オプションなしで省略して実行可能
    ● 『git commit -a』
    ○ 全てのファイル※1
    を自動的にステージエリアに追加
    git push
    ○ ローカルで作成したコミットをリモートに反映
    ※1 新規作成または変更・削除されたファイル
    git add / commit / push
    35

    View full-size slide

  26. コミット後に追加で直前のコミットに追加したい時は?
    A:
    『git commit --amend』を実行することでPush前の直前コミットに対して、
    ・コミットメッセージの修正
    ・コミット内容の追加
    のみ可能
    コミットの修正①
    37

    View full-size slide

  27. 直前のコミットを取り消してやり直したい場合は?
    A:
    『git reset --soft HEAD^』を実行して
    直前のコミットをgit addしたあとの状態に戻す
    コミットの修正②
    38

    View full-size slide

  28. GitHubのリポジトリを作成
    39

    View full-size slide

  29. GitHubのリポジトリ作成
    ● アカウントが必要
    ● リポジトリの公開範囲に注意
    40
    https://github.com/new

    View full-size slide

  30. ● リモートリポジトリを作成したらローカルで追加が必要
    ● 『git remote add origin <追加したいリポジトリのURL>』
    ○ 意図して変更しない場合は、デフォルトで「origin」を指定
    リモートリポジトリの追加
    41

    View full-size slide

  31. git add 〜 リポジトリ作成まで
    42

    View full-size slide

  32. 有効化したいおすすめの設定
    43

    View full-size slide

  33. マージ済みのブランチを削除
    ● 同じブランチを使いまわさずに1回の機能開発で使い捨てることが多い
    ● マージ後に削除することが一般的でGitHubでも自動削除する機能がサポートされている
    ○ 完全に削除されないため、後で復元可能
    44

    View full-size slide

  34. 脆弱性アラート
    ● GitHubの標準機能としてDependabotアラートが提供されている
    ● 推しツールがなければ、とりあえず有効化して関心を持つことから始める
    ○ GitHub標準以外のツールやサービスもご紹介可能
    45

    View full-size slide

  35. ブランチプロテクション(有料プランのみ)
    46
    ←マージ時にプルリク必須
    ↓マージ時にすべてのステータスチェックの成功必須

    View full-size slide

  36. ② 既存の開発プロジェクトに
    途中から参加
    47

    View full-size slide

  37. リポジトリをクローン
    49

    View full-size slide

  38. リポジトリをクローン
    ● cd ~/Documents/dev
    ○ 開発関連のファイルをまとめたいディレクトリに移動
    ● git clone <リポジトリのURL>
    ○ 任意のディレクトリ上で実行するとリポジトリ名でディレクトリが作成される
    ● cd <リポジトリ名>
    ○ プロジェクトに移動
    50

    View full-size slide

  39. リポジトリをクローン(VS Code編)
    51

    View full-size slide

  40. HTTPSやSSHなどいくつか手段があるがどれを使えばいいのか?
    A:
    意思を持って使用することを除き、HTTPS方式で接続することをおすすめします。
    ・所属組織などで通信環境の制限を受けにくい
    ・比較的セットアップが容易(gh auth loginの使用を前提)
    HTTPS vs SSH
    52

    View full-size slide

  41. プルリクエストとコードレビュー
    53

    View full-size slide

  42. プルリクエストの作成
    ● 開発者が実装したソースコードのレビューはプルリクエスト機能を使用
    ● 原則的にプルリクエストを作成しないマージはNG
    ● タイトル欄:
    ○ コミットした変更内容から簡潔に概要を書く
    ● 説明欄:
    ○ 変更した内容(特に前提や経緯など)
    ○ バグや不具合などは再現方法や動かし方の手順
    ○ など
    54

    View full-size slide

  43. コードレビュー
    ● ソースコードの行レベルでディスカッションや指摘、修正提案などが行える
    ● 威圧的なコメントは控える
    ● FYI、IMO、LGTMなどの略語もカジュアルに
    ○ FYI:参考までに
    ○ IMO:私の意見では
    ○ LGTM:いいと思う
    55

    View full-size slide

  44. シングルラインとマルチラインでコメント
    コメントしたい行の左端の+ボタンをクリック
    56
    コメントしたい行の左端の+ボタンから開始か
    ら終了までをカーソルをドラッグ

    View full-size slide

  45. 返信テンプレート
    57

    View full-size slide

  46. 変更を提案
    58

    View full-size slide