初心者向け学習方法一覧はこちら
この記事では、GitHubのメリットと、利用方法について解説します。
GitHubとは
GitHubとは、開発したソースコードを保存・共有するバージョン管理ツールです。ソースの修正、ファイルの追加、削除などを変更履歴として保持することで、不具合が発生した時などに、どの地点で発生したのかを把握したり、過去の時点のソースコードまで巻き戻したりすることができます。
一人で開発する際にはあまり気にすることはないですが、チームで開発をする時には、誰が、いつ、どんな変更をしたのかを管理する必要があります。また、誰かが開発したソースコードを最新の状態にアップデートしたり、変更理由や変更によって変わる要件の記載、バグの起票やレビューなどもGitHub上で管理することができます。
初めてのプログラミングを学ぶ際に、GitHubの情報は必須ではありませんが、開発途中に、自分がどの箇所を修正したかのか差分を把握することや、修正前の状態に戻すことができるので学習中から利用することをおすすめします。
また、使い方を知らない新人が開発現場で大事故を引き起こすことがありますので、開発の現場に配属されるまでの間には使い方は学習してください。
Gitの成り立ち
GitHubはサービスの名称ですが、元はGitというCLIの分散型バージョン管理システムの仕組みがありました。Git登場以前のバージョン管理システムでは、複数人の人が、共通のファイルを同時に編集していました。しかし、全員が同時にファイルの編集すると、お互いの修正が競合したり、上書きするなどしてしまうため、整合性を維持すること極めて困難でした。
そこで、Gitでは全員のソースコードを集約する共有の場所(リモートリポジトリ)とは、別に開発者の手元のローカルリポジトリを分離することで、個々の開発者が手元で自由に開発できるようにしました。Gitの仕組みを利用したバージョン管理ツールは、GitHub以外にもGitLab、BitBucketなどがあります。サービスとしての特徴はもちろん異なりますが、サービスの運用視点に立つのでなければ、最も利用されているGitHubに慣れ親しむと良いでしょう。
従来のバージョン管理システム
Gitのバージョン管理システム
基本的なGitのバージョン管理方法
GitHubを理解するには、GitHubがチームで効率よくサービス開発するためのソースコードを管理するためのツールだということと、ソースコードを管理するためのお決まりの御作法があるということを理解していれば、コマンドの使い方も理解しやすくなります。
この章では、GitHubで利用される概念と用語の説明と、開発現場で広く浸透している御作法について解説します。
Gitの管理方法
- ローカル環境
- ワークスペース:手元の作業環境。作業内容がそのまま反映される。
- インデックス(ステージング):ワークスペースで発生した修正のスナップショットを保持する。
- ローカルリポジトリ:リモートリポジトリとローカル環境で変更した差分を保持する。
- サーバー環境
- リモートリポジトリ:ローカルリポジトリの変更内容を保持する。
Gitでは、リモートリポジトリとローカルリポジトリを分離することで、開発者が自由に開発ができると説明しましたが、ローカルリポジトリを直接編集するのではなく、ワークスペースで開発した内容を、インデックスに登録し、差分をローカルリポジトリにコミットします。つまり、ワークスペースで更新した内容は、意図的にGitコマンドを入力してリポジトリに登録し、開発内容を公開するタイミングで、リモートリポジトリにプッシュする必要があります。
ソースコードを修正したのに、コミットできない、リモートリポジトリの内容をフェッチしたのに、手元で開発できないというようなことがないよう、自分がどのコマンド操作を、どこの環境に対して行っているのかを一通り把握してください。
Gitのブランチの切り替え
Gitの優れた機能として、ブランチを複数切り替えることができます。ブランチとは、開発内容を枝分かれさせてることができる機能です。パラレルワールドが出来上がるように、ブランチを分岐させればブランチごとに異なる開発を進めることができます。オリジナルのブランチからAとBのブランチを作成した場合、Aで開発した内容をコミットし、Bのブランチに切り替えば、Bでは別の開発を進めることができます。また、BからAに戻ると、Aはコミットした状態の変更内容から再度開発を進めることができます。
Gitのブランチの作成は、ブランチ名を決めれば簡単にできますが、ブランチの命名規則を統一させたり、目的・用途に応じてブランチを分岐させた方が、後から原因の調査や問題の特定をしやすくなります。今回は、開発現場でもよく使われるGit-Flowというリポジトリの分岐モデルのルールを紹介します。
Git-Flowのブランチ
メインブランチ
- master
- リリース済みのソースコードを管理するブランチです。このブランチの内容を直接開発することはありません。masterに反映された内容は、developにも反映する必要があります。
- develop
- 開発中のソースコードを管理するブランチです。deveopという名称ですが、このブランチの内容を直接開発せず、developブランチから分岐したfeatureブランチ上で開発をします。
サポートブランチ
- feature
- 機能を開発するためのブランチです。developブランチから分岐させ、開発完了後には、developにマージします。
- hotfix
- リリース後に発生した緊急対応の必要な修正対応をするときに使います。開発完了後には、masterにマージします。
- release
- プロダクトをリリースするための準備を行います。developブランチから分岐し、品質が担保できたタイミングでmasterにマージします。
GitHubの使い方を学ぶには
Gitコマンドの使い方がわからない時に参照する定番のサイトです。
お馴染みのドットインストールです。アーカイブされているため、古い情報も含まれているかもしれませんが、一通りの概念を理解する上で役に立つので参考にしましょう。
英語ですが、視覚的にGitコマンドを把握できるサイトです。エラーが発生した時に、訳もわからず適当にGitコマンドを叩いてエラーを連発させないよう、どのリポジトリでどこコマンドを入力するべきか意識的に把握するようにしましょう。
コマンドだけ覚えても、やっぱりやらかしてしまう人はいます。Gitに対する不安がある方は、視覚的に理解すると良いので、初心者向けのスライドも参考にしてください。
基本的なGitHubの使い方は以上ですが、開発現場でどうしようもないやらかしをしてしまった時は、QiitaやZennなどの開発者向けブログサイトも参考にしてください。
プログラミングスクールの選び方
転職を検討中の方向け
フリーランス・副業で活躍したい方向け
教養・キャリアアップしたい方向け
給付金について詳しく知りたい方向け