[超初心者] Github入門

概要

超初心者がGitHub関して纏めます。
また、シナリオに沿ってどのような操作が必要になるかも纏めます

まずは、Gitが生まれた背景を見てみましょう

ソースコード管理の歴史

ソースコード管理（Source Code Management, SCM）は、ソフトウェア開発における欠かせない要素であり、その進化はソフトウェア開発プロセスの革命をもたらしました。

中央集中型バージョン管理（CVCS）の課題

ソフトウェア開発の初期には、中央集中型バージョン管理システム（CVCS）が主流でした。CVCSでは、プロジェクトのソースコードは中央リポジトリに集約され、開発者は中央リポジトリからコードをチェックアウトして編集しました。しかし、CVCSには以下の課題がありました

• 競合とコンフリクトの管理: 複数の開発者が同時にコードを変更すると、競合やコンフリクトが頻繁に発生しました。これを解決する手段が必要でした。

• 履歴の管理: プロジェクトの変更履歴を効果的に追跡し、特定のバージョンを特定する方法が不足していました。

BitKeeperとDVCSの出現

Linus Torvalds(リーナス・トーバルズ)氏は、BitKeeperを使用してLinuxカーネルのソースコード管理を行っていました。BitKeeperは商用バージョン管理ツールで、Linuxカーネルの開発者は無料で使用する特権を得ていました。しかし、BitKeeperのライセンスに関する問題が発生し、Linuxカーネルの開発者コミュニティ内で不満が高まりました。この問題は、BitKeeperの使用を継続することが難しくなり、Linus Torvalds氏がGitを開発するきっかけとなりました。

Gitの誕生 (2005年~

SCM問題への解決策として、Linus Torvalds氏はGitを開発しました。Gitは分散バージョン管理システム（DVCS）であり、以下の特徴を備えています

• 分散性: 各開発者は中央リポジトリとローカルリポジトリの両方を持ち、オフラインでも作業できます。競合やコンフリクトを最小限に抑え、柔軟な作業を可能にしました。

• 履歴の管理: Gitは優れた履歴管理を提供し、変更履歴を透明かつ効果的に追跡します。これにより、特定のバージョンを特定しやすくなりました。

• 分散協力: 開発者は地理的に離れていても協力し、コードを共有しやすくなりました。これはオープンソースプロジェクトにとって特に重要です。

• 柔軟性: 開発者は異なるワークフローに合わせてGitをカスタマイズできます。

Gitは成功し、Linuxカーネルの開発においても使用されました。その後、Gitの影響力は拡大し、GitHubやGitLabなどのプラットフォームが登場し、ソフトウェア開発プロセスを大きく変革しました。

GitHub (2008年~

Gitベースのソースコードホスティングプラットフォームで、多くの開発者によってソースコードがホストされ、共有されています。主要な機能には次のものがあります

• プルリクエスト: 開発者は変更を提案し、コードレビューと協力を行うためのプルリクエストを作成できます。

• イシュートラッキング: 問題やタスクを追跡し、プロジェクトの進捗を管理できます。

• コラボレーション: チーム内外の開発者がプロジェクトに参加し、コードを共同で開発できます。

• ウィキとドキュメンテーション: プロジェクトに関する情報を整理し、ドキュメンテーションを提供できます。

GitLab (2011年~

Gitベースのソースコード管理プラットフォームのもう1つの重要な選択肢です。以下はGitLabの特徴です

• 自己ホスティング: GitLabはオンプレミスで自己ホスティングすることができ、セキュリティとデプロイメントのコントロールを提供します。

• CI/CDパイプライン: 統合とデリバリーのための自動化ツールを統合し、DevOpsの原則を支援します。

• アクション: イベントに応じた自動化を可能にするアクションという概念を提供します。

• 柔軟なライセンス: GitLabはオープンソース版とエンタープライズ版を提供し、異なるニーズに合わせて選択できます。

---

ここからはGitHubの話題に戻り、基本的な概念を紹介します

Githubの基本的な操作フロー

リポジトリのクローン (Clone)

ソフトウェアプロジェクトのリポジトリ（コードベース）をGitHubからローカルに複製します。これにより、自分のコンピュータで作業できるようになります。

次のコマンドでリポジトリをクローンします。

git clone <リポジトリのURL>

ソースコードの改修 (Edit)

ローカルでコピーされたリポジトリ内で、必要なコードの変更や改修を行います。この段階ではまだ変更はリモートリポジトリに影響を与えません。

コミット (Commit)

ソースコードの改修が完了したら、変更をコミットします。コミットは変更のスナップショットを作成し、変更の説明（コミットメッセージ）を付け加えます。

git commit -m "変更内容の説明"

プッシュ (Push)

ローカルでのコミットが完了したら、変更をリモートリポジトリにアップロード（プッシュ）します。これにより、他の開発者と変更を共有できます。

git push

プルリクエストの作成 (Create a Pull Request)

プッシュした変更を元のリポジトリに統合するために、プルリクエスト（Pull Request, PR）を作成します。PRは変更内容とその説明を含むリクエストで、他の開発者に対して変更の確認とレビューを依頼します。

マージ (Merge)

プルリクエストをレビューし、変更が承認された場合、リポジトリの管理者が変更をマージします。これにより、変更が元のリポジトリに統合され、プロジェクト全体に適用されます。

加筆中…