【地域おこし勉強会 第２回】Git勉強会【2023/10/18】

Transcript

1. Git勉強会 波紫寛斗（はし）
2. 目次 1. 本勉強会の目的 2. 諸注意 3. 入門編（リポジトリ～プッシュ） 4. 発展編（ブランチ～プルリクエスト） 5. 参考文献
3. 本勉強会の目的 • 以下のようなGitの基本用語を学ぶ ◦ リポジトリ ◦ コミット ◦ プッシュ ◦ プル ◦ ブランチ etc … • Git-Flowを学ぶ • VSCodeを用いてGitの基本操作が行える
4. 諸注意 • 開発環境はVSCodeを使う • GitHubでは2要素認証が推奨されているため、後日設定必須 • 本勉強会ではCloneの際にHTTPS通信を用いるが、SSH接続のほうがセキュリティ 上は良いため、実際の開発の際はSSHを用いる • GitHubのアップデートの際にUIが変わる可能性があるため、演習のスライドは操作 が若干変わる可能性がある
5. １．入門編（リポジトリ～プッシュ）
6. Gitとは • プログラムのバージョン管理ツール ◦ ファイルの「第〇版」とか、ソフトの「 Ver.◦◦」みたいなものをラクに管 理 できるツール • 制作者はLinuxカーネルの生みの親の リーナス・トーバルズさん • Gitで管理しているプログラムを公開するサイトがGitHubや GitLab
7. なぜGitが必要なのか？ • ファイルで管理していると以下のことが起こる ◦ 無秩序に名前を付けてしまった場合、どのファイルが最新のものか区別できない ◦ チームで共有している場合、作業内容を一目で把握できない ◦ 二人同時に同じ名前でファイルをアップロードした場合、先にアップロードした人の変更が消える 引用：サル先生のGit入門（https://backlog.com/ja/git-tutorial/intro/01/）
8. 履歴を管理するリポジトリ（Repository） • リポジトリ（Repository）：状態を保存しておくための場所 • リポジトリは以下の２種類にわけられる ◦ ローカルリポジトリ：ユーザ一人ひとりが利用するために、自分の手元のマシン上に配置 するリポジトリ ◦ リモートリポジトリ：専用のサーバに配置して複数人で共有するためのリポジトリ • そのため、GitHub上で作成するのはリモートリポジトリ 引用：サル先生のGit入門（https://backlog.com/ja/git-tutorial/intro/02/）
9. ワークツリーとインデックス • ワークツリー：作業者が作業しているディレクトリ • インデックス：コミットするファイルを一時的に保持しておくための場所
10. 変更を記録するコミット（Commit） • コミット（Commit）：ファイルの追加・変更をリポジトリに記録すること • コミットを実行すると、直前のコミットからの差分（diff）が作成される • コミットは下図のように時系列でリポジトリ上に管理されている • コミットを遡ることで、過去の変更履歴やその内容の把握が可能
11. 【コラム】分かりやすいコミットメッセージ • コミットをする際には、その変更内容を「コミットメッセージ」に記す必要がある • コミットメッセージはプロジェクトによって書き方が異なる • 以下のような書き方が存在する 1行目：[add]: hoge.pyを追加 1行目：変更内容の要約 2行目：空行 3行目：変更した理由
12. 【コラム】過去のコミットを書き換える • revert：過去のコミット打ち消す • reset：過去のコミットを捨てる • cherry-pick：過去のコミットから抜き取る • rebase -i：コミット履歴を書き換える
13. リモートリポジトリにプッシュ（Push）する • プッシュ（Push）：リモートリポジトリに変更履歴をアップロードする • Pushを実行すると、リモートリポジトリに自分の変更履歴がアップロードされて、リ モートリポジトリ内の変更履歴がローカルリポジトリと同じになる
14. リモートリポジトリをクローン（Clone）する • クローン（Clone）：リモートリポジトリを丸々ダウンロードして、ローカルリポジトリとし て利用すること • Zip形式でダウンロードする場合と違う点： ◦ コミット履歴が保持されている ◦ プル（後述）が可能 ◦ ブランチ（後述）もダウンロードできる
15. リモートリポジトリからプル（Pull）する • プル（Pull）：リモートリポジトリからローカルリポジトリを更新すること • プルを行うことで、リモートリポジトリから最新の変更履歴をダウンロードしてきて、 自分のローカルリポジトリにその内容を取り込む
16. 演習
17. GitHubのアカウントを作成する 以下のサイトの手順に従ってGitHubのアカウントを作成する https://reffect.co.jp/html/create_github_account_first_time/
18. VSCodeのインストール 以下のサイトを参考にして、Stable版のインストールを行う https://www.javadrive.jp/vscode/install/index1.html#section1 【注意】VisualStudioとVisualStudioCode（VSCode）はアイコンが似ているから注意！
19. ディレクトリの作成をして、VSCodeで開く • 今回はデスクトップ上に「Benkyoukai」という名前 のディレクトリを作成 • ディレクトリ名は以下のルールに基づいて作成す る ◦ 日本語を含まない ◦ スペースを使用しない ◦ 全角文字を使用しない • 作成後、右クリックを押してCodeで開くをクリック
20. リポジトリの初期化 左サイドバーの上から２番目のアイコンをクリックし、 「リポジトリを初期化する」をクリックする
21. ファイルを追加する • 一番上のアイコンをクリックし、左側のス ペースで右クリックを押し、ファイルを追加 する • 今回追加するファイルは「README.md」 （Markdown記法で書かれたREADMEファ イル）
22. ファイルをインデックスに追加し、コミット • ２番目のタブに移動し、対象ファイルにカーソルを合わせて「＋」ボタンを押すことで ファイルをインデックスに追加できる • 追加後、上の入力欄にコミットメッセージを入力し、「コミット」ボタンを押すことでコ ミットできる
23. GitHubにリモートリポジトリを作成する • 「Repositories」タブの「New」ボタンをクリックする • 以下の項目を入力する ◦ Owner：リポジトリのオーナー（普通は変更不要） ◦ Repository Name：リポジトリ名（今回は Benkyoukaiがいいかも） ◦ Description：リポジトリの説明（記入は任意） ◦ Public/Private：リポジトリを他のユーザーに公開するか否か
24. リモートリポジトリのURLをコピーする 作成後、画像の赤線の位置にあるURLをコピーする
25. リモートリポジトリの設定をする • 再度VSCodeを開き、２番目のアイコンをクリックする • 「・・・」ボタンをクリックし、リモート→リモートの追加をクリックする • 先ほどコピーしたURLを貼り付けてEnter • その後、リモート名を「origin」と入力してEnter
26. プッシュする • 「ブランチの発行」ボタンをクリックすることでプッシュできる • プッシュが完了したらGitHubの画面は以下の画像のようになっているはず
27. ２．発展編（ブランチ～プルリクエスト）
28. ブランチ（Branch） • ブランチ（Branch）：コミット履歴の流れを分岐して記録していくためのもの • 分岐したブランチは他のブランチの変更の影響を受けない ◦ →同じリポジトリ内で並行作業が可能 • 各ブランチで変更後、それらをマージ（merge: 統合）すれば一つにまとまる
29. ブランチの運用とGit-Flow • ブランチを適切に分けるには、運用ルールを決 める必要がある ◦ ルールなしにブランチを分けると、どの変更がどのブラ ンチか分からなくなりカオス • Git-Flow：Gitにおけるブランチ分岐モデル ◦ master: プロダクトとしてリリースする用のブランチ。リリースした らタグ（後述）を付ける
 ◦ hotfix: リリース後の緊急対応（クリティカルなバグフィックスなど） 用。 ◦ release: プロダクトリリースの準備用ブランチ ◦ develop: 開発用ブランチ ◦ feature: 機能の追加用。developから分岐し、developにマージす る https://cloudsmith.co.jp/blog/efficient/2020/0 8/1534208.html
