Qt チュートリアル Gitについて語ります Git導入のあれこれ

GitHubにアカウントを作ろう

こんにちは。以前の記事では、Gitって大体どんなものなのか、ということについて語りました。今回は、実際にGitを使ってみようと思います！

まず、Gitを使うには、GitHubか、あるいはGitLabというところでアカウントを作成します。私はどちらも利用したことがありますが、今のところ、どちらも使用感は変わりません。似てるから同じところが開発しているのかな？と思ってしまうのですが、どうやら別の会社組織がそれぞれ運営されているようですね。

ど真ん中の登録ボタン使いますよ。

ここでアカウントを作ります。

初めてのリポジトリ作成

アカウントを作成して入ったら、Newとかボタンがあるので、そこでリポジトリを作成します。

Repository Nameのところが、リポジトリ名です。そのままですね。
ここに、例えば、FirstProjectとか、適当な名前を入れます。

Descriptionは、Optional　つまり書きたければ書いてくださいっていうことです。このリポジトリのちょっとした説明を書きます。

PublicとPrivateは重要です。他人に自分のソースコードを見られたくなければ、Privateにしてください。過去は有料でしたが、今は無料でPrivateにすることができます。基本的にはPrivateで始めましょう。公開は後でいくらでもできます。

Initialize this repository with :
のところは、ReadMeファイルと一緒にリポジトリを作るかどうかを聞かれています。ここにチェックをすると、ReadMeというテキストファイルが同時にリポジトリに入れ込まれます。このReadMeは何を書くファイルなのかというと、あなたのリポジトリの詳細を書くファイルになります。

リッチテキストで書くことができます。ココのドキュメントは、あなたのプロジェクトがどのようなものなのかを他者に説明するために非常に重要です。後で加えることはできますので、別にいいのですが、くわえておいて損はないでしょう。

Add .gitignore
というのも重要です。Git初心者の方にとっては何だこりゃ？という感じですよね。これは、自分が扱いたくないファイルを、gitでは管理しないようにするための設定ファイルです。

じゃあ、どんなものを扱いたくないのかと言いますと、大抵の場合はこういうものです。

buildファイル

buildファイルは、あなたがプログラムをデバッグなりなんなりで実行するたびに、生成されます。それをgitのリポジトリに上げるとどういうことになるかわかりますか？別に何か重大なエラーを引き起こすわけではないんですが、プログラム実行の度に作られるファイルを、わざわざ大事に管理しておくっていうのは無駄だと思いませんか？欲しければまたプログラムを実行すればいいのです。もしこれをリポジトリに含めてしまうと、buildファイル分、余計なコードが管理されることになります。.gitignoreは、こうした、gitで管理するのは嫌なファイル、無駄なファイルを別扱いすることができる設定ファイルなのです。

だからって、gitignoreには何を書けばいいんだ！と思いますよね。Noneがデフォルトですが、読んで字のごとく、これは.gitignore選択用コンボボックスが立ち上がり、なんと、

Qt用の.gitignoreファイルを自動生成することができます。これはどういうことかわかりますね？通常git管理したくないという慣習が成立しているファイルについては、あらかじめQt用の.gitignoreが用意されている、ということです。これは大変便利です。もちろん、先ほどご紹介したbuildファイルも無視されるように設定されています。これはぜひQtを選択しましょう！

