【gitをソフト開発で使いこなそう!:第10回】GitHubにSSH接続してみよう!
前回は、GitHubの概要を解説しましたが、今回は実際にGitHubを使ってソースコードを公開する手順を解説します。
2020年6月23日、GitHubの操作方法(UI)が大きく刷新されました。
本連載第10回以降の操作方法の説明は、刷新される前に書かれたものです。大半の操作方法は同じと思われますが、実際の操作方法と異なる場合があります。
GitHubのアカウントを作成する
GitHubを使って、ソースコードを公開するには、まずGitHubのアカウントを作る必要があります。
上のリンクから、GitHub公式ページに移動し、「サインアップ」をクリックしてください。
後は、画面の指示に従えば登録出来るはずですが、上手くいかない場合は下のサイトを参考にしてみてください。
GitHubは無料で使うことも出来ますが、有料の料金プランを使うことでより機能が充実したGitHubを使うことも出来ます。
詳しくは、下のページをご覧ください。
GitHubでは、全世界に公開するリポジトリ(パブリックリポジトリ)と非公開にするリポジトリ(プライベートリポジトリ)の2種類のリポジトリを作成することが出来ます。
以前は、個人向けFreeプラン(名前の通り、無料でGitHubを使える料金プラン)でプライベートリポジトリを作成することが出来ませんでしたが、2019年1月からFreeプランでもプライベートリポジトリを作成出来るようになりました。
古い記事だと、「Freeプランでは、プライベートリポジトリを作成することが出来ない」と書かれている場合があるため、注意が必要です。
プッシュするための設定をする
前回の説明で「ローカルリポジトリから、リモートリポジトリへ変更を反映する」という作業がありました。
この操作のことをプッシュと言います。
GitHubを使う場合、上の説明のリモートリポジトリがGitHubに当たります。
すぐにGitHub上でリポジトリを作成して、プッシュしたい所ですが、いくつか設定の手順を踏まなければなりません。
プッシュ出来る人を制限する
プッシュとは、先ほども説明した通り、リモートリポジトリに変更を反映することです。
GitHub上でリモートリポジトリを作成すると、基本的にそのリモートリポジトリは全世界に公開されてしまいます。そのため、何も考えないと誰でもあなたが作成したリモートリポジトリに、プッシュすることが出来てしまいます。(もしかしたら、コンピュータウイルスを埋め込まれるかもしれない)
そこで、あなたしかあなたが作成したリモートリポジトリにプッシュ出来ないようにしておく必要があります。
GitHubでは、いくつかこれを出来るようにする仕組みが用意されていますが、今回はSSHを使います。
SSHとは?
SSH(Secure Shell)とは、ざっくり言うと誰かに勝手にプッシュされたり、通信している内容を盗み見られないようにするために決めたプロトコル(決まり事)のことです。
今回は、SSHの仕組みについて詳しく説明しません。
詳しい仕組みが知りたい方は、下の記事をお読みください。
2020年現在、デジタル署名やSSHの仕組みについて検索しても正しい情報はほとんど出てきません。これは、インターネットだけでなく入門者向けの書籍も同じような状況です。
下に、デジタル署名やSSHの正しい説明が書かれた記事を載せておきました。最終的にネット検索した記事を見る場合でも、まず下の二つの記事に目を通しておいたほうが良いと思います。
秘密鍵と公開鍵
GitHubでSSHの仕組みを使って、リモートリポジトリにプッシュするためには、秘密鍵と公開鍵という二つの鍵を作成する必要があります。
また、公開鍵はGitHub上に登録する必要があります。
以下、具体的な手順を見ていきましょう。
鍵を作る
まずGitBashを開きます。
GitBashの開き方を忘れてしまった方は、第2回の記事をご覧ください。
そこで次のコマンドを入力します。
ssh-keygen -t rsa -b 4096 -C "GitHubで登録する時に使ったメールアドレス"
すると、次のようなメッセージが出て入力を求められますが、全て何も入力せずにEnterキーを押してください。
Enter a file in which to save the key (/c/Users/you/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again:
最初の入力で求められたのは、鍵の名前です。指定しても問題ありませんが、名前を指定してしまうと鍵がある特定のフォルダに作成されません。
ある特定のフォルダに作成されないと、鍵を追加するための設定が余分に必要になります。
二つ目の入力で求められるのは、秘密鍵のパスフレーズです。
秘密鍵は名前の通り、秘密にしなければいけません。もし漏れてしまうと、自分以外の誰かが勝手にリモートリポジトリにプッシュすることが出来てしまいます。
そこで、もし秘密鍵が漏れたとしても誰かに悪用されないように、秘密鍵を使うのにパスワードのようなものをかけておきます。これをパスフレーズといいます。(今回の設定では、指定していません。)
公開鍵を登録する
公開鍵をGitHub上に登録します。
次のコマンドを入力して、公開鍵の内容をクリップボードにコピーします。
clip < ~/.ssh/id_rsa.pub
続いて、先ほど作成したGitHubアカウントにログイン(サインアップのボタンの隣にサインインボタンがある。そこからログインすることが出来る。)します。
ログイン出来たら、プロフィール画像のアイコンをクリックしSettings
をクリックします。
サイドバーから、SSH and GPG keys
をクリックします。
New SSH key
もしくは、Add SSH key
をクリックします。
先ほどクリップボードにコピーした公開鍵の内容をKey
に貼り付けます。
Add SSH key
をクリックします。これで、リモートリポジトリにプッシュ出来るようにするための設定は完了しました。
設定が上手くいったか確認する
下のコマンドを入力します。
ssh -T git@github.com
設定が上手くいっていれば、次のような表示が出るはずです。
Hi <あなたのユーザネーム>! You've successfully authenticated, but GitHub does not provide shell access.
リモートリポジトリを作成する
プッシュするリモートリポジトリを作成します。
作成したGitHubのアカウントにログインし、左サイドバーのNew
をクリックします。
すると次のような画面が表示されます。
Repository Name(リポジトリの名前)・Description(リポジトリの説明文。リポジトリ名の下に表示される。)を入力します。
その下にあるのは、作成したリポジトリを公開するか、非公開にするか選ぶボタンです。
Publicを選べば、リポジトリは公開され、Privateを選べば、リポジトリは非公開になります。
今回は、Privateにしています。
さらに下にあるのは、リポジトリを作成したときに最初から置いておくファイルを指定する欄です。今回は、何も設定しません。
全ての設定が完了したら、一番下のCreate repository
をクリックします。
プッシュする
ローカルリポジトリを作成する
ボタンをクリックすると、次のような画面が表示されます。
これで、GitHubにリモートリポジトリを作成することが出来ました。
ローカルリポジトリを作って、そこでの変更を今回作成したリモートリポジトリにプッシュしてみましょう。
適当なフォルダ(フォルダの中には、何も入れない)でGitBashを立ち上げます。
まず、新たなリポジトリを作成します。
git init
続いて、何かファイルを新たに作成してください。
ここでは、下の内容を書き込んだTest.txtというファイルを新たに作成します。
早くプッシュしたい
作成したファイルをステージングエリアに追加して、コミットします。
git add --all git commit -m "firstcommit"
リモートリポジトリにプッシュする
作成したローカルリポジトリをリモートリポジトリにプッシュするには、プッシュする先の場所(アドレス)を指定する必要があります。
(……そりゃあそうですよね。どこにプッシュしていいか分からないと、プッシュしようがないですから。)
GitHub上で作成したリポジトリのアドレスは、先ほど見せた画像の青枠で囲ったところに表示されています。
今回作成したリポジトリのアドレスは、下のようになっています。
git@github.com:terapotan/BlogTestRepository.git
このアドレスを、ローカルリポジトリ側に追加します。
もし「https」から始まるアドレスが表示されていたら、アドレスの左隣にある「SSH」というボタンをクリックすると、「git@」から始まるアドレスが表示されます。
今回追加するのは、「git@」から始まるアドレスの方です。
リモートリポジトリのアドレスを追加するにはgit remote
コマンドを使います。
下のコマンドで、git@github.com:terapotan/BlogTestRepository.git
というアドレスをローカルリポジトリに追加します。
git remote add origin git@github.com:terapotan/BlogTestRepository.git
git remote -v
と入力して、次のように表示されれば、追加されています。
origin git@github.com:terapotan/BlogTestRepository.git (fetch) origin git@github.com:terapotan/BlogTestRepository.git (push)
次のコマンドを入力すると、プッシュを行うことが出来ます。
git push -u origin master
先ほど表示したリモートリポジトリのページをリロードすると、確かにTest.txtが追加されているのが分かります。
git pushコマンドでは、プッシュする先のリモートリポジトリを指定する必要があります。
直接リポジトリのアドレスを指定しても、動作しますが、あの長いアドレスをいちいち打つのは面倒です。
そこで、「git remote add <名前> <リポジトリのアドレス>」とすることで、リポジトリのアドレスの別名を指定することが出来ます。
originと言う名前がよく使われているのは、gitがデフォルトで付けるリモート名(リポジトリのアドレスの別名)だからです。
そのため、originという名前に特別な意味があるわけではありません。
実際上の例でoriginをtestに変えても、動作します。
次回予告
次回は、git push
コマンドについて詳しく解説していきます。
う-ん、よく分からん!
この記事を読んで、疑問に思うことがあったときは、気軽にコメント欄や私のTwitterから質問してください。(すぐに答えを返せるとは限りませんが。)
参考文献
Pro Git
git,GitHubを使うにあたって必要なコマンドの使い方が詳しく解説されています。この連載を読んで分からないことや詳しく知りたいことがあったときはまずProgitを読んでみるといいでしょう。 git-scm.com
分散型と集中型バージョン管理
分散型バージョン管理と集中型バージョン管理のデメリットとメリットについて書かれています。
矢をよけろ!【サポート情報】
ここでは、矢をよけろ!のサポート情報を掲載しています。
矢をよけろ!の紹介記事はこちら。
更新履歴
- 2020/3/19:Ver1.0公開
お知らせ
お知らせがある場合は、ここにお知らせを掲載します。
矢をよけろ!
矢をよけろ!(サムネイル/スクリーンショット)
このゲームを遊んでみる
下のリンクから、ゲームをダウンロード出来ます。
キャッチフレーズ
画面のドロイド君を動かして、上から降ってくる矢から逃げ切れ!
どんなゲーム?
ドロイド君を動かして、上から降ってくる矢から、一定時間逃げます。
無事逃げ切ることが出来れば、ステージクリア!
ステージは、EASY,NORMAL,HARDの3種類。
NORMAL,HARDでは、アイテムが降ってくるかも……?
操作方法
- →,←矢印キー:ドロイド君を動かす
- スペースキー:ジャンプする
ソースコード
このゲームのソースコードをGitHub上で公開しています。
(素材ファイルが含まれていないため、ビルドすることは出来ません。)
サポート情報
矢をよけろ!に関するサポート情報は、下の記事からご覧ください。
【gitをソフト開発で使いこなそう!:番外編】デジタル署名のよくある誤解
あなたは、「デジタル署名とはこういうものだ!」と思っていませんか?
……実はこれ、デジタル署名のよくある間違った説明です。
今回の記事では、「なぜこの説明が間違っているのか」「正しいデジタル署名の説明とは何なのか」について解説していきます。
正しいデジタル署名の説明
先ほどの説明がなぜ間違っているかを説明する前に、まず正しいデジタル署名の説明を行います。
デジタル署名で守れるもの
ここに、Aさんとチケットを販売するお店があったとします。
Aさんは、上の図のような手順でチケットを購入することが出来ます。(チケットの購入は、インターネット上で行います。)
ですが、このままでは誰かが、Aさんが「来月のコンサートのチケットを2枚購入する」というメッセージを、「来月のコンサートのチケットを200枚購入する」というメッセージに書き換えてしまう(改ざん)かもしれませんし、Aさんになりすまして「来月のコンサートのチケットを追加で100枚購入する」というメッセージを送ってしまうかもしれません(なりすまし)。
また、チケット販売店がAさんからチケット代金を受け取るときに、Aさんが「え?私そんなメッセージ送ってませんよ? きっと誰かがなりすまして送ったんですよ!」と言われたときに、そうでないことを証明する手段もありません。(否認)
デジタル署名を使うとこれらの脅威から守ることが出来ます。
デジタル署名で守れる脅威の中に盗聴が入ってないのが分かると思います。残念ながら、盗聴はデジタル署名だけでは防ぐことが出来ません。盗聴も防ぎたいのであれば、通信内容を暗号化しておく必要があります。
デジタル署名とは?
先ほど紹介した例を使って、デジタル署名の仕組みについて解説します。
まずAさんは、署名鍵と検証鍵と呼ばれる二種類の鍵を作ります。
署名鍵は外に漏れ出ないように自分以外には秘密にしておきます。
逆に検証鍵は、公開しておきます。
Aさんは、送りたいメッセージと署名鍵(厳密に言うと検証鍵も)を使って署名を作成し、メッセージと署名をチケット販売店に送ります。
チケット販売店は、Aさんから送られてきたメッセージ、署名と公開されている検証鍵を使って、署名が正しいかどうか検証します。
検証では、「送られてきた署名が、送られてきたメッセージとAさんが作成した秘密鍵を使って作られたもの」であることを確かめます。
そうであることが確かめられれば、「このメッセージは間違いなくAさんが送信したものだ」ということを確認できます。(Aさんが作成した秘密鍵を持っているのは、Aさん以外にいないはずだから。)
これで否認となりすましが出来なくなります。
また、検証は送られてきたメッセージと署名を使って行われます。そのため、誰かがメッセージだけ変えて改ざんをしようとしても、そのメッセージに合った署名を作ることが出来ないため、改ざんすることは出来ません。
上のデジタル署名でもし、Aさんの検証鍵が誰かの検証鍵にすり替えられていたら、どうでしょう。すり替えが行われると、Aさんの署名鍵を持っていなくても検証は正しく行われてしまいます。よって、その検証鍵が確かにAさんが作ったものであることを証明する仕組みが必要です。この仕組みをPKI(公開鍵基盤)と言います。
なぜあの説明は間違っているのか?
さて、本題に戻ります。
最初に言った通り、よくデジタル署名の仕組みとして、
のように説明されます。しかし、これは間違った説明です。
なぜ間違った説明と言えるのでしょうか。理由は二つあります。
理由1:デジタル署名そのものの、説明になっていない
もし上の説明のようにデジタル署名を作れるとしても、そのような仕組みを使えば、デジタル署名の仕組みを作れるというだけであって、デジタル署名そのものを説明したことになっていないのです。
理由2:秘密鍵で暗号化して公開鍵で復号することは出来ない
そして公開鍵で暗号化、秘密鍵で復号が出来るからといって、「(公開鍵暗号を使って)秘密鍵で暗号化して、公開鍵で復号する」ことは出来ません。
……なぜそう言い切れるのでしょうか。同じ鍵ですから、なんだか入れ替えられそうな気がします。
これを考えるには、まず公開鍵暗号とはどのようなものだったかを改めて考える必要があります。
公開鍵暗号というのは、
というものであることが分かります。
公開鍵暗号には、様々な種類(RSA暗号、ElGamal暗号など)がありますが、(実際にやっている処理は違うにしろ)上の1~3の入力と出力は、どの公開鍵暗号であっても共通ですし、どんな公開鍵暗号であっても上のように使えば、動作することが保証されています。(というより、上のように使うことを想定して全ての公開鍵暗号は、作られている。)
では、先ほど誤りと言った説明で上と同じように暗号化・復号の手順を書いてみます。
最初に挙げた手順と見比べると、本来公開鍵を入力すべきところに秘密鍵が、公開鍵を入力すべきところに秘密鍵が入力されています。
秘密鍵と公開鍵は、同じ「鍵」という文字がついてはいますが、別物です。(全ての公開鍵暗号は、最初に挙げた手順で行うことを想定して作っている。全ての公開鍵暗号で、鍵をひっくり返して動くことはない。)
ですから、秘密鍵から公開鍵、公開鍵から秘密鍵に入力する鍵を変えることは出来ません。
下の4つのコラムは、もっと詳しく知りたい人向けに書いています。今の段階で理解できなければ、無理に理解する必要はありません。(というか、かえって混乱するかもしれない。)(4つ目のコラムは、コラムの中で数式が書けないため、本文に書いています。)
ここまでの説明を聞いて「いや、秘密鍵で復号、公開鍵で暗号化だったら公開鍵暗号を使ってデジタル署名が作れる!」「RSA暗号だったら、秘密鍵と公開鍵ひっくり返せるのでは?」などと思う方がいらっしゃるかもしれません。(一応下のコラムで説明します。)
しかし、よく考えてみてください。仮にそれらが全て正しかったとしても理由1で述べた通り、「そうやればデジタル署名が作れる」ことを証明したに過ぎないのです。
結局どこまでいっても「デジタル署名そのもの」の説明になることはありません。
上の説明では、秘密鍵で暗号化、公開鍵で復号は出来ないと説明しました。ですが、秘密鍵で復号、公開鍵で暗号化であれば理屈上は可能です。(入力する鍵を変えていないため。)
秘密鍵で平文を復号???と思うかもしれませんが、これは単に秘密鍵と平文を復号するアルゴリズムに入力することを指しています。
ですが、これを行うためには「同じ鍵・同じ平文で暗号化すれば、毎回必ず同じ暗号文が出力される」公開鍵暗号を使う必要があります。
「えっ?何を当たり前のことを。そんな性質のどの公開鍵暗号も持ってるんじゃないの?」と思われるかもしれませんが、全ての公開鍵暗号がこの性質を持っているとは限らないのです。(性質を持っていない公開鍵暗号の例:ElGamal暗号,RSA-OAEPなど)
先ほど説明した性質を持っていない、ということは仮に正しい秘密鍵で復号されたものを公開鍵で暗号化して検証しようとしても、正しく検証出来ない可能性があるということになります。
まぐれで検証が通ったり、通らなかったりするデジタル署名はもはやデジタル署名ではありません。
先ほどのコラムで「全ての公開鍵暗号で出来るわけではない」と書きました。ということは、出来る公開鍵暗号もあるということです。
「同じ鍵・同じ平文で暗号化すれば、毎回必ず同じ暗号文が出力される」という性質を持つ公開鍵暗号として一番有名なのはRSA暗号でしょう。
RSA暗号からであれば、「秘密鍵で復号、公開鍵で暗号化」を行うことでデジタル署名を作ることが出来ます。(理論上は。実際のソフトウェアで「秘密鍵で復号、公開鍵で暗号化」をやってもエラーが出て動かないだろう。少なくともOpenSSL上では動作しなかった。)
実際この考え方を使っているデジタル署名が存在します。それがRSA署名です。
ですが、先ほどのコラムでも言った通りこれが出来るのは一部の公開鍵暗号に限られます。これだけを見て「全ての公開鍵暗号でデジタル署名が作れる」とは言えないでしょう。
Column:RSA暗号なら「秘密鍵で暗号化、公開鍵で復号」出来る!?
本文では全ての公開鍵暗号で鍵をひっくり返して動くことはない、(秘密鍵で暗号化、公開鍵で復号を行うことは出来ない。)と説明しました。
ですが、他の公開鍵暗号で出来なくてもRSA暗号であれば、秘密鍵で暗号化、公開鍵で復号することが出来るという主張を耳にします。
……本当なのでしょうか。それを確かめるために、RSA暗号がどのような仕組みで動いているのか見ていくことにします。
平文を,公開鍵をとします。(正確にはも公開鍵です。)
このとき、次の式を計算することで暗号文を求めることが出来ます。
また、秘密鍵をとします。
このとき次の式を計算することで、暗号文を平文に復号することが出来ます。
なんだか難しそうな数式が出てきました。ですが、今回はこの数式の意味を理解する必要はありません。が公開鍵でが秘密鍵ということが何となく分かれば大丈夫です。
,というのはそれぞれの乗、の乗という意味です。
これだけを見ると、秘密鍵であると公開鍵であるを逆にしても出来そうです。
このようにRSA暗号の式だけを見ると、秘密鍵で暗号化、公開鍵で復号出来そうに思えます。
しかしながら、実際にRSA暗号の処理を行うソフトで秘密鍵で暗号化、公開鍵で復号を行うことは出来ません。
式を見て出来そうなのに、ソフトでは動かないとはどういうことなのでしょうか。というより、本当に動かないのでしょうか。
「OpenSSL」という、公開鍵暗号や共通鍵暗号などの処理を行うことが出来るソフトを使って、実際にやってみましょう。
Gitの連載から来られた方は、GitBash上で下のコマンドを実行することが出来ます。
そうではなく、使用しているOSがWindowsの場合は、追加でOpenSSLをインストールする必要があります。
インストール方法については、下の記事などを参考にしてください。
まず初めに、秘密鍵を作成します。
openssl genrsa 2048 > private_key.pem
このコマンドを実行すると、private_key.pemというファイルが作成されます。名前の通りこのファイルが秘密鍵となります。
続いて公開鍵を作成します。
openssl rsa -pubout < private_key.pem > public_key.pem
秘密鍵の作成と同じく、public_key.pemというファイルが作成されます。
このファイルが公開鍵となります。
暗号化するファイルを作成しておきます。ファイルの名前の通りこれが平文となります。
echo 'Hello!' > plain.txt
作成されたplain.txtを開くと「Hello!」と書かれているはずです。
さて、ここからが本番です。
下のコマンドでは、秘密鍵を使って平文を暗号化しています。暗号化した結果はplain.encryptedというファイルに書き込まれるようになっています。上手くいくでしょうか。
openssl rsautl -encrypt -inkey private_key.pem < plain.txt > plain.encrypted
エラーメッセージが表示されずにコマンドの実行が終了したでしょうか。
また、plain.encryptedというファイルが作成されているでしょう。
cat plain.encrypted
というコマンドを実行すると、plain.encryptedの中身を見ることが出来ます。文字化けしていてよく分かりませんが、「秘密鍵で暗号化」は上手くいったように見えます。
最後に「公開鍵で復号」が出来るかどうか確かめてみます。
復号した結果はplain.decryptedに書き込まれます。復号した結果がplain.txt、つまり平文と一致すれば「公開鍵で復号」出来たことになります。
openssl rsautl -decrypt -pubin -inkey public_key.pem < plain.encrypted > plain.decrypted
上のコマンドを実行してみると、次のようなエラーメッセージが出てしまいました。
A private key is needed for this operation
「この操作には、秘密鍵が必要です」と書かれています。
以上の結果から、(少なくともOpenSSLでは)RSA暗号であっても「秘密鍵で暗号化、公開鍵で復号」出来ないことが分かりました。
実は、OpenSSLの場合秘密鍵のファイルの中に公開鍵の情報が含まれているのです。恐らく、秘密鍵の情報で暗号化を行ったのではなく実際には、公開鍵の情報を使って暗号化したのではないでしょうか。
その証拠に、公開鍵で復号の手順で復号に秘密鍵を使う(-pubinオプションは外す必要がある)と平文に復号されます。(もし秘密鍵で暗号化されたのなら、秘密鍵で暗号化して秘密鍵で復号されたことになってしまう。)
OpenSSLの実装を実際に見たわけではないので推測にすぎませんが。
どちらにせよ、これはOpenSSLだからたまたま動いただけで他のソフトで動く保証はどこにもありません。RSA暗号であっても「秘密鍵で暗号化、公開鍵で復号」は出来ないと言い切った方が無難です。
う-ん、よく分からん!
この記事を読んで、疑問に思うことがあったときは、気軽にコメント欄や私のTwitterから質問してください。(すぐに答えを返せるとは限りませんが。)
参考文献
暗号技術のすべて
この書籍のp.502~p.505で、「よくあるデジタル署名の誤解」について解説されています。
共通鍵暗号・公開鍵暗号・メッセージ認証コード・ハッシュ関数など(シーザー暗号などの古典暗号も解説されている!)まさに「暗号技術のすべて」が詳しく解説されています。
普通、暗号技術がどのような仕組みで動いているのかを、詳しく追おうとすると、どうしても数学の知識が必要になってしまいます。ですが、この書籍では仕組みの理解に必要な数学知識の説明を一緒にやってくれます。
「暗号技術をきっちりと押さえておきたい!」という人にはぴったりの本でしょう。(ただ、約700ページとかなり分量が多いです。最初のうちは興味のあるところから読んでいったほうがいいでしょう。私もまだ読み切れてない……)
「電子署名=『秘密鍵で暗号化』」という良くある誤解の話 など
なぜ「秘密鍵で暗号化」が間違っているのか解説している記事もいくつかあります。
一度目を通しておくといいでしょう。
【gitをソフト開発で使いこなそう!:第9回】ローカルリポジトリとリモートリポジトリ
今回からGitHubの使い方について解説していきます。前回でも話した通り、これが使いこなせるようになると自分のソースコードを全世界に発信出来るようになります。(これ以外にもたくさん機能があります。)
どうやってコードを共有する?
自分で作ったコードを自分だけで管理するなら、今まで(第1回~第8回)やってきた内容で問題ありません。
しかし、自分が作ったコードを他の人と共有したいとしたらどうでしょうか。
また他の人と一緒にコードを編集したいとしたらどうでしょうか。
リモートリポジトリとローカルリポジトリ
これをローカルリポジトリとリモートリポジトリというものを使って解決します。
第1回でも軽く解説しましたが、ここでもう一度用語について解説します。
リポジトリとは、ファイルやファイルの変更履歴をまとめたものを指します。
ローカルリポジトリとは、自分のPC上で管理しているリポジトリのことです。第1回~第8回までこのリポジトリを操作してきました。
リモートリポジトリとは、ネットワーク上で管理しているリポジトリのことです。
厳密に言うとリポジトリは、何らかのデータを保管する場所を指す用語です。
「データの保管場所」という広い意味ですから、gitだけでなく様々な場所でリポジトリという言葉は登場します。先ほど説明した意味はあくまでもgitでのリポジトリを指したものです。
共有する具体的な手順
このリモートリポジトリとローカルリポジトリを使ってgitでは、どのように変更を共有するのでしょうか。
次のような場面を考えてみましょう。
AさんとBさんが同じソフトを一緒に開発しています。
ここで、Aさんがローカルリポジトリに変更を加えたとします。
Aさんはこの変更をリモートリポジトリに反映します。
Bさんは、リモートリポジトリの変更を自分のローカルリポジトリに反映します。
これでAさんの変更がBさんにも共有されました。
何でこんなことするの?
先ほどはリモートリポジトリと、ローカルリポジトリを使って変更をお互いに共有しました。
ですが、ただ共有するだけなら下の図のように、全ての履歴を一つのリポジトリで管理するようにしてもいいのではないでしょうか。
手順もシンプルですし、こちらの手法の方がいい気がします。
ですがこの手法には次のようなデメリットがあります。
- インターネットに接続されていないとコミットやブランチ作成などが出来ない
- リポジトリが一つ壊れるだけで全てのデータが失われてしまう
- 誰か一人の操作が全体に影響を与えてしまう
デメリット1
最初に紹介した方法を使えば、インターネットに接続されていなくてもコミットやブランチ作成などを行うことが出来ます。
インターネットに接続されていない時に行った変更は、後で一気にリモートリポジトリに反映させることが出来ます。
デメリット2
最初に紹介した方法であれば、もしリモートリポジトリが壊れたとしてもローカルリポジトリにデータが残っているため、すぐに復旧することが出来ます。
デメリット3
例えば誰かが手違いで、リポジトリを破壊してしまったとしましょう。(間違ってブランチを消してしまったなど)そうすると、全員そのリポジトリを使っているため全ての人が影響を受けてしまいます。
最初の方法であれば、ローカルリポジトリを操作してからリモートリポジトリに変更を反映するためこのような問題は起きにくくなります。
本文では、最初にローカルリポジトリとリモートリポジトリを使って管理する方法と一つのリポジトリだけを使って管理する方法を紹介しました。
これらの方法には、名前が付いておりそれぞれ分散バージョン管理システム(DVCS),集中バージョン管理システム(CVCS)と呼ばれています。
gitは分散バージョン管理システムですが、Subversionのような集中バージョン管理システムもあります。
GitHubって何だ?
一言で言い切るのは難しいですが、大雑把に言うならソフトウェアのソースコードを公開出来るWebサービスのことです。
ただソースコードを公開するだけなら、GoogleDriveなどのファイル共有サービスを使うだけでも問題ありません。しかしGitHubの場合他の人からのソースコードの編集を受け付けたり、逆に他の人が公開しているソースコードの編集を求める機能などソフトウェア開発に便利な機能がたくさん備わっています。
「GitHub」という名前の通り、gitをソースコードの公開に使うことが出来ます。
上の説明を聞いても「GitHub」が何なのかいまいちピンとこないと思います。実際にGitHubを使うようになればだんだん分かってくるでしょう。
次回予告
次回は、具体的なGitHubの使いかたについて解説していきます。
う-ん、よく分からん!
この記事を読んで、疑問に思うことがあったときは、気軽にコメント欄や私のTwitterから質問してください。(すぐに答えを返せるとは限りませんが。)
参考文献
Pro Git
git,GitHubを使うにあたって必要なコマンドの使い方が詳しく解説されています。この連載を読んで分からないことや詳しく知りたいことがあったときはまずProgitを読んでみるといいでしょう。 git-scm.com
分散型と集中型バージョン管理
分散型バージョン管理と集中型バージョン管理のデメリットとメリットについて書かれています。
【gitをソフト開発で使いこなそう!:第8回】gitを実際の場面で使ってみよう
- 具体的にどうやってgitを使うんだ?
- 実例1:メモ書きを管理する
- 実例2:そんなにソフトの規模が大きくないソースコードを管理する
- 実例3:規模が大きいソフトのソースコードを管理する
- 次回予告
- う-ん、よく分からん!
- 参考文献
具体的にどうやってgitを使うんだ?
これまで7回に渡って、gitの操作方法について説明してきました。
ですが、これだけだと「こういう機能があるのは分かったけど、実際どうやって使うの?」となってしまうかもしれません。
そこで今回は、具体的にどうやってgitを使うのか見ていくことにします。
この連載で見てきたように、gitにはたくさんのコマンドが存在します。使う頻度が低いのも含めれば、数えきれないほどのコマンドがあるでしょう。
当然すべてのコマンドを覚えきるのは不可能ですし、覚えても何か月か経てば忘れてしまいます。
コマンドを忘れた時は、検索して使い方を調べればいいのですが、忘れる度に検索するのは少し面倒です。よく使うコマンドだけでも、一枚の紙にまとまっていれば便利です。
このカンニングペーパーのようなものをチートシートと呼びます。
チートシートはgitだけでなくC#やBlenderなど様々なものに対して作られています。
「いちいち検索するの面倒だな」と思ったら、自分でチートシートを作ってみるのもいいかもしれません。
実例1:メモ書きを管理する
パソコンに保存したメモ書きをgitで管理することを考えてみましょう。
自分用のメモ書きを人に見せることはまずないでしょう。
ですから、ブランチの機能を使わずひたすらコミットしていくだけでいいのではないでしょうか。
これだけでも、
- 間違ってメモ書きを消してしまってもすぐに戻せる
- 変更前のメモ書きに戻したい時にすぐ戻せる
- どこをいつ変更したのかが、すぐに分かる
といったメリットを得ることが出来ます。
実例2と実例3では、ブランチの機能を使う方法を紹介します。
ですが、自分だけで気軽にgitを使いたいのならこういう管理方法もありだと(個人的に)思います。
実例2:そんなにソフトの規模が大きくないソースコードを管理する
今度は、あまりソフトの規模が大きくないソースコードを管理することを考えてみましょう。
先ほどと同じように管理してもいいですが、今回は少し違う形で管理してみましょう。
先ほどの例では、内容に変更を加える時はmasterブランチにコミットしていました。
しかし、今回の例では、developブランチをmasterブランチから新たに作ってそのブランチに変更をコミットします。
機能の追加が終わったら、developブランチをmasterブランチにマージします。
何個かの機能の追加を一緒に進めたい時は、その機能ごとにブランチを作成します。
例えば、「〇ボタンを押すとキャラがジャンプする」という機能と「△ボタンを押すとキャラが自爆する」という機能を一緒に(同時並行で)追加したいとします。
この時二つの機能を一つのブランチで追加しようとせずに、それぞれ別のブランチを作って追加します。
上の例であれば、「jumpChar」と「suicideChar」というブランチをmasterブランチから作成します。
このような運用にすることで、次のようなメリットがあります。
- 機能を追加している途中でも、完成版のソースコードを取ることが出来る
- 今どの機能を追加しているのか、機能の追加はどれくらい進んでいるのかが一目で分かる
実例1の方法でやろうとすると、今ソフトに機能を追加している最中なのか、機能の追加が終わって完成したのかわからなくなってしまいます。(全て1つのブランチで管理しているため。)
また、完成したソースコードを取ってこよう!と思っても、完成したソースコードに既に変更が加えられている場合、取ってくるのは簡単ではありません。(HEADを前のコミットに戻さないといけない。)
今回紹介した方法を使えば、今何をやっている最中なのか一目でわかる上に、masterブランチに移動するだけで機能を追加し終わった(完成版)のソースコードを取ってくることが出来るようになります。
実例3:規模が大きいソフトのソースコードを管理する
実例3では、規模が大きいソフトをgitで管理する方法を考えていきます。
下の図は、実例3で解説する運用方法の表した図です。図の左側にあるmaster、develop…はブランチ名を表しています。
…どうでしょうか。実例2と比べてブランチの数が増えている上に、矢印もいっぱいあってなんだか複雑そうです。
このブランチの管理方法は、git-flowと呼ばれています。(私が考えたものではありません。)
実際複雑なため、これを簡単に行えるようにするgit-flowという専用のツールがあります。(git-flowは管理方法の名前でもあり、ツールの名前でもあります。)
今回の記事では、git-flowの大雑把なやり方のみを紹介します。
詳しい解説やツールの導入について知りたい方は、このページの下にある参考文献をご覧ください。
git-flowは、先ほども言った通り複雑です。
それだけでなくツールの導入も少し癖があり、ある程度慣れていないと難しいでしょう。
まだgitの操作に慣れていないうちは、実例2の方法で管理して、慣れてきたらgit-flowのやり方を少しずつ導入してみるのがいいでしょう。
タイトルの1~7の番号は、図の①~⑦と対応しています。
各ブランチの役割
masterブランチは、公開用のソースコードを指しています。
masterブランチにまだ公開してはいけないもの(まだやりかけの機能追加)はコミットしてはいけません。
developブランチは、開発用のブランチです。
featureブランチは、機能追加用のブランチです。実際の機能追加はこのブランチで行います。
releaseブランチは、ソフトのリリース(公開)の準備のために使うブランチです。
hotfixブランチでは、現在動いているソフトのバグの修正を行います。
1:developブランチを作る
ソフトに新たな機能を追加する時は、まずdevelopブランチを作成します。
2:featureブランチを作る
実例2と同じように、追加したい機能ごとにブランチを作成します。
ここで作成するブランチ名は、「feature」である必要はありません。
3:全てのfeatureブランチをdevelopブランチにマージする
機能の追加が終わったら、追加した内容をdevelopブランチにマージします。
4:developブランチをreleaseブランチにマージする
追加した機能の内容を、releaseブランチにマージします。releaseブランチでは、ソフト公開前の最終調整を行います。
5:releaseブランチをmasterブランチにまとめる
最終調整が済んだら、releaseブランチをmasterブランチにマージします。
6:masterブランチからhotfixブランチを作成する
現在公開中のソフトにバグが見つかって、それを修正したい時は、masterブランチからhotfixブランチを作成します。
実際のバグ修正作業は、hotfixブランチで行います。
7:hotfixブランチをmasterブランチにマージする
修正内容をmasterブランチに反映します。
今回の記事で見てきた「どのようにブランチを管理するのか」を表したものをブランチモデルと呼ぶことがあります。
よく知られているブランチモデルとして、git-flowやGitHubFlowがあります。
興味のある方は、下の参考文献を見てみるといいでしょう。
次回予告
第1回~第8回にかけて、gitのコマンドの使い方について解説してきました。
第9回からは、GitHub上でどのようにgitを使うのか解説していきます。これが出来るようになると、ソフトウェアのソースコードを複数人で共有できるようになります。
う-ん、よく分からん!
この記事を読んで、疑問に思うことがあったときは、気軽にコメント欄や私のTwitterから質問してください。(すぐに答えを返せるとは限りませんが。)
参考文献
Pro Git
git,GitHubを使うにあたって必要なコマンドの使い方が詳しく解説されています。この連載を読んで分からないことや詳しく知りたいことがあったときはまずProgitを読んでみるといいでしょう。 git-scm.com
gitのチートシート
gitでよく使われるコマンドをまとめたチートシートは、以下の記事で公開されています。
qiita.com
ブランチモデル
git-flowとGitHubFlowについて解説されています。
www.atmarkit.co.jp
www.atmarkit.co.jp