30. ブランチの切り替え • チェックアウト（Checkout）：ブランチを切り替えること • チェックアウトを行うと、まず移動先のブランチ内の最後のコミットの内容がワークツ リーに展開 • HEAD：現在使用しているブランチの先頭を表す名前 • チェックアウトする→HEADが切り替わる
31. ブランチの統合（mergeとrebase） • マージ（merge）：二つのブランチを統合し、統合コミットを追加する merge • リベース（rebase）：統合先ブランチの次に、統合元ブランチの変更履歴を加える rebase
32. 【コラム】mergeとrebaseの使い分け マージ（merge）とリベース（rebase）はどちらもブランチを統合するが、性質が異なる • マージ ◦ 変更内容の履歴はそのまま残るが、履歴が複雑になる • リベース ◦ 履歴は単純になるが、元のコミットから変更内容が変更される。そのため、元のコミットを動かない 状態にしてしまうことがある。 例えば、featureブランチにdevelopブランチの内容を取り込む時は、developブランチの 環境で新機能を動作させたいため、その場合はあえてrebaseを使う
33. マージでの競合とその解消 • ブランチAとブランチBで作業を行い、それらを一つのブランチにマージする場合、 同じファイルを変更していたらどちらのブランチの変更を取り込めば良いか問題に なる • 競合（Conflict）：ブランチを統合する際に起こる変更箇所の重複 • 競合の解消方法： ◦ どちらか一方の変更履歴をすべて取り込み、もう一方は消去する ◦ ２つの変更履歴をミックスさせて取り込む
34. タグ • タグ（Tag）：特定のコミットを参照しやすくするために名前を付けること。よくバージョ ン名を付けるのに使われる。 • タグの種類 ◦ 軽量タグ：名前をつけるだけ ◦ 注釈付きタグ：名前＆コメント＆著名をつけられる
35. プルリクエスト • プルリクエスト（PR: Pull Request）：ブランチをマージする前に、変更内容を他の開 発者に通知する機能（マージの前段階） • プルリクエストを行うことで、他の開発者がレビューしてくれるので品質を担保でき る • プルリクエストはGitの機能ではなく、GitHub独自の機能 プルリクエストを使わない開発プロセス プルリクエストを使う開発プロセス
36. イシュー • イシュー（Issue）：そのプロジェクト内のタスク（やること）を管理する機能 • プルリクエストと併せて利用することが多い ◦ Issueを確認→開発→プルリクエストを提出 →レビュー→マージ • IssueはGitの機能ではなく、GitHub独自の機能
37. 演習
38. ブランチを作成する • 左下の「main」と書かれている箇所をクリックする • 上部に出現する入力欄に「develop」と入力し、Enterを押すことで、mainブランチか らdevelopブランチを作成できる
39. ブランチで作業をしてコミット • 左下が「develop」の場合に新たにコミットをすると、developブランチ上にコミットし たことになる • README.mdを編集して、コミットしてみよう
40. 作業内容をプッシュする • 「Branchの発行」を押すと、ブランチをリモートリポジトリ上に作成し、今までのコミッ ト履歴をプッシュすることができる
41. プルリクエストを発行するー① • mainブランチ以外に更新があった場合、画像のような表示が出ているはず • 「Compare & Pull Request」をクリックするとプルリクエストを作成画面に遷移する
42. プルリクエストを発行するー② ←Pull Requestのマージ先の設定 ←レビュー依頼する人 ←作業者 ←ラベル ←プロジェクト ←関連するマイルストー ン 詳細な内容→ タイトル→
43. 参考サイト • https://backlog.com/ja/git-tutorial/ • https://qiita.com/fruscianteee/items/6ab6d4381a88269ce336