Git・Githubまとめ
このページの最後に本課題の開発でのGitの使用例を載せているので、そちらもご覧ください。
Gitは、ソフトウェアのバージョン管理を行うためのツールです。バージョン管理とは、ファイルやコードの変更履歴を追跡し、管理する仕組みのことです。Gitを使うことで、プログラミングやプロジェクト管理がより効率的に行えます。
- 変更履歴の管理：ファイルの変更を自動で記録し、誰がどのような変更を行ったのかを追跡できます。
- 分散型システム：各開発者のPCにリポジトリが存在し、インターネット接続なしでも作業が可能です。
- ブランチ機能：異なる作業を並行して行うことができ、変更を安全に統合できます。
- 安全性と効率性：過去の状態に簡単に戻れるため、安心して作業が進められます。
GitHubは、Gitを使用したリポジトリ（コードや変更履歴のデータが保存される場所）をホストするウェブサービスです。GitHubを使うことで、リモートリポジトリ（オンライン上のリポジトリ）を管理したり、チームでの共同作業をよりスムーズに行うことができます。
- リモートリポジトリ：GitHubにコードをアップロードすることで、インターネットを介してどこからでもアクセスできるようになります。
- コラボレーション機能：プルリクエストやイシュー（問題・要望の管理）など、チームメンバーとのコラボレーションを簡単に行える機能があります。
- オープンソースプロジェクト：多くのオープンソースプロジェクトがGitHub上で管理されており、誰でもアクセスし、貢献することができます。
- コミュニティと学習：GitHubには大規模な開発者コミュニティがあり、多くのリソースやチュートリアルが利用できます。
| 特徴 | Git | GitHub |
|---|---|---|
| 定義 | バージョン管理ツール | Gitをホストするウェブサービス |
| 目的 | コードの変更履歴を管理 | リモートリポジトリの管理と共有 |
| 使用方法 | コマンドラインで操作 | ウェブインターフェースやAPIを使用 |
| コラボレーション | ローカル環境で行う | チームでの共同作業が容易 |
Gitは、ソフトウェアのバージョン管理を行うためのツールです。これを使うことで、コードの変更履歴を管理したり、複数人での共同作業がスムーズになります。以下は、WindowsとMacでのGitのインストール手順です。
Windowsでは、Gitがデフォルトでインストールされていないことが一般的です。以下の手順に従って、Gitをインストールしましょう。
-
インストーラのダウンロード
- Git公式サイトにアクセスし、Windows用のインストーラをダウンロードします。
-
インストーラを実行
- ダウンロードしたインストーラ（
*.exeファイル）をダブルクリックして実行します。
- ダウンロードしたインストーラ（
-
インストールウィザードに従う
- 画面の指示に従って、インストールを進めます。特に変更がなければ、デフォルト設定のままで問題ありません。
- 途中で「Adjusting your PATH environment」などの選択肢が出てくるので、推奨されている選択肢を選んで進めましょう。
-
インストールの完了
-
インストールが完了したら、コマンドプロンプトを開き、以下のコマンドを実行してGitが正しくインストールされたか確認します。
git --version
-
Gitのバージョン情報が表示されれば、インストール成功です。
-
Macでは、Gitがすでにインストールされていることもありますが、もし入っていない場合は、Homebrewを使って簡単にインストールできます。Homebrewは、Mac向けのパッケージ管理ツールで、ソフトウェアを簡単にインストールできます。
-
Homebrewがインストールされているか確認
-
端末（Terminal）を開き、以下のコマンドを入力します。
brew --version
-
Homebrewのバージョンが表示されれば、すでにインストールされています。
-
-
Homebrewがインストールされていない場合
-
Homebrewがインストールされていない場合、以下のコマンドを端末で実行してインストールします。
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
-
-
Gitをインストール
-
Homebrewがインストールされたら、以下のコマンドでGitをインストールします。
brew install git
-
-
インストールの確認
-
Gitが正しくインストールされたか確認するために、以下のコマンドを実行します。
git --version
-
Gitのバージョン情報が表示されれば、インストール成功です。
-
GitHubのイシュー（Issue）は、プロジェクトに関連するタスクやバグ、機能要求などを追跡・管理するための機能です。開発プロジェクトでは、多くの人が協力して作業を進めるため、問題点や改善すべき点が発生します。これらを効率的に管理し、プロジェクトチーム内で共有するためにイシューが使われます。
イシューを使用することで、以下のようなメリットがあります：
-
バグ報告: ソフトウェアを開発していると、動作しない部分や予期しない挙動をする部分が見つかります。これらの問題点をイシューとして登録することで、誰が、いつ、どのようなバグを見つけたかが記録され、修正作業がスムーズに進みます。
-
機能要求: 新しい機能の提案や、既存の機能の改善提案もイシューとして登録できます。これにより、チーム内でのアイデアの共有や議論が促進されます。
-
タスク管理: プロジェクトには多くのタスクが存在します。これらをイシューとして登録することで、誰が何を担当しているのか、どのタスクが優先されるべきかなどを明確に管理できます。
-
進捗管理: イシューにはステータス（例：オープン、クローズ）やラベル（例：バグ、機能要求）を付けることができます。これにより、プロジェクトの進捗状況を一目で確認できます。
GitHubのプロジェクトページにある「Issues」タブから新しいイシューを作成できます。
すると、以下のような画面になります。
- Title（タイトル）: イシューの内容を簡潔に表すタイトルを入力します。
- Comment（コメント／説明文）: イシューの詳細な説明を記載します。できるだけ具体的に書くことが重要です。
- Assignees（担当者）: このイシューを誰が担当するかを指定します。自分で対応する場合は自分のアカウントを、他の人に依頼する場合はその人のアカウントを選択します。
- Labels（ラベル）: イシューの種類（バグ、機能要求など）や優先度を示すラベルを付けます。
- Projects（プロジェクト）: このイシューを関連付けるプロジェクトを選択します（使用する場合）。
- Milestone（マイルストーン）: このイシューが属する具体的なリリースや期限を示すマイルストーンを指定します（使用する場合）。
- わかりやすいタイトルをつける: イシューの内容が一目でわかるようなタイトルを心がけましょう。タイトルだけで大まかな内容が把握できると、後から検索しやすくなります。
- 説明文を丁寧に書く: 課題の背景、問題点、再現手順、期待する結果などを詳細に記載してください。具体的な情報があると、他の人が問題を理解しやすく、適切な対応がしやすくなります。
- 適切な担当者とラベルを設定する: イシューに関連する人を担当者として指定し、内容を示すラベルを付けることで、イシューが適切な人に届き、優先度や種類が一目でわかるようにしましょう。
- 他のイシューやプルリクエストとのリンクを活用する: 関連するイシューやプルリクエストがある場合は、その番号を記載してリンクしましょう。これにより、関連する作業や議論を追跡しやすくなります。
イシューの作成は、ただのタスク報告やバグ報告以上の意味を持ちます。プロジェクトの進行において、コミュニケーションのツールとして非常に重要な役割を果たします。そのため、イシューを作成する際には、他の開発者やチームメンバーがスムーズに作業できるように、丁寧かつ詳細に情報を提供することが大切です。
コードを書き終わってPR（プルリクエスト）を出したら、イシューと紐づけるようにしましょう。
PR画面の右側の、「Development」からイシューを選択・紐付けができます。
ブランチ(Branch)とは、Git の重要な概念の一つで、ソースコードの独立した作業スペースのことを指します。メインの開発ラインから分岐した別の並行ラインを作成することで、新機能の開発やバグ修正などの作業を行うことができます。
ブランチを使うメリットは、以下のようなものがあります。
- 並行作業が可能: メインの開発ラインに影響を与えずに、別のブランチで作業できるため、複数人で並行して開発を進められます。
- 実験が安全にできる: 新しい機能を試す際に、メインのコードを変更する必要がなく、ブランチ上で実験的な変更を加えることができます。うまくいかない場合は、そのブランチを削除するだけで済みます。
- 分離された履歴管理: ブランチごとにコード変更の履歴が残るため、それぞれの変更内容を追跡しやすくなります。
- アトミックな統合: 機能が完成した段階で、メインのブランチにマージ(統合)することができます。これにより、ステップバイステップでメインのコードを更新できます。
新しいブランチを作成して切り替える手順は以下の通りです。
- 作業ディレクトリで 「git branch」を実行すると、現在のブランチ一覧が表示されます。
- 「git branch 新しいブランチ名」を実行すると、新しいブランチが作成されます。
- 「git switch 新しいブランチ名」または「git checkout 新しいブランチ名」で、新しいブランチに切り替えることができます。
上記の2、3の手順を一度に行うこともでき、「git switch -c 新しいブランチ名」または「git checkout -b 新しいブランチ名」と実行します。近年では、checkoutよりもswitchを使うことが推奨されています。
ブランチ上の作業が完了したら、メインのブランチ(通常は main や master)に統合(マージ)する必要があります。
-
git checkout mainでメインブランチに切り替えます。 -
git merge 作業ブランチ名を実行すると、作業ブランチの変更がメインブランチにマージされます。
マージ時に競合(コンフリクト)が発生した場合は、手作業でコンフリクトを解決する必要があります。
プロジェクトによっては、ブランチの運用ルールを決めておくことがよくあります。例えば、以下のようなルールが一般的です。
-
メインブランチの保護: メインの開発ブランチ（通常は
mainやmaster）には、直接のコミットを禁止し、必ずプルリクエスト（PR）を介してマージを行うルールを設けることが多いです。これにより、コードレビューを実施し、品質を保つことができます。 -
機能ブランチの命名規則: 機能やバグ修正ごとに新しいブランチを作成する際、一定の命名規則を設けることで、何のためのブランチであるかを明確にします。例えば、
feature/新機能名やbugfix/バグ内容といった形式がよく用いられます。 -
定期的なマージ: 定期的にメインブランチの変更を各機能ブランチに取り込むことで、コンフリクトを早期に解消することが推奨されます。これにより、最終的なマージ時に発生するコンフリクトを減らすことができます。
-
不要なブランチの削除: 作業が完了したブランチは、プロジェクトの整理のために定期的に削除します。これにより、ブランチの一覧が見やすくなり、管理がしやすくなります。
プロジェクトによっては、ブランチの運用ルールを決めておくことがよくあります。例えば、以下のようなルールが一般的です。
-
メインブランチの保護: メインの開発ブランチ（通常は
mainやmaster）には、直接のコミットを禁止し、必ずプルリクエスト（PR）を介してマージを行うルールを設けることが多いです。これにより、コードレビューを実施し、品質を保つことができます。 -
機能ブランチの命名規則: 機能やバグ修正ごとに新しいブランチを作成する際、一定の命名規則を設けることで、何のためのブランチであるかを明確にします。例えば、
feature/新機能名やbugfix/バグ内容といった形式がよく用いられます。 -
定期的なマージ: 定期的にメインブランチの変更を各機能ブランチに取り込むことで、コンフリクトを早期に解消することが推奨されます。これにより、最終的なマージ時に発生するコンフリクトを減らすことができます。
-
不要なブランチの削除: 作業が完了したブランチは、プロジェクトの整理のために定期的に削除します。これにより、ブランチの一覧が見やすくなり、管理がしやすくなります。
プロジェクトによっては、ブランチの運用ルールを決めておくことがよくあります。例えば、以下のようなルールが一般的です。
-
メインブランチの保護: メインの開発ブランチ（通常は
mainやmaster）には、直接のコミットを禁止し、必ずプルリクエスト（PR）を介してマージを行うルールを設けることが多いです。これにより、コードレビューを実施し、品質を保つことができます。 -
機能ブランチの命名規則: 機能やバグ修正ごとに新しいブランチを作成する際、一定の命名規則を設けることで、何のためのブランチであるかを明確にします。例えば、
feature/新機能名やbugfix/バグ内容といった形式がよく用いられます。 -
定期的なマージ: 定期的にメインブランチの変更を各機能ブランチに取り込むことで、コンフリクトを早期に解消することが推奨されます。これにより、最終的なマージ時に発生するコンフリクトを減らすことができます。
-
不要なブランチの削除: 作業が完了したブランチは、プロジェクトの整理のために定期的に削除します。これにより、ブランチの一覧が見やすくなり、管理がしやすくなります。
GitHub Discussionsは、リポジトリ（プロジェクトのコードやファイルが保存されている場所）内で意見交換やディスカッションを行うための機能です。プロジェクトに関する質問や提案、アイデアを共有できる場を提供します。
-
オープンな議論の場: 開発者やユーザーが自由に意見を述べられる場所です。誰でも参加でき、さまざまな視点を集めることができます。
-
構造化された議論: ディスカッショントピック（話題）をカテゴリ分けして整理できます。たとえば、「一般的な質問」「機能リクエスト（新しい機能の提案）」「バグレポート（問題の報告）」などのカテゴリを作成できます。
-
通知とサブスクリプション: 興味のあるディスカッションにサブスクライブ（登録）すると、新しい投稿やコメントがあったときに通知を受け取れます。これにより、見逃さずに情報を追うことができます。
-
検索性: ディスカッションの内容は全文検索が可能です。過去の議論を簡単に参照したり、同じような質問を探すことができます。
-
リッチなマークダウン: コメントには、コードスニペット（コードの一部）、画像、リンクなどを挿入できます。これにより、よりわかりやすい説明が可能になります。
-
リポジトリページに移動: プロジェクトのリポジトリページから「Discussions」タブをクリックします。
-
新しいディスカッションを開始: 「New discussion」ボタンをクリックします。
-
カテゴリの選択: 適切なカテゴリを選び、ディスカッションのタイトルと本文を入力します。具体的でわかりやすい内容にすることが大切です。
-
コメントに返信: 他のユーザーからのコメントに対して返信したり、リアクション（感情表現）を付けることができます。
-
ディスカッションの管理: ディスカッションを「解決済み」にしたり、「ピン止め」して重要なトピックを目立たせたり、カテゴリを変更することもできます。
プルリクエスト（PR）は、別のブランチで行った変更をメインのブランチに統合するためのリクエストです。PRを作成することで、他の開発者に変更内容を確認してもらい、フィードバックを得ることができます。これは、コードレビューのプロセスを促進し、コードの品質を向上させるために重要です。
- レビュー: プルリクエストには、他の開発者からのコメントやフィードバックを受け取る機能があります。これにより、コードの改善やバグの指摘が可能になります。
- マージ: プルリクエストが承認されると、その変更をメインのブランチにマージできます。この際、競合が発生することもありますが、その場合は手動で解決する必要があります。
コミットは、Gitで行った変更を記録することを指します。変更をコミットすることで、プロジェクトの状態を特定の時点で保存し、履歴として残します。
- 変更履歴の管理: 各コミットには、変更内容を説明するメッセージを付けることができます。これにより、過去の変更を追跡しやすくなります。
- ロールバック: 何か問題が発生した場合、過去の状態に戻す（ロールバック）ことができます。これにより、安心して開発を進められます。
リポジトリは、プロジェクトのコードやファイルが保存されている場所です。GitHubでは、リポジトリはプロジェクトごとに作成されます。
- バージョン管理: リポジトリ内のすべてのファイルのバージョンが管理されます。これにより、過去のバージョンに戻したり、変更履歴を確認したりできます。
- コラボレーション: リポジトリを共有することで、複数の開発者が同時に作業できる環境を提供します。
クローンは、リモートリポジトリの内容をローカル環境（自分のコンピュータ）にコピーすることを指します。これにより、インターネット上のリポジトリにあるコードを自分のPCで編集したり、実行したりできます。
-
git clone <リポジトリURL>: リモートリポジトリの内容をローカルにコピー(クローン)します。 -
git init: 新しいGitリポジトリを作成します。既存のプロジェクトフォルダでこのコマンドを実行すると、そのフォルダがGitで管理されるようになります。 -
git add <ファイル名>: 変更したファイルを stagingエリア(インデックス)に追加します。git add . とすると、カレントディレクトリ以下のすべての変更ファイルが stagingエリアに追加されます。 -
git commit -m "コミットメッセージ": stagingエリアに追加されたファイルの変更を、ローカルリポジトリに確定(コミット)します。-mオプションでコミットメッセージを指定します。 -
git push <リモート名> <ブランチ名>: ローカルリポジトリの変更をリモートリポジトリ(GitHubなど)に反映(プッシュ)します。通常は git push origin main が使われます。 -
git pull <リモート名> <ブランチ名>: リモートリポジトリの変更をローカルリポジトリに取り込み(プル)します。他のユーザーの変更を取り込む際に使用します。 -
git switch <ブランチ名>: 指定したブランチに切り替えます。git switch -c <新ブランチ名> で新しいブランチを作成し、そのブランチに移動できます。 -
git merge <ブランチ名>: 指定したブランチの変更を、現在のブランチにマージ(統合)します。 -
git status: ローカルリポジトリの状態を確認します。変更ファイル、stagingエリアの状況、コミットの有無などが分かります。
-
git log: コミットの履歴を表示します。git log --oneline で簡潔な表示になります。 -
git diff: 変更点(差分)を表示します。git diff HEAD でローカルの変更点を、git diff <コミットID> で指定したコミットとの差分を確認できます。 -
git branch: ローカルのブランチ一覧を表示します。git branch -a でリモートブランチも含めて表示されます。 -
git checkout <コミットID>: 指定したコミットの状態に移動します。git checkout - で直前のブランチに戻ります。 -
git reset --hard <コミットID>: ローカルリポジトリを指定したコミットの状態に強制的に戻します。変更を取り消す際に使用しますが、注意が必要です。 -
git stash: 作業中の変更を一時的に退避させます。git stash pop で退避した変更を復元できます。 -
git remote add <リモート名> <リポジトリURL>: 新しいリモートリポジトリを登録します。
これらのコマンドを積極的に活用し、Gitの効率的な運用を心がけましょう。
GitやGitHubを使用する際には、いくつかの注意点があります。特に、通常のコードライティングではあまり考慮しないような行為や、避けるべき行動が存在します。以下に、代表的な「やってはいけないこと」を挙げます。
- 何をしたのかがわからないメッセージ：適当なメッセージや一言だけのメッセージ（例：「修正」）では、変更内容が把握できません。具体的な内容を書くように心がけましょう（例：「バグ修正：ログイン機能のエラーを修正」）。
- 小さな単位でコミットしない：多くの変更を一度にコミットすると、何がどのように変更されたのかが不明瞭になります。関連する変更をまとめて、小さな単位でコミットすることが重要です。
-
バイナリファイルや機密情報：ソースコード以外のファイル（例：大きなバイナリファイルやパスワードが含まれたファイルなど）をコミットすることは避けましょう。
.gitignoreファイルを使って、無視するファイルを指定することができます。データに関してもよっぽどのことがない限りUploadするべきではないです。
-
強制的なプッシュ（
git push --force）：他の人の変更を無視して強制的にプッシュすると、協力作業が台無しになります。特に共有リポジトリでは注意が必要です。
- レビューを行わない：プルリクエストはコードレビューを行うための重要な機会です。内容を確認せずにマージすることは避け、必ずレビューを行いましょう。
- 変更をドキュメントに反映しない：コードを変更した場合は、関連するドキュメントも更新することが重要です。変更が反映されていないと、他の開発者が混乱する原因になります。
- リモートリポジトリとの同期を怠る：定期的にリモートリポジトリからプルを行わないと、他の開発者の変更を取り込むのが遅れ、マージコンフリクト（変更の衝突）が発生しやすくなります。
- 公開リポジトリでのプライベート情報の共有：プライベート情報（パスワードやAPIキーなど）を公開リポジトリに含めないようにしましょう。セキュリティ上の重大なリスクとなります。
git clone https://github.com/matsuoinstitute/chatbot-demo
git switch -c feature/xxxxxxの部分は、このブランチでの主な作業内容を英語で書きましょう（例：新たにLangchainを導入したい→feature/add_langchainなど）
git add -u or {特定のファイル} or .
git commit -m "作業内容"
git push origin feature/xxx「作業内容」は、このコミットでやったことが見た人に伝わるような内容にしましょう。
コミットメッセージに関する参考記事：
git push origin feature/xxxが成功すると、Githubの「Pull requests」で以下のようにPRを作成できるボタンが表示されます
上記のような画面が表示されない時
「New pull request」から、自分のブランチを選択し、「Create pull request」をしましょう。
続いて、このような画面になるかと思います。タイトルやイシューの紐付けなどを行い、PRを完成させましょう！
この時点で、まだ完成していない、このブランチでやるタスクがもう少しある、という場合は、ドラフト状態でPRを作っておき、作業が終わったら「Ready for review」でPRを完成させましょう。
作業が終わったら...
-
┗ 公式リファレンス。コマンドに関して疑問点があったら、こちらを参照してください。
-
┗ 公式のチュートリアル。Webブラウザ上で動作するインタラクティブな教材なため、手軽に学ぶことができる。