(ただ、このファイルは、プロジェクトの作成の時に、バージョン管理システムを選択する際、Gitを選択していれば作成されています。どちらのファイルを残すべきか・・・ですが、私は結局、プロジェクトの作成で作った方を残すようにしています。理由は、そのQtのバージョンにあった.gitignoreが作成されるはずだ、という期待からです。それに引き換え、Gitの方で作成される.gitignoreは、Qtのバージョンアップに合わせて更新されるとは限らないと考えています。そのため、結局は後で上書きを行う処理をしています。全く同じものであるかどうかは、差分を見るアプリなどを利用して見比べてみてください。）

Choose a License
こちらは、あなたのソースコードのライセンスを選択するところです。私がド素人のころ、こう思いました。

あ、自分のソースコード、他人に盗まれたらどうしよう！

ないない（笑）。始めたばかりの人のソースコードは、まず狙われませんので大丈夫。でも、最初にこう思っちゃう人いるかな？今となっては笑い話ですけどね。

というのはまぁおいておいて、ライセンスというのは、自分のソースコードを他人が再利用するときに、その人に示す一定のルールです。

例えば、GPLという有名なオープンソースのライセンスがあります。このライセンスをつけたソースコードにしたとしましょう。あなたのソースコードを誰かが書き換えた場合、それを商用利用したときは、そのソースコードも、必ず公開しなければなりません。例えそのコードの１部を利用したのであるとしても、そうしなければならないのです。

例えば、PyQtというQtのPython用ライブラリがあります。これはGPLです。
このPyQtというライブラリを、あなたのソースコードに組み込んで開発を行ったとすると、PyQt以外のものを利用したソースコードも、全て公開する必要がある、という強力なライセンスになっているのです。

そこで、こうしたGPLライセンスがついたソースコードを使っているソースコードを利用したソースコードも、やっぱり公開しなければならないという伝播現象が起きます。これをGPL汚染と言います。そこで、ソースコードは公開したくないんだよな～と思っている人からすれば、GPLなんて大っ嫌い！という声が出てきます。

ライセンスについてはいろいろあるので、調べてみてくださいね。と言っても、最初から理解できるとは思えませんけどね。いずれライセンスについても、自分の勉強がてらお話できればいいなと思います。

このように、プログラムを書く、と言っても、周辺にはいろいろと知っておかなければならないことが多く存在しているのです。一気に全てを知り尽くすことは無理です。こうした機会を利用して、少しずつ学んでいきましょう。ここでは、最も緩いライセンスである、MITライセンスを選択しておきましょう。MITライセンス、GPLライセンス、LGPLライセンス、BSDライセンスくらいは、早いうちに知っておいた方がいいかもしれません。

Create Projectを押しますと、このような状態になります。あなたの初めてのプロジェクト、そしてそのリポジトリです。ここから全てが始まります。

が！！！

最初にめちゃくちゃ重要なことを言っておくべきだったのに、それを全く言っていませんでした。それは何かと申しますと、

公開鍵と秘密鍵の生成です。

公開鍵と秘密鍵

うわ！なんかややこしそうな話が出てきた！と思いますよね。最初は頭が付いていけないかもしれませんが、このことについては絶対に知っておかなければなりません。

ここは、どうしてこんなものを必要とするのか？素人の方達が理解するためということで、それに焦点を合わせて解説をしていきたいと思います。

まず、GitHubはアカウントが必要でしたよね？普通アカウントを作るからには、GitHubのサービスを使うために、あなたのアカウントを使って、GitHubにログインする必要があります。そして、初めてその中のサービスを使うことができる。これが常識と言えば常識でした。

しかし、それはメンドクサイですよね。ソースコードを書いている人は、ちょっとした修正をしてはプログラムをGitHubのリポジトリに送り込んでいます。この変更をするたび、ログインパスワードを打ち込んで、いちいちコピペとかを行っていたり、コマンド入力で行くとしても、事前にログインが必要とか、煩わしくやってられません。

そこで、公開鍵と秘密鍵を使って、これをログインパスワードの代わりにします。ということは、この仕組みのおかげで、このソースコードを送ってきているのはあなた自身なのだ、ということが特定できるようになる、というわけです。

こうした本人確認を行う仕組みを認証と言いますが、公開鍵と秘密鍵を使った認証以外にも、いろいろな認証方法があります。ですが、それは今は置いておきましょう。

まず、公開鍵というのは、その名の通り、公開する鍵です。誰からも見ることができてしまいます。次に、秘密鍵は、これもその名の通り、秘密にする鍵です。この鍵の内容は、決して第三者に見せてはいけません。

あ、一応断っておきます。鍵と聞いて、私たちの身近にある鍵を想像してしまった人？その気持ちはよくわかるのですが、鍵というのは結局のところ、PCでいえば、暗号文です。人が目で見ても訳の分からない順番で並べられた文字列です。

公開鍵と秘密鍵の話も最初にしておくべきだったのですが、それ以前にもっと重要なことがありました。それは、Gitのインストールです。今は、Windowsでの開発を前提に進めていますから、Git for Windowsをインストールする必要があります。

これをインストールした後、Windows+ Rを押して、powershellを起動します。

OKを押します。

gitがインストール成功していれば、git --versionと叩くと、こんな感じでバージョンナンバーが返ってきます。

githubとのやり取りは、sshという通信プロトコルで行います。ssh-keygenと叩いてみてください。すると、ed25519の公開、非公開のキーペアを生成します。キーは、.ssh/id_ed25519のところに保存されます。

と言ったメッセージが出ます。

ed25519というのは、公開鍵暗号方式の一つです。詳しくは別途調べてください。ここで重要なのは、.sshフォルダという隠しフォルダに、公開鍵と秘密鍵のペアのファイルが入れ込まれる、というメッセージです。

passphraseというのは、要らない場合はそのままEnterキーを押します。それも、２回押しますね。passphraseを入れる場合は、gitを使うたびに、passphraseを入れるよう求められるようになります。githubのアカウントを入れるのは大変ですが、セキュリティのために、ちょっとしたパスワードを入れるくらいならいいよ、という人は、入れてください。ただし、このパスフレーズを忘れてしまわないようにしてください。私の経験上、共用パソコンを使うなんてことでもない限り、必要が無いと思っています。

こうなれば、キーが生成されたことの証拠です。あなたのidが～へ保存された。公開鍵が～へ保存された。そのキーフィンガープリントはこれだ！と書かれています。

こちらが、生成された公開鍵と秘密鍵のファイルです。

で、私はこれをすぐに削除し、今まで使っていたのに戻します。で、このpubという拡張子のファイルを開きます。その中の内容を全てコピーします。pubは、publicのpubです。

GitHubの自分のページに行って、自分のアイコンをクリックします。その中の、Settingsという項目を押します。

すると、こちらの項目があるので、ここをクリックします。
New SSH Keyというボタンを押します。

Titleは、あなたが好きなものを入力してください。
Keyのところにpubファイルでコピーしたテキストをそのまま貼り付けます。
Key TypeはAuthentication KeyでOKです。訳すと認証キーですからね。

Add SSH Keyを押せば、公開鍵の登録は終了します。

公開鍵と秘密鍵って一体？

この仕組みは調べていただくと分かるのですが、なぜ、公開鍵の内容を、GitHubのページに張り付けたのでしょうか。公開して本当に大丈夫なのでしょうか？と言ったいろいろな疑問が湧くと思います。

実は公開鍵認証とは別に、従来は共通鍵認証というのが行われていました。それは、お互いが共通の秘密鍵を持つことによって、認証を行う、というものです。私がAという秘密のテキストがかかれたファイルを持っていて、あなたにもAという秘密のテキストが書かれたファイルが渡されます。そして、私は自分のファイルをその人に送り届ける時、暗号化を行います。この暗号化は、同じ秘密鍵を持っている人にしか復元できないのです。

だから、ここで、ファイルのセキュリティが確保されるのでした。

しかし、この方式は、秘密鍵をやり取りしたい人数分用意しなければならない、ということになります。例えば、100人のプログラマがいる組織で、お互いにやり取りをするという話になると、4950個だっけ。それくらいの鍵が必要になります。そのため、鍵の管理が大変です。

そこで考え出されたのが、公開鍵暗号方式です。例えば、githubのファイルがあります。それをあなたのパソコンに送り届けようとします。まず、githubは、自分のところにあるファイルを公開鍵で暗号化します。そしてそれをあなたに送り届けます。その公開鍵で暗号化されたファイルは、あなたの秘密鍵でしか復元することができません。公開鍵は、どれだけ人々に知られていたとしても、それは暗号化する側の鍵です。秘密鍵が誰にも知られていない以上は、誰もその暗号化された文章を解読することはできません。

逆に、自分のソースコードをgitに送るとき、自分の公開鍵で暗号化します。
じゃあ、今度はGitHub側が秘密鍵を使うんだね？と考えてしまいますが、GitHub側には秘密鍵はありません。これは調べたところによれば、チャレンジレスポンス方式というのを使っているようです。

また、公開鍵暗号方式と秘密鍵暗号方式というのは、明確に分かれているわけではなく、二つを組み合わせることによって、両者のメリットを生かしている仕組みも存在しています。

これのおかげで、私たちはGithubにいちいちログインする必要もなく、リポジトリに自分のソースコードを送り込むことができるのです。

(注：本記事の内容は、上記の本とは何の関係もありません。)