Githubをはじめよう 初心者向け完全ガイド

Transcript

1. GitHub をはじめよう！ 〜登録から基本操作まで〜 初心者向け完全ガイド 1
2. はじめに このスライドでは、プログラミングの世界で広く使われている GitHub の基本的な使い方を、ゼロから丁寧に解説します。 ゴール: GitHub アカウントを作成できる 基本的なGit コマンドを理解し、使えるようになる リポジトリを作成し、コードを管理できるようになる GitHub を使った基本的な開発の流れを体験する 2
3. 目次 1. GitHub/Git とは？ ( なぜ使うの？) 2. アカウント作成 ( 最初のステップ) 3. 基本用語を知ろう ( 共通言語の理解) 4. Git の準備 ( ローカル環境の設定) 5. リポジトリ作成 ( プロジェクトの箱作り) 6. ローカルでの基本操作 ( コードの記録) 7. リモートとの連携 ( コードの共有・保存) 8. 変更と更新 ( 日々の開発サイクル) 9. ブランチ操作 ( 安全な開発のために) 3
4. 1. GitHub/Git とは？ 4
5. Git とは？ バージョン管理システム の一つ。 ファイルの 変更履歴 を記録・管理 するためのツール。 いつ、誰が、どこを、どのように変 更したかを追跡できる。 過去の状態に戻したり、変更点を比 較したりできる。 主に ローカル環境 ( 自分のPC) で動 作する。 5
6. GitHub とは？ Git を使った開発を支援する Web サービス。 Git リポジトリを オンライン上 で保存・共有できる場所。 複数人での共同開発（チーム開発）をスムーズにする機能が豊富。 コードレビュー（プルリクエスト） タスク管理（Issues, Projects ） Web サイト公開（GitHub Pages ） 世界中の開発者が利用するプラットフォーム。 6
7. なぜGitHub を使うの？ ( メリット) バージョン管理: コードの変更履歴を安全に管理。間違いがあって も元に戻せる！ コード共有: チームメンバーや世界中の開発者とコードを簡単に共 有。 バックアップ: オンライン上にコードが保存されるので、PC が壊れ ても安心。 チーム開発: 複数人での開発が効率的に。誰が何を変更したか一目 瞭然。 ポートフォリオ: 自分のスキルや成果物を公開し、アピールできる。 オープンソース: 世界中の公開プロジェクトに参加したり、学んだり 7
8. 2. アカウント作成 8
9. Step 1: 公式サイトへアクセス Web ブラウザで github.com と検索するか、直接URL を入力して GitHub 公式サイトにアクセスします。 9
10. Step 2: サインアップ開始 画面右上にある「Sign up 」ボタンをクリックします。 10
11. Step 3: アカウント情報入力 画面の指示に従って、必要な情報を入力します。 メールアドレス (Email address) パスワード (Password) ユーザー名 (Username): 他のユーザーと重複しない、あなた固有の 名前（後で変更可能） 11
12. Step 4: 認証と設定 メール認証: 登録したメールアドレスに確認メールが届きます。メー ル内のリンクをクリックして認証を完了します。 プラン選択: 基本的に「Free ( 無料) 」プランで十分です。 アンケート: 利用目的などの簡単なアンケートに答えます（スキッ プ可） 。 12
13. アカウント作成完了！ これでGitHub アカウントが作成され、ダッシュボード画面が表示され ます。 13
14. 3. 基本用語を知ろう 14
15. リポジトリ (Repository) プロジェクトに関するファイル（ソースコード、ドキュメント、画 像など）を保管する 場所 や フォルダ のこと。 プロジェクトの全ての変更履歴も含まれる。 ローカルリポジトリ: 自分のPC 上にあるリポジトリ。 リモートリポジトリ: GitHub 上にあるリポジトリ。 15
16. コミット (Commit) ファイルの変更内容を ローカルリポジトリに記録 する操作。 セーブポイントのようなもの。 「何を、なぜ変更したか」を示す コミットメッセージ と共に記録 する。 git commit -m "変更内容のメッセージ" のように使う。 16
17. プッシュ (Push) ローカルリポジトリで行ったコミット（変更履歴）を リモートリポ ジトリ (GitHub) にアップロード する操作。 これにより、他の人も変更内容を見たり、利用したりできるように なる。 git push のように使う。 17
18. プル (Pull) リモートリポジトリ (GitHub) の最新の変更内容 を ローカルリポジ トリに取り込む 操作。 他の人が行った変更を自分のPC に反映させるために使う。 git pull のように使う。 18
19. ブランチ (Branch) コミット履歴の流れを 分岐 させる機能。 メインの履歴（通常 main や master ）に影響を与えずに、新しい機 能の開発やバグ修正などを 並行して 行うことができる。 作業が終わったら、元のブランチに マージ (Merge) して統合する。 19
20. マージ (Merge) 分岐した ブランチ で行った変更内容を、別のブランチ ( 通常は main ブランチ) に 統合 する操作。 git merge のように使う。 20
21. プルリクエスト (Pull Request / PR) 自分がブランチで行った変更を、他の人（主にリポジトリ管理者） に レビューしてもらい、マージを依頼 するための機能。 GitHub 上で作成する。 チーム開発でコードの品質を保つために重要。 21
22. 4. Git の準備 22
23. Git のインストール GitHub を使う前に、自分のPC に Git をインストールする必要があり ます。 Windows: Git for Windows (git-scm.com) からダウンロードしてイ ンストーラーを実行。 Mac: Xcode Command Line Tools に含まれていることが多い。ターミ ナルで git --version を実行して確認。 Homebrew を使って brew install git でもインストール可能。 Linux (Debian/Ubuntu): sudo apt update && sudo apt install git Linux (Fedora): sudo dnf install git 23
24. Git の初期設定 ( 重要！) ターミナル（またはコマンドプロンプト、Git Bash ）を開き、以下の コマンドを実行して、ユーザー名 と メールアドレス を設定します。 これは、誰がコミットしたかを記録するために使われます。GitHub ア カウントと同じ情報 を設定するのが一般的です。 git config --global user.name "あなたのGitHubユーザー名" git config --global user.email "あなたのGitHubメールアドレス" 24
25. 設定の確認 設定が正しく行われたかを確認します。 git config --global user.name git config --global user.email 設定したユーザー名とメールアドレスが表示されればOK です。 25
26. 5. リポジトリ作成 26
27. Step 1: 新規リポジトリ作成画面へ GitHub にログインし、ダッシュボード画面右上の「＋」アイコンをク リックし、 「New repository 」を選択します。 27
28. Step 2: リポジトリ情報入力 Repository name: リポジトリの名前を入力（例: hello-world , my-first-project ） Description (optional): リポジトリの説明（任意） Public / Private: Public : 誰でも閲覧可能 ( オープンソースなど) Private : 自分と招待した人のみ閲覧可能 ( 個人プロジェクト、社 内プロジェクトなど) 今回は Public を選んでみましょう。 28
29. Step 3: 初期ファイルの設定 リポジトリ作成時に、いくつかの便利なファイルを自動生成できま す。 Add a README file: プロジェクトの説明を書くファイル。チェッ クを入れるのがおすすめ。 Add .gitignore: Git の管理対象外にするファイルやフォルダを指定 する設定ファイル。 ( 最初は不要でもOK) Choose a license: プロジェクトの利用条件を示すライセンスファイ ル。( 最初は不要でもOK) 今回は「Add a README file 」にチェックを入れましょう。 29
30. Step 4: 作成実行 入力と設定が終わったら、 「Create repository 」ボタンをクリックし ます。 30
31. リポジトリ作成完了！ 作成したリポジトリのページが表示されます。 README ファイルが作成されているのが確認できます。 31
32. 6. ローカルでの基本操作 32
33. Step 1: リモートリポジトリをローカルにコピー (Clone) まず、GitHub 上に作成したリモートリポジトリを、自分のPC （ロー カル環境）にコピーします。これを クローン (Clone) と言います。 1. GitHub のリポジトリページを開きます。 2. 緑色の「<> Code 」ボタンをクリックします。 3. 「HTTPS 」タブが選択されていることを確認し、表示されている URL をコピー します。 33
34. Step 1: クローン実行 ターミナルを開き、リポジトリを保存したいディレクトリに移動 ( cd コマンド) してから、以下のコマンドを実行します。 git clone 例: git clone https://github.com/your-username/hello-world.git 実行すると、カレントディレクトリにリポジトリ名のフォルダ（例: hello-world ）が作成され、リモートリポジトリの内容 （README.md など）がダウンロードされます。 34
35. Step 2: リポジトリフォルダへ移動 クローンして作成されたフォルダに移動します。 cd 例: cd hello-world これ以降のGit コマンドは、基本的にこのリポジトリフォルダ内で実行 します。 35
36. Step 3: ファイルを作成・編集 テキストエディタなどを使って、このフォルダ内に新しいファイルを 作成したり、既存のファイル（例: README.md ）を編集したりしてみ ましょう。 例: hello.txt という名前で新しいファイルを作成し、何かテキストを 書き込む。 # 例: hello.txt の内容 Hello, GitHub! 36
37. Step 4: 変更状況の確認 (status) どのようなファイルが変更されたか、Git の管理状況を確認します。 git status 新しいファイルを作成した場合、 「Untracked files 」 （追跡されていな いファイル）として表示されます。 既存ファイルを変更した場合、 「Changes not staged for commit 」 （コ ミット対象になっていない変更）として表示されます。 37
38. Step 5: 変更をステージング (add) コミットしたい変更内容を ステージングエリア と呼ばれる場所に追加 します。これにより、どの変更を次のコミットに含めるかを選択でき ます。 特定のファイルだけステージング: git add 例: git add hello.txt 例: git add README.md 変更された全てのファイルをステージング: 38
39. Step 6: 変更をコミット (commit) ステージングした変更内容を、意味のあるメッセージ と共にローカル リポジトリに記録します。 git commit -m "ここにコミットメッセージを書く" 良いコミットメッセージの例: "Add hello.txt" (hello.txt を追加) "Update README.md with project description" (README.md にプロ ジェクト説明を追記) "Fix typo in introduction" ( 導入部分のタイポを修正) 39
40. Step 7: コミット履歴の確認 (log) これまでのコミット履歴を確認できます。 git log 各コミットのID ( ハッシュ値) 、作成者、日時、コミットメッセージが 表示されます。 ( 終了する場合は q を押します) 40
41. 7. リモートとの連携 41
42. ローカルの変更をリモートへ (Push) ローカルリポジトリで行ったコミット（変更履歴）を、GitHub 上のリ モートリポジトリに反映させます。 git push origin main origin : リモートリポジトリのデフォルト名（クローン時に自動設 定される） main : プッシュ先のブランチ名（多くのリポジトリでデフォルトの ブランチ名。以前は master が主流でした） 42
43. GitHub 上で確認 git push が成功したら、ブラウザでGitHub のリポジトリページをリ ロードしてみましょう。 ローカルで行ったコミットが反映され、ファイルが追加・変更されて いるはずです。 43
44. もし main でエラーが出たら？ もし git push origin main でエラーが出る場合、デフォルトブランチ が master である可能性があります。その場合は以下を試してくださ い。 git push origin master 現在のブランチ名は git branch コマンドで確認できます（ * がつい ているものが現在のブランチ） 。 44
45. リモートでの変更をローカルへ (Pull) 他の人がリモートリポジトリを更新した場合や、自分がGitHub 上で直 接ファイルを編集した場合など、リモートリポジトリの最新の状態を ローカルリポジトリに取り込みます。 git pull origin main ( または git pull origin master ) これにより、ローカルのファイルがリモートの最新状態に更新されま す。 45
46. 連携の基本サイクル 開発を進める上での基本的な流れは以下のようになります。 1. git pull : 作業開始前に、リモートの最新の変更を取り込む。 2. ファイル編集: コードを書いたり、ファイルを修正したりする。 3. git add . : 変更したファイルをステージングする。 4. git commit -m "メッセージ" : 変更内容をローカルに記録する。 5. git push : ローカルの変更をリモートに反映させる。 このサイクルを繰り返して開発を進めます。 46
47. 8. 変更と更新 47
48. GitHub 上でファイルを編集してみる GitHub のリポジトリページでは、ブラウザ上で直接ファイルを編集す ることも可能です。 1. 編集したいファイル（例: README.md ）をクリック。 2. ファイルの右上に表示される鉛筆アイコン（Edit this file ）をクリッ ク。 3. エディタ画面で内容を編集。 4. 画面下部の「Commit changes 」セクションでコミットメッセージ を入力し、 「Commit changes 」ボタンをクリック。 48
49. リモートの変更をローカルに反映 (Pull) GitHub 上で編集（コミット）したので、リモートリポジトリがローカ ルリポジトリより新しくなりました。 この変更をローカルに取り込むために pull を実行します。 ターミナルでリポジトリフォルダに移動し、実行します。 git pull origin main ( または git pull origin master ) ローカルのファイル（例: README.md ）が更新されていることを確認し てください。 49
50. ローカルで編集 → Push 今度はローカルでファイルを編集し、その変更をリモートに反映させ てみましょう。 1. ローカルのファイル（例: hello.txt ）をテキストエディタで編集 し、保存。 2. ターミナルで変更をステージング: git add hello.txt ( または git add . ) 3. コミット: git commit -m "Update hello.txt" 4. リモートにプッシュ: git push origin main GitHub のリポジトリページをリロードし、 hello.txt が更新されてい 50
51. コンフリクト (Conflict) とは？ もし、同じファイルの同じ箇所 を、リモートとローカルで 別々に編集 してしまった場合、 git pull や git merge をしようとすると コンフ リクト（衝突） が発生します。 Git はどちらの変更を優先すべきか自動で判断できないため、手動で修 正する必要があります。 今回は深入りしませんが、 チーム開発ではよく起こりうることなの で、覚えておきましょう。 コンフリクトが発生したら、落ち着いてメッセージを読み、ファイル を修正して再度コミットします。 51
52. 9. ブランチ操作 52
53. なぜブランチを使うのか？ 安全な作業場所: メインのコード（ main ブランチ）を直接編集する のはリスクが伴います。ブランチを切れば、メインに影響を与えず に自由に試行錯誤できます。 並行開発: 新機能の開発、バグ修正、実験などを、それぞれ別のブ ランチで行い、同時進行できます。 整理: 作業内容ごとにブランチを分けることで、変更履歴が整理さ れ、管理しやすくなります。 main (or master ) ブランチは、常に 安定して動作する状態 を保つこと が理想です。 53
54. 現在のブランチを確認 git branch 現在存在するブランチの一覧が表示され、今いるブランチには * が付 きます。 最初は * main ( または * master ) のように表示されるはずです。 54
55. ブランチを作成 新しい作業用のブランチを作成します。ブランチ名は、作業内容がわ かる名前にするのが一般的です（例: feature/add-new-page , fix/login-bug ） 。 git branch 例: git branch develop これだけではブランチが作成されただけで、まだ移動はしていませ ん。 git branch で確認すると、新しいブランチ名が増えているはずで す。 55
56. ブランチを切り替え 作成したブランチに移動（チェックアウト）します。 git checkout または、新しいGit バージョンでは switch コマンドも使えます。 git switch 例: git checkout develop git branch で確認すると、 * が移動したブランチについているはず です。 56
57. 作成と切り替えを同時に ブランチの作成と、そのブランチへの切り替えを一度に行うコマンド もあります。 git checkout -b または git switch -c 例: git checkout -b feature/update-readme 57
58. ブランチでの作業 切り替えたブランチで、通常通りファイルの編集、 add 、 commit を行 います。 ここでの変更は、切り替え元のブランチ ( main など) には 影響しませ ん。 1. ファイルを編集 2. git add . 3. git commit -m "ブランチでの変更内容" 58
59. 新しいブランチをリモートにプッシュ ローカルで作成した新しいブランチでの変更を、リモートリポジトリ (GitHub) にも反映させます。初めてそのブランチをプッシュする場合 は、以下の -u オプションを付けて実行します。 git push -u origin 例: git push -u origin develop -u オプションは、ローカルブランチとリモートブランチを紐付け （upstream 設定） 、次回以降 git push だけでプッシュできるように します。 59
60. ブランチをマージ ( 統合)(1) ブランチでの作業が完了したら、その変更内容を main ブランチ（ま たは他の統合先ブランチ）に取り込みます。 1. 統合先のブランチに切り替え: git checkout main 2. 最新の状態にする ( 念のため): git pull origin main 60
61. ブランチをマージ ( 統合)(2) 3. ブランチをマージ: git merge 例: git merge develop これで、 develop ブランチでの変更が main ブランチに統合されまし た。 61
62. マージ後のプッシュ ローカルの main ブランチでマージが完了したので、その結果をリモ ートリポジトリに反映させます。 git push origin main 62
63. 不要になったブランチの削除(1) マージが完了し、不要になったブランチは削除できます。 ローカルブランチの削除: git branch -d 例: git branch -d develop ( -D オプションは大文字で、マージされていないブランチも強制削 除します) 63
64. 不要になったブランチの削除(2) リモートブランチの削除: git push origin --delete 例: git push origin --delete develop 64
65. 10. プルリクエスト 65
66. プルリクエスト (PR) とは？ ブランチで行った変更を main ブランチなどに マージしてもらうた めの依頼。 GitHub 上で作成・管理する。 コードレビュー の機会を提供し、変更内容について議論できる。 チーム開発において、コードの品質を保ち、安全にマージするため の重要なプロセス。 流れ: ブランチで作業 → プッシュ → GitHub でPR 作成 → レビュー → ( 修正) → マージ 66
67. プルリクエストの作成手順 (GitHub 上) 1. 作業ブランチ ( develop など) をGitHub にプッシュした後、リポジ トリページにアクセスすると、 「Compare & pull request 」ボタン が表示されることがあります。それをクリック。 2. 表示されない場合は、 「Pull requests 」タブを開き、 「New pull request 」ボタンをクリック。 67
68. プルリクエストの詳細設定 1. 比較ブランチの選択: base: マージ先のブランチ ( 通常 main or master ) compare: マージ元のブランチ ( 自分が作業したブランチ、例: develop ) 変更内容が表示されるので確認します。 2. タイトルと説明の入力: タイトル: 変更内容が簡潔にわかるタイトル ( 例: "Add user login feature") 説明: なぜこの変更を行ったのか、どのような変更か、レビュー してほしい点などを具体的に記述。 68
69. レビューとマージ プルリクエストが作成されると、レビュアー（指定された人やチー ムメンバー）がコードを確認し、コメントや修正依頼をすることが できます。 コメントや修正依頼があれば、ローカルで修正 → コミット → プッ シュ すると、自動的にプルリクエストに反映されます。 レビューで問題がなければ、リポジトリの管理権限を持つ人が 「Merge pull request 」ボタンをクリックしてマージを実行しま す。 マージ後、作業ブランチは不要なら削除できます (GitHub 上または ローカルで git branch -d ... ) 。 69
70. 11. プライベートリポジトリ 70
71. プライベートリポジトリとは？ リポジトリの内容が 非公開 に設定されたリポジトリ。 リポジトリ所有者 と、明示的に 招待されたコラボレーター（協力 者） のみがアクセス（閲覧、編集など）できます。 個人の未公開プロジェクト、社内プロジェクト、機密情報を含むコ ードなどの管理に適しています。 71
72. 作成方法 リポジトリを新規作成する際に、 「Visibility 」の選択肢で「Private 」 を選びます。 既存のリポジトリをプライベートに変更することも可能です（リポジ トリの Settings → Danger Zone → Change repository visibility ） 。 72
73. コラボレーターの招待 プライベートリポジトリに他のユーザーを招待して、共同で作業する ことができます。 1. プライベートリポジトリのページを開き、 「Settings 」タブをクリッ ク。 2. 左側のメニューから「Collaborators and teams 」または「Manage access 」を選択。 3. 「Invite a collaborator 」ボタンをクリック。 4. 招待したいユーザーの GitHub ユーザー名、氏名、またはメールア ドレス を入力して検索し、選択して招待します。 5. 招待されたユーザーが承認すると、アクセス可能になる。 73
74. 注意点 無料プランでもプライベートリポジトリの作成数に制限はありませ んが、一部の高度な機能（コードセキュリティ機能など）は有料プ ランが必要な場合があります。 プライベートリポジトリでも、誤って機密情報（パスワード、API キーなど）をコミットしないように注意が必要です。 .gitignore を 活用しましょう。 アクセス権限は適切に管理し、不要になったコラボレーターは削除 しましょう。 74
75. 12. まとめと次のステップ 75
76. 今日学んだこと Git とGitHub の基本的な概念と役割 GitHub アカウントの作成方法 Git のインストールと初期設定 リポジトリの作成（Public/Private ）とクローン 基本的なGit コマンド ( status , add , commit , log , push , pull ) ブランチの作成、切り替え、マージ ( branch , checkout / switch , merge ) プルリクエストの基本的な流れ プライベートリポジトリの概要 76
77. 次のステップ GitHub の世界は奥が深いです！今日学んだことを基礎に、さらに以下 の内容を学んでみましょう。 コンフリクトの解決: チーム開発では必須のスキル。 GitHub Flow / Git Flow: より体系的なブランチ戦略。 Issue: タスク管理、バグ報告、機能要望など。 GitHub Actions: CI/CD （ビルド、テスト、デプロイの自動化） 。 GitHub Pages: リポジトリから簡単にWeb サイトを公開。 README の書き方: プロジェクトを魅力的に紹介。 OSS への貢献: 公開されているプロジェクトに参加してみる。 77
78. 学習リソース GitHub 公式ドキュメント (docs.github.com): 最も正確で詳細な情 報源。 Pro Git (git-scm.com/book/ja/v2): Git の定番書籍（無料公開） 。 さまざまなオンラインチュートリアルやブログ記事: 「GitHub 使い 方」 「Git 入門」などで検索。 実際に使ってみること！: 小さなプロジェクトでも良いので、自分 でリポジトリを作って、日々の作業でGit/GitHub を使ってみるのが 一番の近道です。 78
79. ご清聴ありがとうございました！ 79