# はじまり こんばんは、エンジニアのお家でまったり 青少将ラジオのニューブルーです。 この番組は、エンジニアだからお伝えできることや、 響きになったことなど、楽しくITを学べるチャンネルです。 聞きに来てくださってありがとうございます。 さて、今日から新しいシリーズを始めたいと思います。 その名も、今こそ知りたいIT用語 という形になっていきます。 今、ただ聞けないIT用語シリーズを聞いて、 ITって意外と面白いかもとか、 もっと知りたいなと感じてくれた、 あなたのための一歩進んだシリーズになっていきます。 ITの世界って、本当に変化のスピードが速いんですけど、 昨日まで専門用語だったものが、 気づけば日々の当たり前になっているみたいな、 この時代の流れに、ただ眺めているだけじゃ、 ちょっともったいないなと思いませんか。 ということで、このシリーズは、 今だからこそ知っておきたい旬の知識を、 皆さんと一緒にしっかりキャッチアップ していきたいと思っております。 エンジニアの専門用語だからとスルーするのではなく、 今一歩進んで、一緒にいろんなことに チャレンジしていきましょう。 ということで、今までなんとなく覚えてきた知識を、 点と点だった知識が線でつながっていくような、 そんな知的なワクワク感を皆さんと 共有できたら嬉しいと思っております。 はい、というのをここまでAIのジェミニンに、 ちょっとオープニングを新しく始めるにあたって、 オープニングを考えて、一緒に考えて、 壁打ちしながら考えてもらったんですけど、 どんな感じですかね。ちょっと気になったりとか、 何かありましたらコメントいただけると嬉しいです。 また、この本シリーズ、いつものように ハッシュタグをまた作ろうと思っておりますので、 今更聞けないIT用語と同時に、今こそ知りたい IT用語のハッシュタグも用意しますので、 そちらからこのシリーズの放送は、 連続で聞いていただければと思っております。 はい、ということで、それではその記念すべき第一回目、 今回はGitとGitHubをちょっと取り上げようかなと思っております。 GitとGitHub、よく似ているようでというか、 エンジニアの業界ではこれがもうスタンダードに なってきているものになるんですけど、 その辺りを、でもエンジニアだけじゃなくて、 普通のWindowsとかでいろいろファイルを、 いろんなファイルを作られている方とか、 そういう方は取り入れていただけると便利かなと思ったので、 まず第一回目で取り上げたいと思っております。 # Git、GitHubとは❓ ということで、GitとGitHubについて お話をしていこうかなと思っております。 GitとGitHubの前に、まずはGitですね。 Gitは技術の話で、技術というかバージョン管理をする その機能というか、企画みたいなもの。 企画ではないか、考え方というかツールというか、 そういうものになっていきます。 GitHubはまた出てくるんですけども、 Gitを使ったリポジトリの管理サービス。 リポジトリだけじゃないですけど、いろんなこと。 そういうのを一つのサービスがGitHubになってきます。 なので、Gitを使ったサービスがGitHubという形で、 その二つの違いは最初に説明しておこうかなと思っています。 まず、Gitからちょっとやっていきますね。 Gitは先ほど言ったように、ファイルとかのバージョンを 管理するそのシステムになってきます。 Windowsですとか、他のMacとかLinux系の どこでも使えるんですけど、コンピューターとしましょうかね。 コンピューター上で皆さんいろんなファイルを管理というか、 エンジニアですとソースファイルとかになってくるんですけど、 それをどんどん修正していくっていうのが 日々のお仕事というか作業になってきます。 そのときにバージョンを管理していく形になるんですけど、 結構昔はファイル名を変えたりとか、 ほにゃららバージョン1とか、 ほにゃららバージョン2とかって変えて、 最新のやつだけはほにゃららっていう正式名称の名前にして 管理していくみたいなことを、 バージョン管理システムを使わなければ そういう感じになっていると思います。 皆さんでファイルとかいろいろ作られてる方で、 そういうバージョン管理したくなったときに、 どうされてますかっていうときに聞いたら、 もしかしたらこういうファイル名を変えてバージョン管理してるとか、 バージョン管理してないですみたいな方も いらっしゃるかもしれないですけど、 そこにこのGitっていうバージョン管理の システムを入れることによって、 そのあたりが簡単にいきますし、 いろんな複数のバージョンを管理するようになれるという形になってきます。 なので、エンジニアだけでなく、 いろんなWindows上でファイルをいろいろどんどん修正されて使われてる方とか、 例えば写真を書くことないか、絵を書かれてる方で、 画像ファイルをどんどん変えていかれてる方とか、 その方とかいろいろウェブのデザイナーさんも、 ウェブのデザイナーさんはウェブ系のエンジニアと一緒になるので、 大体ソース管理はGitを使ってる方が多いと思うんですけど、 そんな感じでGitを使う形になっていきます。 Gitで主な特徴で、本当にメインの部分だけちょっとお話しすると、 まず変更履歴、バージョン管理システムなので、 変更履歴の管理ができるようになります。 この管理する1個1個の単位をGitではコミットと呼ぶことになってます。 ですので、とあるAというファイルがいて、 そのAというファイルを変更しました。 ってなったら、そのAというファイルに対して、 こういう修正をしましたよっていうメッセージ付きでコミットっていうことを行います。 それをすることによって、そのAというのが変更、 AへのAというファイルへの変更が確定するという形になります。 それに対して今度はバージョン管理システムですので、 過去の今までの履歴をどんどんたどっていって、 この時のファイルに戻したいっていうことも、 このGitではできるようになってます。 それも簡単にこのファイルに戻すみたいな感じで、 一瞬でそれだけで戻ったりとかするので、 今そのコミットをつけてたときの、 コミットするタイミングのメッセージをちょっとたどっていって、 この時のファイルはどうだったかみたいなのをやったりとか、 テキストファイルとかだったら、 この時点とこの時点の変更の差分を表示して、 こっちを戻すとか、そういうのも簡単にできるようになっています。 画像ファイルとかはどうしてもバイナリファイルになったりとか、 ExcelとかWordとかのドキュメントファイルとかもバイナリファイルになってくるので、 差分がちょっと難しい、 表示しづらい部分もあったりするんですけど、 その辺りはGitとは別で差分表示のツールとかを使って、 うまく表示したりとかして、過去のファイルに戻したりとかもするかなと思います。 次がブランチという機能があります。 これは分岐ということにはなってくるんですけど、 例えば先ほどのファイルでいうと、 Aというファイルを修正しようとなったときに、 Aというものは一旦置いておいて、 そこからブランチを作ることによって、分岐させることによって、 例えばA'みたいなファイルを作って、 そのファイルに対してこういう修正をして、 さらにこういう修正をしてというのを どんどん修正をしてコミットしていくということをします。 それを何回かコミットを繰り返したときで、 A'のファイルが完成したってなったら、 もともとのAというファイル、 その部分に今度はマージという統合かなという形をするんですけど、 それをすることによってブランチという作業場所ですかね、 そんなところでいろいろ修正を加えたものを、 一気にAというファイルにマージするという形で、 Aというファイルが一気に何個かの修正が一気に加わるみたいな形をしたりします。 これ何でいいのかというと、 エンジニアル業界とか関わらずチーム開発ですよね。 チーム開発をする上ではやっぱり一人が同じファイルを修正する、 複数人が同じファイルの中身のAさんがファイルの先頭のほうを直してたら、 Bさんが同じファイルの後ろのほうを直したりとか、 そういうのもしていったりするので、 その辺を同じファイルを一緒に直すことにはせずに、 AさんはAさん用のブランチを作って、 そこで修正したものと、 BさんはBさん用のブランチを作ってという形で、 それぞれAさんのブランチとBさんのブランチを最終的にマージして、 そのあたりはマージの部分についてはGitがうまいように考えてマージしてくれるので、 変な感じにならずに、 同じところを全く同じ行を修正してたらどっち採用しますか、 みたいな確認が入ったりするんですけど、 そんな感じでマージすることによって、 一つのAさんもBさんを直した、 二人が同時に直したような一個のファイルが出来上がるというのを作っていったりもします。 Gitのところでお話を先にしなければいけなかったかもしれないんですけど、 Gitは今本当にエンジニアの業界では、 これがスタンダードになっていってて、 もしかしたらこの後に他のバージョン管理ソフトツールが 出てくるのはもしかしてないかもしれないというぐらいに結構流行っているというか、 これになってしまっている部分もあって、 なぜこれが一番いいのかと言われているのが、 Gitの一個前に流行っていたのが、 SVNと呼ばれるバージョン管理ツールがありました。 SVNというか正式名称サブバージョンと言うんですけど、 そちらのほうが以前バージョン管理ツールで流行ってたんですけど、 そのSVNとGitとの違いって、 まずSVNは管理方法が集中型と呼ばれる管理方法を行います。 集中型で、一箇所に集中させて 管理しようという考え方だったんですけど、 例えるなら、ファイルをとある場所に、 図書館とかにファイルを置いておくと。 それをマスターファイルとして、 何かAさんが修正したくなったらその図書館に行って、 そのファイルを今から修正しますって言って、 持って帰って修正して、 完成したらその図書館に返しに行く という形になっていました。 Bさんが修正したくなったら、 またその図書館に借りて修正して返すみたいな形の修正方法で、 バージョン管理のシステムになっていて、 それが集中型と呼ばれてたんですけど、 なので、中央にあるサーバーというか、 図書館ですよね。 それが動かなくなったらとかいう状態になったら、 最新状態が図書館にあるので、 最新状態が取れないような状態になって、 作業がストップは、本当にストップはしないんですけど、 ちょっと大変な状態になっていったっていうのが、 サブバージョン、SVNの時代はあったんですけど、 Gitが登場することによって、 Gitは今度は分散型と呼ばれる管理方法になってます。 これ分散型なので、例えば図書館自体を 自分の家にコピーしてきちゃうみたいな、 サンプルで出した、例として出した、 なんか変だったかもしれないですけど、 本当にそんな感じのイメージをしてもらったらよくて、 なので、サーバーがもし動かなくなったとしても、 自分の家に持ってきた、コピーしてる 図書館を使って作業ができるっていうのが、 分散型の特徴になってくるのかなと思います。 ちょっとチャプターの時間があれなので、 ちょっとチャプター変えたいと思います。 # Git、GitHubとは❓(続き) というふうに分散して、図書館というマスターを いろんなところに持たせるという形をしたことによって 最近の開発の主流って、 またアジャイルとか言うんですけど、 結構スピード重視というか、 開発をスピーディーに開発していくみたいな 開発スタイルが結構主流になってきているので、 それとGitという考え方というか、 いろんなところにコピーを持とうという考え方が いい感じにマッチしたから結構流行っているのかなと思ったりもします。 そのときにSVNではマスターを1個に限定してましたけど、 Gitでも考え方は1個に限定した方が、 やっぱり人間が使いやすいというのはあるので、 どこか1箇所にマスターを作って作業する っていうのをやったりします。 それのマスターに一番なるというか、 よく使われているのがGitHubとか、 他にGitLabとかいろいろGitのリポジトリと呼ばれて 管理する場所をウェブサービスとして提供している いろんなサービスがあるんですけど、 GitHubが一番、 Hairとかいうか使っている人が多いので GitHubが一番有名なんですけど、 そのリポジトリをGitHubに用意して、 そこをマスターとして使って、 みんなで使い合うという形になります。 今、こうやってGitHubをマスターとして 使うって言ったんですけど、 マスターではないので、分散型、 あくまでGitは分散型なので、 マスターっていうのは人間が勝手にそういうふうな 定義にして使うっていうことになります。 なので、たまにGitHubの説明をされるときに、 GitHubがメインマスターとして使うとか、 例えばバックアップで使うとか、 そういう説明をされるときが結構あるんですけど、 それは実はGitの考え方としては違うというか、 違うものだと私は思っていて、 本当に分散型なので、あくまでそのGitHubは 分散されたコピーの一つでしかないという形になります。 なので、自分のパソコンも1個のリポジトリと 言われるコピーを持ってますし、 そのGitHubも一つのリポジトリのコピーであると。 また、そのリポジトリをコピーした、 例えば私がAさんだとして、 他のBさん、同じプロジェクトのBさんのところにある リポジトリもそれがコピーになってきたりします。 なので、先ほどバックアップじゃないよって言ったのは、 GitHubがマスターではあるっていう考え方で仕事をするんですけど、 実はマスターは、もしかしたらBさんのリポジトリが マスターになってくるっていうこともあって、 Gitってそれぞれのリポジトリのバージョンが 本当にバラバラになるんですよね、たまに。 そのマスターをGitHubにしてないがためというか、 それらを忘れていくと、 それぞれの個人のリポジトリが バージョンが違うバージョンで出来上がっていくんですけど、 そのときにもしBさんのリポジトリをマスターにしてしまうと、 GitHub自体もそのBさんのリポジトリのコピーになってしまうので、 コピーというか全てが同期されるようなイメージを 持ってもらったらいいと思うんですけど、 なので、厳密にはバックアップにならないんですよね。 そのBさんをマスターにした瞬間に GitHubのリポジトリはBさんのコピーになってしまうので、 ちょっと説明が難しいかもしれないですけど、 リポジトリをそれぞれ連携すると、それぞれが同期しあって、 全く同じものが複数の箇所に存在するという形になっていって、 どこをマスターとするかはその使う人次第なので、 バックアップではなくてコピーと言ってもらった方がいいのかなと思ったりします。 そんな感じでちょっと難しくなっていったかもしれないですけど、 最初の今こそ知りたいIT用語シリーズとして、 今どんな感じでやっていこうかなというのもあっているので、 台本も特にこのシリーズは作らないでいこうかなと思っていて、 本当にこのシリーズをノートに、今更聞けないIT用語シリーズはノートに説明文をというか、 お話しする内容を台本みたいなものを作って、 それに沿ってお話しさせていただいてますけど、 この今こそ知りたいIT用語シリーズについては、 こんな感じで本当に難しくなっていくので、 言葉で説明するときも、 私が今思ったことをつらつらとお話ししていこうかなと思うので聞きづらい部分もあったり、 ノートに台本とか作ると本当にさらにわかりにくくなっていってしまうと思うので、 図解とかできればもっとわかりやすいと思うんですけど、 ちょっとそこまでする時間もあれですし、 そういうのをやっていると多分YouTubeとかの方が全然いいものができたりするので、 ボイシーでやっているメリットというか、 お暇なときに聞きながら勉強していただければと思っているので、 そんな感じのシリーズにしていこうと思っているので、 このシリーズは台本なしで つらつらとお話しさせていただこうと思います。 ということで最後まで聞いていただいて、 聞きづらい部分は初めてだったので、 聞きづらい部分とかあったかもしれないですが、 それは申し訳なかったんですが、 今後も今こそ知りたいIT用語シリーズ、 よかったら聞いていただければと思っております。 ということで、もし何かこういうことについて聞きたいですよとか、 本当に一歩進んだIT知識というか、 そういうところをやっていきたいと思うので、 すごい突っ込んだ質問というか、 突っ込んだIT用語でも全然かまわないので、 もし何かご要望みたいなのがありましたら、 コメントとかでお連絡いただければと思っております。 ということで最後まで聞いていただき、 ありがとうございました。 それでは今日も適当にまったりお過ごしください。 ありがとうございました。