複業フリーランスのhillpointです。
この記事では、これから、ITエンジニアになろうという人が、最低限が知っておくべき、Gitの基礎知識とGitの使い方について、超入門編をお届けします。
なに？？？
プログラムのソースコードの
バージョン管理をしてくれる
便利なツールです。
プログラムを使って、システムやサービスを開発すると、いろんな変更が発生します。
一度作ってしまえば、完成！といったことには、絶対ならないのが、プログラミングです。
そんないろんな変更の履歴を管理してくれるのがバージョン管理ソフトです。
使い方の例として
プログラムのソースコードいじってました。
あ？こりゃ失敗だ。
もとに戻したい！
あれ、エディタの戻るじゃ戻らない・・・
はい、バージョン管理ソフトの出番です。
いじる前の、ソースコードにもどします！
てな感じです。
バージョン管理ソフトでは、ソースコードの履歴を管理してくれる以外に、こんな機能があります。
・ソースコード以外のファイルもバージョン管理（＝履歴管理）できる。
・１つのファイルを複数の人で修正する場合、整合性を保ってくれる。
このバージョン管理ソフトで、一番使われているのが、Gitというバージョン管理ソフトです。
バージョン管理ソフトを使うことは、エンジニアにとって、当たり前のことで、Git使えますか？とか聞かれることもない、絶対必須のスキルとなります。
専門用語について
アイコンがついている専門用語は、「知らないと恥ずかしいITエンジニアの用語集」ページに説明を記載しているので、専門用語の意味が解らない場合、リンクをタップして、説明を参照してください。
Gitの基礎知識
知らなくても良いですが、バージョン管理ソフトには、いろんな種類のものがあります。
そんな中、今一番使われているのが、Gitなんですが、こんな特徴があります。
Gitは、分散型バージョン管理ソフトです。
Git以外のバージョン管理ソフトは、サーバ集約型のバージョン管理ソフトでした。
例えば、ワードやエクセルで作ったファイルをみんなに公開したい場合、みんなが参照できるファイルサーバやGoogle Driveなんかに保存して公開しますよね。
で、公開したけど、ちょっと修正しましたなんて場合は、公開していたファイルのファイル名をちょっと変えて（日付やbackupなんてつけたりして）、新しいファイルを公開したりします。
昔のバージョン管理ソフトは、このようなサーバでのファイル公開や履歴管理を自動でしてくれるソフトでした。
Gitは、これをローカル（自分のパソコン）で、できるようになっています。
自分のパソコンで、バージョン管理して、最後に整った結果をサーバへ送るみたいな感じです。
これのなにが便利か？というと、だいたいの作業は、自分のパソコンでしますが、自分のパソコンの中でも、バージョン管理してくれるので、失敗したり、間違ったりしても、簡単に元に戻せます。
加えて、試しに変更してみたり、２パターン作ってみて、良い方法を公開しようなんて思っていたら、そのお試しで作ったものもバージョン管理してくれます。
その後、仕上がったら、サーバへ送るのですが、この操作も、とても簡単で、「Push」という操作をするだけで、サーバへ送ってくれます。
サーバに送ってみたら、誰か他の人が同じファイルを編集していたら、「被ってますよ。」と教えてくれたり、両者の変更をうまいことマージしてくれたりします。
Gitは、ファイルを管理してくれる優秀な秘書といった感じです。
インターネット上で、プログラムのソースコードを保存・公開することができるGitHub（ギットハブ）というサービスがある
Gitを調べると、必ずセットで、GitHubというキーワードがでてきます。
GitHubとは、ソフトウェア開発プロジェクトのためのソースコード管理サービスです。
世界中の人々がプログラムコードやデザインデータを保存・共有・公開できるサービスです。
なにが便利かというと、自分で作ったプログラムやデザインをGitHubにアップすることで、インターネット上、これを共有することができます。
そして、それをそのままバージョン管理続けることができ、自分以外のエンジニアが修正を加えることが可能なんです。
公開されているソースコードの閲覧や簡単なバグ管理機能、SNSの機能を備えており、エンジニアにとって無くてはならないサービスです。
もちろん、公開範囲の設定やセキュリティも万全なので、この、GitHubを使ってバージョン管理を行っている企業も多数あります。
Gitの使い方
Gitの使い方については、「サル先生のGit入門」参照とします。
なぜなら、とても分かりやすく、完成度が高いから。
やりたいことで調べる「逆引きGit」も準備されており、抜群に良いです。
なお、このサル先生のGit入門は、BackLogというプロジェクト管理ツールのヘルプページです。
BackLogとは、日本製の有名なプロジェクト管理ツールで、チケットによる課題管理やガントチャートによる進捗管理など、プロジェクトを進行する上で、必要な機能がオールインワンで搭載されているWebサービスです。
BackLogには、Gitをはじめとするバージョン管理のサーバを担う機能も搭載されております。
なので、サル先生のGit入門を進めていくと、BackLog上のレポジトリ（ファイルやディレクトリの履歴や状態を記録する場所）を使用する説明がありますが、この部分は、GitHubを使うようにすれば、BackLog無しでもサル先生のGit入門を進めていけます。
余談：サル先生のサルでもわかる入門書
IT業界では、時に、「サルでもわかる」という表現をします。
実際、サルではわかりませんが、誰にでもわかる、理解できるように書くことを現しています。
この表現が、一番よく使われるのが「手順書」です。
例として、不特定多数の人に、なにかのソフトやアプリをインストールする手順書を作るとします。
このような手順書は、どんな人が、どんな環境で使用するかわからないので、誰がやっても、どこでやっても、うまく行くように、書くことが求められます。
なぜなら、難しい部分や解りにくい部分があると、使った人が、混乱したり、間違えたり、うまくできずに余計に時間を浪費してしまいます。
時間がかかっても、インストールできれば良いのですが、問題が発生して解決できない場合は、発行元に問合せとなります。
そもそも、問合せする時間が無駄ですし、受けるほうも、回答の手間が発生します。
くわえて、多数の人から、同じ問合せを受けるなんてことにもなりかねません。
こんな風にならないよう、「サルでもわかるように書いて」という風に使います。
Git-flowについて
サル先生のGit入門で、Gitの使い方は、理解されたとします。
Gitには、masterブランチやdevelopブランチ、releaseブランチなど、いろいろな用途のブランチがあることが解ったと思います。
これらを使いこなすため、実際のシステム開発の現場では、Git-flowと呼ばれるフローに従って、Gitの利用を進めます。
フローといいつつも、プラグイン（ツール）があり、Git-flowを適用すると、Git-flowのフローに従ったバージョン管理が可能となります。
有名なフローがこれなんですが・・・
https://nvie.com/posts/a-successful-git-branching-model/より
わからんですよね・・・
ちょっと噛み砕いて説明します。
https://www.atmarkit.co.jp/ait/articles/1708/01/news015.htmlより
わかりやすそうな図を「@IT」で見つけたので、これで説明します。
この図は、Git-flowでブランチをどのように使うか示しています。
Git-Flowで使われるブランチ
この図で使用されるブランチを上から説明します。
- master
正式版のブランチ。本番環境（ユーザーが使っている、世にでている）と同一となるブランチ。
勝手にいじると怒られる。 - hotfix
正式版に問題、バグがあり、緊急で修正する際に使うブランチ。
このブランチだけ、masterとdevelopの両方にマージすることが許される。
とは言え、バグ改修が目的なので、あまり使いたくないブランチ。 - release
プログラムの機能追加や変更を本番環境へリリースする時に使うブランチ。
リリースしてもたものの、失敗（問題発生）した場合は、masterへ戻す必要があるので、リリース用のブランチを使うわけ。 - develop
開発時において、複数の人が行うプログラムの機能追加や変更を集約するブランチ。 - feature
開発時において、機能追加や変更を行うブランチ。開発する人が作って利用する。
試験完了したら、developブランチへマージする。
Git-Flowの使い方（フローの流れ）
この図に使用されるブランチをもとに、使い方（フローの流れ）を順番に説明します。
- プロジェクト開始時、masterブランチを作り、masterブランチからdevelopブランチを作ります。
ともにまだ何もない状態。 - developブランチからfeatureブランチを作成し、プログラミングしてプログラムを開発します。
- プログラムが開発完了したら、developブランチへマージします。
マージは、管理者へ依頼を出して、管理者がレビューを実施し、問題無ければ、マージする。という流れを取ることが多いです。 - みんなの開発が完了し、developブランチが完成したら、リリース準備です。
- リリースは、developブランチからreleaseブランチを作成します。
- releaseブランチを使って、本番環境へリリースを行います。
- リリースが成功したら、releaseブランチをmasterブランチへマージします。
もし、問題があったり、失敗したら、マージはしません。再度、④からやり直し。 - 本番環境で、問題発生し、急遽修正しないといけない場合は、hotfixブランチを作成して、修正作業を実施します。
- hotfixブランチをリリースして、問題無ければ、masterブランチとdevelopブランチへマージします。
- また、次の開発が始まったら、②から再開です。
まとめ
なぜ？こんなバージョン管理ソフトを使うか？というと、複数の人で、プログラミングしてシステムなりサービスを開発すると、必ず、「バージョン間違ってます。。。」問題が起きます。
特に多いのが
「なぜか？前のバージョンに戻っています。」
これをIT業界では、「先祖帰り」なんていいます。
次に多いのが、バージョンのアンマッチ
「あのソフトのバージョンが古いです。」
「あのソフトとバージョンがあっていません。」
「バージョン確認して頂けましたか？」なんて、文句言われるのもよくあります。
こおいう問題って、無駄なんですよね。。。
なんというか、ヒューマンエラーというか、凡ミスというか。
こおいう無駄な問題を無くしたいので、バージョン管理ソフト使います。
自分を守るためにも、Gitによるバージョン管理は、しっかり身に着け、適切なバージョン管理ができるようにしましょう。
以上 「Gitってなに？から始めるGitの基礎知識と使い方」でした！