この記事を書いた人
machida

こんにちは、町田です。StartupWeekendに参加したり、引越しをしたり、休日はバタバタしていて久しぶりの記事になってしまいました。前回の Github for Mac の記事が好評だったので(たくさんのはてブやTweetありがとうございます!)、今回も Github for Mac を使ったレポートです。

只今 Lokkathon の真っ最中

実はこの記事を書いてる今はLokkathon(ロッカソン)というこのブログでもちょくちょく出てくるRubyで出来たCMS、「Lokka」をみんなで触ろうっていうイベントの真っ只中です。ついさっきひとつのタスクを Github for Mac を使って完了させたのですが、そのときに使ったGithub for Macのレポートを書いておこうと思います。

ちなみに Lokkathon は毎週水曜夜19:00〜からオンラインと東京初台のフィヨルドオフィスで行ってます。オンラインは「LingrのLokkaルーム」で行ってます。お気軽にご参加ください。フィヨルドオフィスの方はLokkaの作者、komagataさんが水曜の21時過ぎにTweetしてるので、そちらを見張っててください。

Github for Mac を使ってGithub にあるリポジトリをローカルにClone

今回はLokkaをいじるっていう作業をするので、Github for Mac を使ってLokkaをローカルに持ってきます。

まずは Github の Lokka のページへ(https://github.com/komagata/lokka)。

Clone in Mac ボタンをクリック。

komagata/lokka - GitHub

すると、このリンクはアプリケーションを起動しますか?と聞かれるので、アプリケーションの起動を選択。

Google Chrome

自分のMacの中のどこの場所に Clone をするかを選択します。僕は「サイト(ターミナルから見るとSitesという名前)」ディレクトリに開発するプロジェクトを置いてるので、そこを選択。

今回は Lokka の「mobile-theme」というブランチに僕が作った「jarvi_mobile(ヤルヴィ モバイル)」というテーマを追加する、という作業をやるので、「Lokka_mobile」という名前でCloneをしました。

GitHub

たった、これだけ。Clone完了!

Github for Mac に Lokka が出てきました。

GitHub

次は、Master以外のブランチに Commit & Sync に挑戦です。

この記事を書いた人
machida

ついさっき、

Dreamweaver

Dreamweaver

Twitter / @jishiha: @machida と思ってお知らせしました。そして僕 ...

ということがありましたので、早速「GitHub for Mac」を使ってみました。@jishihaさんの言うことは正しいので、GitHub for Mac がいいものであることは確かです。

結論を先に言いますが、もし、僕がエンジニアでデザイナーに仕事を依頼するときは、Gitを知らないデザイナーでも、とりあえずMacを使ってるデザイナーに依頼したいと思いました。なぜなら「Github for Mac」があればすぐにGitを使うことが出来るようになるから。ではでは、以下「Github for Mac」のレポートをどうぞ。

GitHub for Macとは

まずは「git」とは?の復習

プログラマーが開発をするときは大体バージョン管理を行うのですが、「git」はそれをするためのバージョン管理システムの一つです。
バージョン管理システムとは、コンピュータ上で作成、編集されるファイルの変更履歴を管理するためのシステムのこと。MacのTime Machineみたいに、プロジェクトを前の状態に戻したりとかをするためのものです。
もしかしたら、この記事を読んでいるデザイナーの中にはSubversionというバージョン管理システムを触ったことがある人もいるかもしれません。まぁ、プログラマーに怒られそうですが、それと同じようなやつです。ただ、gitを使ってる人のほとんどが曰く、「gitの方がいいもの」だそうです(僕もgitに関する知識はこれくらいなので、今のところはここまで)。ちなみにgitの作者はLinuxの作者であるリーナス・トーバルズさんです。

@jishihaさんからgitのわかりやすいメリットの説明をこの記事のコメントでいただきましたので転載。

git と svn の違いは、git の方が格段にブランチが作りやすいなどいろいろあるのですけれど、基本的な使い方だけしていてもわかりやすいメリットは git は .git フォルダひとつだけでレポジトリを管理しているのに対し、svn は .svn は各フォルダごとに作られて散らばっていてうざいというのがあります。
svn 使っていてありがちなのがフォルダを移動してしまうことで、.svn も移動してしまい、おかしなことになってしまい修復するのが面倒というのがあります。git ならレポジトリで管理している一番元となるフォルダ以下の .git さえ触らなければ何の問題もありません。 これひとつだけでも、svn より git を使ったほうが良い理由になると思っています。

「github」とは?の復習も

gitのプロジェクトを置いておくホスティングサービス。プロジェクトのソースコードやそこに使われてる画像ファイルなどを置いておく倉庫のようなものです。webデザイナーなら一度は必ず訪れたことがある「SourceForge.JP」と同じようなものですね。

githubが面白いのは、単なる倉庫として使うだけでなく、githubのユーザーそれぞれが個別のページを持っていて、この人は何を開発しているのかが見れたりすることが出来ます。また、githubに置いてあるプロジェクトを自分のところに持ってきて、元のプロジェクトに手を加えて自分が手を加えたバージョンとして分岐させることも出来たり、その分岐したものを作者に送りつけることも出来ます。

リポジトリの復習も。

バージョン管理をしながらプロジェクトの開発を進めていくにあたって、その内容には実際に作ってるもののファイルの他に、その更新情報も保管する必要があります。例えば、「2月21日にmachidaが画像を追加した」、という情報、「2月23日にkomagataさんがDBの構造を変更した」という情報、「2月24日にmachidaがcssを追加した」という情報、などです。このような更新情報(バージョンと呼びます)をソースコードと一緒に保管することによって、2月24日にmachidaがcssをいじったらサイトのレイアウトが崩れてしまったので、その前のバージョンである、2月23日の状態に戻そう、ということができます。Macをバックアップするアプリ「Time Machine」と同じようなものですね。そのプロジェクトのファイルと更新情報を保管している場所をリポジトリと言います。

…以上、復習でした。

GitHub for Mac は GUI の Git クライアントアプリで、今までさんざんこのKUROIGAMENでやってきた黒い画面(ターミナル)で git コマンドを打つっていうのをターミナルを使わずに、その名の通りボタンをクリックなどをするだけで出来るっていうアプリです。しかも、Github純正で無料。そうそう、 Mac でしか使えません。そこもその名の通り。

インストール

ではでは、早速インストールしてみます。まずはGitHub for Mac へ。

GitHub for Mac

「Download GitHub for Mac」をクリック。

Github

解凍して現れたアイコンをアプリケーションフォルダへ。

Dreamweaver

ちょっと話がそれますが、アイコンを拡大してみると、なんか目が光ってていつもの奥とキャットと違う感じ。

Github

ちなみに、こちらがいつものオクトキャット。こっちのほうが可愛い!

octocat.png (480×480)

セッティング

では、早速起動してみます。まずは、Preferences。

スクリーンショット(2011-07-31 0.38.28).png @ 100% (RGB/8*)

Githubの登録情報を入力。

Preferences

自分のGithubに置いてるプロジェクトが表示されました。

GitHub

これで設定は完了。IDとPASSWORDだけで公開鍵と秘密鍵は不要。なんて楽チン!

リポジトリを作ってみる

まずは、右下の「New Repositry」ボタンを試したいと思います。

GitHub

クリックすると、

  • 「Name」…プロジェクトの名前
  • 「Description」…プロジェクトの説明
  • 「Local Path」…自分のMac内のプロジェクトのファイルが置いてある場所

を入力する画面が表示されました。

GitHub

入力完了。今回は「test-github4mac」というリポジトリを作りました。「test-github4mac」という名前のディレクトリは作りましたが、中身はまだ空です。

「Keep this code private」は、このプロジェクトを他人が見られないようにする場合チェックを入れるのですが、その機能を使うにはGithubの有料プランに加入していないと使えません。今回は別に隠す必要はないのでチェックは外します。

「Local Path」はデフォルトでは「github」というディレクトリを指定されてますが、僕の場合は「Sites」というディレクトリに開発するプロジェクトを入れているので、今回もそこを指定しました(今回のパスは「/Users/machida/Sites/test-github4mac」)。

GitHub

※ ↑ このキャプチャ、ミスってパスが「/Users/machida/Sites/test-github4mac/test-github4mac」になってしまいましたが、ここはスルーしてください

Githubのサイトに行ってみると…

Dreamweaver

「test-github4mac」というリポジトリが作られてました!

Githubにpush

入力後、右下の「Create Repositry」ボタンをクリックすると、「test-github4mac」が出現。

GitHub

「test-github4mac」の右にある矢印をクリックしてみます。

GitHub

「test-github4mac」まだ空だし、まだ一回もコミットをしていないので「No Commits」と表示されてます。

では、空の「test-github4mac」ディレクトリに「index.html」というファイルを置いてみます。

test-github4mac

Github for Mac に戻って、「Changes」タブを開いてみます。すると、「index.html」を追加したことが表示されました。

Dreamweaver

「Collapse All」ボタンをクリックすると、ファイルの内容が確認出来ます。便利!

Dreamweaver

この画面の「Commit summary」の部分に、今回の変更した内容(今回は「index.html」を追加、という変更を行った)を書き入れて、もっと詳しい説明は、「Extended description」に入力。入力が完了したら「Commit Changes」ボタンをクリック。

Dreamweaver

こうなりました。

Dreamweaver

これでコミットは完了。ローカルリポジトリ(自分のMac上のリポジトリ)が更新されました。では、続いてpushしてGithubにあるリモートリポジトリを更新します。

「Github for Mac」の「Branches」タブをクリック。「Publish」ボタンをクリックします。

GitHub

これでpush完了。では、またGithubのサイトに行ってみます。

Dreamweaver

変更が反映されてる!

これはすごく簡単。黒い画面を使わずにちゃんとGitが使えました。Github for Macすごい!

今度はすでにあるリポジトリをクローン、フォーク、別ブランチ作成などに挑戦していきたいと思います。

この記事を書いた人
machida

前回の「おまけ」の部分で説明した、KUROIGAMENを読んでいる方がgithub上でのpull requestを送る練習として作成した「KUROIGAMEN-message-board」リポジトリに、ちょこちょこpull requestをお送りいただきました。ありがとうございます!今後も練習に使ってください(反映にお時間をいただくことがあるかもです、とのときはごめんなさい)。

さて、今回はpull requestを受け取り、それを送ってくれた方のリポジトリの更新部分を自分のリポジトリに取り込む方法。

「git pull」

他人のリポジトリの更新部分を取り込む場合はgitコマンドの「push」の逆、「pull」を使います。

$ git push [pull requestを送ってくれた方のリポジトリ]

…と、「git pull」の引数に「pull requestを送ってくれた方のリポジトリ」を書きます。「git push」をする際は引数に送信する先のリポジトリを書いたので、そのまま逆ですね。例えば、今回「pull request」をいただいた、milligrammeさんのリポジトリを取り込む場合、milligrammeさんの「KUROIGAMEN-message-board」のリポジトリは、

https://github.com/milligramme/KUROIGAMEN-message-board.git

ここにあるので(milligrammeさんのgithub個別ページ内のKUROIGAMEN-message-boardページに書いてあります)、

$ git pull https://github.com/milligramme/KUROIGAMEN-message-board.git

…こう書きます。

すると、ローカルリポジトリの「KUROIGAMEN-message-board」が更新されますので、一応中身を確認して、OKだったら自分のgithubのリポジトリにpush。これで自分の公開しているgithubのリポジトリが更新されました。

こんな感じで最後にpushしたgithubユーザーのiconやcommit内容が表示されます。

こんな感じで最後にpushしたgithubユーザーのiconやcommit内容が表示されます。

この他人のリポジトリの更新部分を自分のリポジトリに取り込むってことを「マージする」と言います。

「merge(マージ)」

wikipediaで見ると、mergeとは「併合する」、「合併する」という意味だそうです。

広義には複数のデータベースやファイル、プログラムなどを一つにまとめる行為を意味する。

…と、書いてありますが、今回のはこれですね。例えば、pull requestを送るときに添えるメッセージに、「XXXXファイルを更新したのでマージしてくださいー」と、書いたりなど。まぁ、「更新を反映させる」って意味で使います。

conflict(コンフリクト)の解消

コンフリクトとは?

さて、ここで他人のリポジトリの更新部分を取り込む際に問題が起こることがあります。ちょっとわかりやすく例をあげてみます。

  1. 1月1日、Aさんがプロジェクト「XXX」のリポジトリをgithubに置いた。
  2. 1月2日、Aさんが「XXX」のindex.htmlを更新。このバージョンをわかりやすく「XXX-ver.1」と呼びます。
  3. 1月2日、BさんがAさんの「XXX-ver.1」をフォーク。
  4. 1月3日、Aさんがプロジェクト「XXX-ver.1」のindex.htmlを更新。このバージョンを「XXX-ver.2」と呼びます。
  5. 1月3日、Bさんが「XXX-ver.1」のindex.htmlを更新。このバージョンを「XXX-ver.1B」と呼ぶ。そして、Aさんにpull requestを送った。

…ってことがあったとします。わかりやすくcacooを使って図を書きました。

わかりやすくcacooを使って図を書きました。

図を見てもらうと、Aさんが作った「XXX-ver.2」と、Bさんが作った「XXX-ver.1B」と、それぞれ別の進化をしたことがわかります(文章の方だと、「4」と「5」)。この枝分かれした進化を次の赤いブロックで統合されることを希望し、Bさんはpull requestを送りました。

Aさんの「XXX-ver.2のindex.html」とBさんの「XXX-ver.1Bのindex.html」、それぞれが同じファイルを更新しています。このとき、マージをしようとすると「おいおい、XXX-ver.2とXXX-ver.1Bのindex.htmlのどっちを採用するんだよ?」と黒い画面が言ってきてマージが出来ずエラーが発生します。このシチュエーションを「conflict(コンフリクト)」と呼びます。コンフリクトとは「衝突」という意味です。

ちょうど「KUROIGAMEN-message-board」でもコンフリクトが起きたので、そのキャプチャを見てみましょう。

コンフリクト

CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

index.htmlにコンフリクトが起きているのでマージに失敗しました、って言ってますね。

では、今回マージに失敗したindex.htmlを見てみましょう。今回のエディタはMacVimを使ってます。

マージに失敗したindex.html

コンフリクトが起きてる部分は、

<li>
<h3>shizaru</h3>
<p>こんにちは。私は全然デザイナーさんじゃないんですけど、KUROIGAMEN愛読してますよ。</p>
<p><a href="http://twitter.com/#!/nushizaru">twitter</a></p>
</li>
<li>
<<<<<<< HEAD
<h3>milligramme</h3>
<p>こんにちわ、新手の投稿方法のメッセージボード、すごく新鮮!</p>
<p><a href="http://twitter.com/#!/milligramme">twitter</a></p>
=======
<h3>ruedap</h3>
<p>こんにちは、こんにちは!</p>
<p><a href="http://twitter.com/#!/ruedap">twitter</a></p>
>>>>>>> d902ef47d2cc9d94604fc8bda478ebff0d2cb2e4
</li>
<li>
<h3>名前</h3>
<p>メッセージ内容。</p>
</li>

…と、出ています。

<<<<<<< HEAD

の部分から、

=======

の部分までと、この部分から

>>>>>>> d902ef47d2cc9d94604fc8bda478ebff0d2cb2e4

の部分まで、この二つのものが出来てしているためにコンフリクトが起こってしまってる、という意味です。今回はどっちかを削除して、どっちかを残す、という選択をするのではなく、両方を取り込みたいので、手動で修正します。

コンフリクトを起こした2つの部分のうちの下の方を

=======
<h3>ruedap</h3>
<p>こんにちは、こんにちは!</p>
<p><a href="http://twitter.com/#!/ruedap">twitter</a></p>
>>>>>>> d902ef47d2cc9d94604fc8bda478ebff0d2cb2e4

こっちに移します。

<li>
<h3>名前</h3>
<p>メッセージ内容。</p>
</li>

<li>
<p>こんにちは、こんにちは!</p>
<p><a href="http://twitter.com/#!/ruedap">twitter</a></p>
</li>

移したら、コンフリクトが起きたときに出てきた、

<<<<<<< HEAD
=======
>>>>>>> d902ef47d2cc9d94604fc8bda478ebff0d2cb2e4

を削除。

<li>
<h3>milligramme</h3>
<p>こんにちわ、新手の投稿方法のメッセージボード、すごく新鮮!</p>
<p><a href="http://twitter.com/#!/milligramme">twitter</a></p>
</li>
<li>
<h3>ruedap</h3>
<p>こんにちは、こんにちは!</p>
<p><a href="http://twitter.com/#!/ruedap">twitter</a></p>
</li>

この状態にしてcommitします。

$ git commit -a -m 'merged ruedap'

今回はruedapさんのcommitをマージしたので「merged ruedap」というメッセージにしました。

ちなみに、どっちか片方を選択するする場合には、採用する方以外を削除して、コンフリクトが起きたときに出てきた「<<<<<<< HEAD」や「=======」などを削除してcommitします。あとは、どっちかを採用する場合は、そういったコマンドで、問答無用で今回マージで受け入れるものを採用する、とか、逆にこっちのリポジトリにあるものを採用するのでconflictを起こした部分のコミットは無視、とかも出来るのですが、これは失敗が怖いので、今のところの僕のレベルでは、毎回目で確認して手動でマージしたいところです。

今回マージしたものは、こちらにあります。引き続き、forkやpull requestの練習に使ってくださいね。では、今回はこの辺で。

そうそう、色々用語が出てきますが、「fork」や「commit」や「マージ」など、英語表記にするか、カタカナ表記にするか迷ってて、今のところめちゃくちゃです。いずれどれかに統一したいとは思ってます。

この記事を書いた人
machida

今回もgithubの使い方。前々回は自分のリポジトリを作るってことをやりましたが、今回は人が作ったものを自分のところにコピーしてきたり、それに手を加えて、元を作った人に「こんな風に変えてみたよ」と知らせたりする、っていう、githubを使ってソースを介したコミュニケーションを楽しむ方法に挑戦したいと思います。

githubにあるリポジトリを自分のリポジトリにfork

新しいgithubの使い方の登場です。「fork」の用語解説は以前にしましたが、今回は実際に「fork」をやってみたいと思います。

まず、githubにある前々回に僕が作った素のHTMLファイル一枚の「KUROIGAMEN-meaasage-board」のリポジトリのページに行きます。

https://github.com/machida/KUROIGAMEN-message-board

次に右上にある「fork」をクリック。

右上にある「fork」をクリック。

すると、githubの自分のページに「KUROIGAMEN-message-board」のリポジトリが作られました。これだけです(もっと何か作業をしたかったですか ? がっかりさせてゴメンナサイ)。

XXXからのフォーク、って出てます。「fork」完了。

今回は普段自分が使ってるgithubアカウント「machida」と、KUROIGAMENの記事を書くようのアカウント「machidanohimitsu」で解説しているのですが、ちょっとわかりずらいですね、ゴメンナサイ。

フォークしたものと、元のリポジトリの場所を確認してみましょう。
ちなみに、リポジトリの拡張子は「.git」です。

元のリポジトリ元のリポジトリ

元のリポジトリの場所は

https://github.com/machida/KUROIGAMEN-message-board.git

forkしたリポジトリforkしたリポジトリ

forkしたリポジトリの場所は

git@github.com:machidanohimitsu/KUROIGAMEN-message-board.git

どちらもリポジトリのファイル名は「KUROIGAMEN-message-board.git」ですが、それぞれ場所が違うことが確認できました。これから、forkしてきた元であるオリジナルの「https://github.com/machida/KUROIGAMEN-message-board.git」ではなく、forkした「git@github.com:machidanohimitsu/KUROIGAMEN-message-board.git」方にpushをして、オリジナルとは別の進化をさせようと、という訳です。別の進化、つまり枝分かれという意味でfork(ナポリタンを食べるときに使うあれです)ですね。

forkしたリポジトリをローカルにcloneする

続いて、githubにforkしたリポジトリが出来たので、今度はそれをローカルに持ってきます。その作業を「clone(クローン)」といいます。複製を作る、という意味ですね。一旦用語をまとめておきましょう。今やっている作業の場合、下記にある「remoteのリポジトリ」はgithubということになります。

  • 「push」…ローカルリポジトリをremoteのリポジトリに送ること
  • 「clone」…remoteのリポジトリをローカルに複製すること

では、早速forkした「KUROIGAMEN-message-board.git」をローカルにcloneしてみましょう。ここでまたgitコマンドの登場です。

git clone

「git clone」のあとの引数に「.git」ファイルを指定します。今回の僕の場合は以下のようになります(「git@github.com:machidanohimitsu/KUROIGAMEN-message-board.git」の部分が人によって変わります)。

$ git clone git@github.com:machidanohimitsu/KUROIGAMEN-message-board.git

git cloneの結果git clone git@github.com:machidanohimitsu/KUROIGAMEN-message-board.gitの結果

うまくいったようなので(相変わらず黒い画面が何にも言ってくれませんが)、Finderで確認をしてみます。

ありました!ありました!

ちゃんとcloneされてました!

cloneしたリポジトリにpushする

では、ただのペライチのHTMLファイルとREADMEだけのこのリポジトリに「css」を追加したいと思います。

「stylesheets」というフォルダを作って、その中に、webデザイナーにはお馴染みのYUIの「reset.css」と、ちょこっとデザインを入れた「basic.css」を追加したいと思います。

このように更新このように更新

上のキャプチャにある状態をcommitして、自分のforkしたリポジトリにpushします。

まずはgit addから

$ git add stylesheets

ディレクトリをgit addしたら、その中身も一緒にaddしてくれます。続いて、commit。

$ git commit -a -m 'added css'

cssを追加しましたよ、というメッセージを添えてcommit。ついでにcssを適用させるためにhtmlもいじったので、変更があったファイルの変更した分も一緒にcommitするために「-a」オプションも忘れずに。

最後にfolkした自分のリポジトリ、「git@github.com:machidanohimitsu/KUROIGAMEN-message-board.git」にpushします。

$ git push git@github.com:machidanohimitsu/KUROIGAMEN-message-board.git

今回の場合、remoteのリポジトリは「git@github.com:machidanohimitsu/KUROIGAMEN-message-board.git」以外にないので、実は「git push」だけでいいのですが、もし今後、何かの開発でremoteリポジトリを複数持つ場合、push先を間違えないように、pushのあとにpush引数にpush先を入れる癖を付けておくと安心。

ひと通りの作業ひと通りの作業

fork元の作者にpull requestを送ってみる

さて、自分のリポジトリの更新には成功しましたが、せっかくcssを足したので、この変更をfork元のリポジトリにも反映させてもらえたら素敵。これこそKUROIGAMENでやっていきたいデザインテロです。

自分のリポジトリの更新した状態を本家にも反映させて、とリクエストを送ることを「pull request」と言います。では、実際にやってみましょう。

まずはfork元のリポジトリのページに行きます。そのページの右上にある「フォーク」ボタンをクリック。

「フォーク」ボタンをクリック。「フォーク」ボタンをクリック。

すると、pull requestに添えるメッセージの入力フォームが表示されます。タイトルと本文が入力出来るのですが、本文には前々回で説明したMardown記法でHTMLを書くことができます。

pull requestに添えるメッセージの入力フォームpull requestに添えるメッセージの入力フォーム

これでpull requestは完了です。

ちなみに、pull requestを受け取った側にはこういった通知が来ます。

pull request

おまけ

前々回と今回でやったgithubの解説で使いましたKUROIGAMEN-meaasage-board」のリポジトリは、ココにあります。forkとpull requestの練習に、こちらをいじってみてください。画像を追加するのも(10M以上とか、あんまり大きすぎるのは勘弁)、cssをいじるのも、HTMLをいじるのもOKです。

この記事を書いた人
machida

前回でgithubを使う準備は整いましたので(アカウント登録、鍵の作成、gitコマンドを使うためにgitをHomebrewでインストール)、今回は実際にgitコマンドをバシバシ使って、gihubのサービスを利用してみたいと思います。

「リポジトリ」を作成。

バージョン管理システムを使う場合、「リポジトリ」という言葉がしょっちゅう出てきます。まずはリポジトリという言葉の意味を調べてみましょう。

リポジトリとは?

バージョン管理をしながらプロジェクトの開発を進めていくにあたって、その内容には実際に作ってるもののファイルの他に、その更新情報も保管する必要があります。例えば、「2月21日にmachidaが画像を追加した」、という情報、「2月23日にkomagataさんがDBの構造を変更した」という情報、「2月24日にmachidaがcssを追加した」という情報、などです。このような更新情報(バージョンと呼びます)をソースコードと一緒に保管することによって、2月24日にmachidaがcssをいじったらサイトのレイアウトが崩れてしまったので、その前のバージョンである、2月23日の状態に戻そう、ということができます。Macをバックアップするアプリ「Time Machine」と同じようなものですね。そのプロジェクトのファイルと更新情報を保管している場所をリポジトリと言います。

githubにリポジトリを作ってみる

では早速、githubにリポジトリを作ってみましょう。

まずは、githubに行って前回作ったアカウントでログインをします。

「新しいリポジトリ」ボタンをクリック。

「新しいリポジトリ」ボタンをクリック。

「プロジェクト名」、「説明」、「ホームページのURL」を入力します(「説明」、「ホームページのURL」はオプションなので入力しなくてもOK)。今回は、「KUROIGAMEN-msessage-board」という素のHTMLファイル一枚だけのプロジェクトを作成する予定です。入力が終わったら「リポジトリを作る」ボタンをクリック。

「リポジトリを作る」ボタンをクリック。

すると、次に行う手順が表示されます。

次に行う手順が表示されます。

ここにも表示された手順をコピペしておきます。

全体設定

ダウンロードおよびインストール Git

git config --global user.name "Your Name"
git config --global user.email machidanohimitsu@gmail.com

次の手順:

mkdir KUROIGAMEN-massage-board
cd KUROIGAMEN-massage-board
git init
touch README
git add README
git commit -m 'first commit'
git remote add origin git@github.com:machidanohimitsu/KUROIGAMEN-massage-board.git
git push origin master

この後に出てくる、「すでにGitが…」と、「Subversionのリポジトリを…」は今回は関係ないのでカットしました。

「全体設定」のはじめにある、「ダウンロードおよびインストール Git」は前回Homebrewでgitをインストールしてるので大丈夫ですね。

「git cofig」

続いて、「git」というコマンドに「config」という引数を付けたコマンドが二回続きますが、こちらは個人の識別情報を登録するコマンドです。このコマンドであなたの名前とメアドを登録することによって、今後のgitを使って更新を行う際、この更新はあなたが行った更新、ということが更新内容とともに記録され、リポジトリに蓄積されていきます。

ちなみに、「~/.gitconfig」を覗いてみると、「git config」で設定した内容が書きこまれているのを確認することができます。今回は「open」コマンドを使って確認してみましょう。

open ~/.gitconfig

出た!ちゃんと書いてある。open ~/.gitconfig

「mkdir」

「次の手順」はなんかたくさんコマンドが出てますが、一つ一つそのまま打っていくだけで手順が完了します。でも、せっかくのgithubを触った最初のこの機会なので一つ一つのコマンドを見ていきましょう。

mkdir KUROIGAMEN-massage-board

「mkdir」はずっと前にやったので問題なしですね。一応、「KUROIGAMEN-massage-board」というフォルダを作るという意味。

「cd」

cd KUROIGAMEN-massage-board

「cd」もずっと前にやりました。ディレクトリ「KUROIGAMEN-massage-board」に移動するという意味

「git init」

git init

またもや「git」コマンドが出てきました。これは「gitリポジトリを作成する」というコマンドです。初めてここで「git init」コマンドを打ったことによって、「KUROIGAMEN-massage-board」というディレクトリの中身は、「git」で管理されたプロジェクトのリポジトリになったのです。これは今後も覚えておいたほうがよさそうなコマンド。

「touch」

touch README

「touch」、これも前にやりましたね。「README」という空ファイルを作る、というコマンドです。

git add README

またまた「git」コマンドの登場。さっきやった「git init」というコマンドを打っても、実はまだリポジトリにファイルもフォルダも登録してない状態です。ここで「git add」というコマンドを使い、gitのリポジトリにファイルやフォルダを追加させます。「add」は「足す」という意味なので、リポジトリに「README」ファイルを足す、というコマンドです。これで、「KUROIGAMEN-massage-board」リポジトリに「README」ファイルが追加されました。このコマンドはこれから何回も使います。

「git commit」

git commit -m 'first commit'

また「git」コマンド。今度は「git commit」です。

バージョン管理システムには「コミット」という言葉が必ず出てくるのですが、今使っている「git」の場合はローカルのリポジトリを更新する、今のリポジトリの状態をバージョンとして保存する、という意味です(これが別のバージョン管理システムの「Subversion」だとまた意味が変わってきますが、それはカットで)。ここは後で説明する「push」と合わせて見たほうがわかりやすいので、「push」のときにもう一度一緒に確認しましょう。

コマンドのあとに「-m」オプションが付いてますね。このオプションはメッセージを添える、というオプションです。今のリポジトリを保存する、という意味の「git commit」ですが、その保存をするときに「何をしたのか」、というメッセージを書いておくと、あとでバージョンを戻すときなんかに、このバージョンまで戻すとどうなるか、というのがわかりやすくなります。今回の場合は「first commit」、「最初のコミットですよ」というメッセージを添えてコミットされてますが、今後デザイナーは「added images」とか「fixed reset.css」なんていうコミットメッセージを書いていくことになります(別に日本語でもいいのですが、英語だと格好いい)。

で、一応「git commit -m 'first commit'」をまとめると、「git add」で「README」というファイルをリポジトリに追加しましたが、空だったリポジトリから「README」を追加したその状態のバージョンを「first commit」というメッセージを添えて作成した、というコマンドになります。

「git remote add origin」

git remote add origin git@github.com:machidanohimitsu/KUROIGAMEN-massage-board.git

はい、また「git」コマンドです。「git」はとても高機能なものらしくて、プログラマーさんでも全ての「git」の機能を把握している人は少ないってくらいだそうです。全てを知らなくても使っていけるものなので怖がらなくて大丈夫。

「remote」とは、物理的に離れててネットワークなどで繋がっている別のコンピューター(環境)という意味で、オリジン弁当でお馴染みの「origin」は言葉、「源」、「元」という意味です。「add」は「足す」ですね。「git@github.com:machidanohimitsu/KUROIGAMEN-massage-board.git」はgithub上に用意されたこのリポジトリを置く場所です。

「git」で作業をしていくときは、ローカルリポジトリを更新して、これでOKという状態になったら、外の場所(今回はgithub)に置かれたリポジトリに、更新されたローカルリポジトリの状態を反映させます。つまり、外に置かれたリポジトリがプロジェクトの「源」になっている訳で、それをローカルに持ってきて、ローカルでいじって、また源に戻す、という作業の繰り返しです。

「remote」ローカルの外にある「git@github.com:machidanohimitsu/KUROIGAMEN-massage-board.git」をプロジェクトの「origin」源として「add」登録(追加)します、というコマンドになります。このコマンドを打つことによって、次に説明する「git push」というコマンドを打ってローカルリポジトリの状態を外に反映させる先が「git@github.com:machidanohimitsu/KUROIGAMEN-massage-board.git」になる、と設定されます。

「git push」

git push origin master

最後のコマンドもgitコマンド。先程ちょこっと触れた「git push」の登場です。「git push」は、ローカルリポジトリの更新された状態を外に反映させる、というコマンドです。「git push」で「orign master」にローカルリポジトリの内容を反映させる、という意味。先程、「git@github.com:machidanohimitsu/KUROIGAMEN-massage-board.git」 を「orign master」として登録しましたから、「git@github.com:machidanohimitsu/KUROIGAMEN-massage-board.git」に、空だったリポジトリから「README」ファイルを追加したローカルリポジトリの状態を反映する、というコマンドになります。

これで無事にgithubに自分のプロジェクトのリポジトリを作ることが出来ました。では、実際にgituhubを使って具体的にどのように作業を進めるかについて説明しておきたいと思います。

  1. githubにリポジトリを作る
  2. READMEファイルを作ったものcommitしてpushする(さっきまでやってた作業)。
  3. ローカルリポジトリをいじる(HTMLをいじったり、cssを変えたり、画像を追加したりなど)
  4. きりのいいところでローカルリポジトリを更新する(commit)
  5. 3~4の作業をループする。
  6. そろそろ第三者に見られてもいいかなぁ、という状態になったら、githubにpushする

…という感じです。

では、「KUROIGAMEN-massage-board」というgithubに登録したリポジトリを更新してみます。

フォルダ「KUROIGAMEN-massage-board」内にindex.htmlというHTMLファイルを作りました。

この状態から…この状態から…

index.htmlを追加!index.htmlを追加!

フォルダにファイルを追加しても、まだ「index.html」はバージョン管理の中には追加されていません。ファイル「index.html」を「git add」して、gitのバージョン管理に追加します。

git add index.html

これで「index.html」もバージョン管理の中に追加されました。

次に、この状態(index.htmlが追加された状態)をcommitします。「added index.html」というメッセージも添えておきましょう。それと、これが大事なのですが、commitをする際に「-a」というオプションを付けます。これを付けることによって、前回のcommitから変更されたファイルを勝手に探して、その変更部分もcommitしてくれます。

git commit -a -m 'added index.html'

githubにpushします。

git push origin master

これでgithub上のリポジトリが更新されました。

今回はただのHTMLファイルを置いただけだったので、「だから何?」って思ったかもしれませんが、自作のwordpressのthemeをgithubで公開して、自分のブログで自作テーマのダウンロードはこちら、なんていうリンクを置いたりなど、デザイナーもgithubで自作のものを置いてみんなに「ここにあるよ」って教えると、もっと自作をする楽しみは増えるんじゃないかなぁ、と思います。僕は自分以外のデザイナーがどんなものを作ってるのか見たくて仕方ないです。なので、何かを作ってgithubにpushしたら教えてくださいね。

READMEファイルの編集

さて、githubをうろうろしてあなたの作ったリポジトリにたどり着いた人が、「このリポジトリはなんなのか」をわかりやすくしておかないと、人も使ってくれないです。でも、リポジトリを作成したときに登録をした情報は、「リポジトリ名」と「説明(一行の)」と「URL」だけ。これじゃどんなものが置いてあるリポジトリだかよくわかないですよね。とそこでそういったものを書きこむのが「README」ファイルです。

html5-media-chaptersというリポジトリを見てみましょう。

README

リポジトリページのトップの下の方に「README」ファイルの中身が表示されてます。これはgithubの便利機能で、READMEファイルの中身が自動的にこのように表示されるようになってます。しかも、READMEファイルにHTMLも使えて、ちゃんとgithubのここに表示される際にはデザインが入ります。これは、デザイナーとしては、ここの部分もちゃんと書いて綺麗に見せたいところですよね。

ただし、READMEでHTMLを使うにはちょっとだけ手間がかかるので、その方法も紹介しておきたいと思います。

READMEファイルでHTMLを使う

まずは、READMEファイルをエディタで開きます。そのときに、「UTF-8」で保存しないと文字化けしてしまうため、ちゃんとそれを指定できるエディタで編集してください。今回は「CotEditor」を使ってみます。

今回は「CotEditor」を使ってみます。

さて、開いた全くの白紙の状態です。ここにHTMLを使って説明を書き入れていきますが、ここで書くHTMLが普通のHTMLではなくて、Markdown記法というものを使って書きます。他にもRDocというものを使っているのもたくさん見るのですが、今回はMarkdownの方で。

html5-media-chaptersというリポジトリのREADMEファイルを見てみましょう。

# HTML5 Media Chapters [http://tonycamp.com/html5-media-chapters/](http://tonycamp.com/html5-media-chapters/)
(Currently only working in Chrome browser)

## Summary:

The beginnings of a jQuery plugin that will allow you to time stamp an element, attach an event handler to it which will load an audio file, and jump to the specified time stamp.

I chose to use the yayQuery podcasts as a demo because they taught me so much. Learn, and share. Thanks Rebecca Murphey, Adam Sontag, Alex Slexton, Paul Irish. Follow these people on github and twitter. You will learn a ton.

## How To Use

Give the element that will handle the click event a data-filname attribute which will serve as the filename to load into the audio player. For this attribute, you don't include the file extension. The extension defaults to .mp3, but can be changed. For example:

<span class="episode_title" data-filename="yayquery_0">Episode 0</span>

Now that you have your click handler and file to load, you need to add a chapter to the audio file. For that you need to add a data-timestamp attribute to the click handler for the chapter. For example:

<a href="#" class="loader" data-timestamp="2:45">_js Library</a>

This example would jump the yayquery_0.mp3 file to the 2 minute 45 second mark and start playing from there.

Next you need to call the new plugin on the click handler. It can be basic like so (uses default values for file type, directory and element classes):

$('.episode_title').mediaChapter();

By default, the plugin will look for HTML5 audio players with a class of "audio", this can be overwritten by specifying a class of your choice like so:

$('.episode_title').mediaChapter({
audioElement: $('.myaudio') // this is your audio class, name it whatever you like
});

Here are some more customizable variables you can use to suit your needs:

audioElement: $('.audio'), // Audio player that will load the audio file

audioChapter: $('.loader'), // Element that will have the data-timestamp for the chapter
audioDirectory: 'mp3' // Directory where audio files live

## Changelog:

### v.1.0 : January 3rd, 2011

#### General
* Very first commit. Still rough, but eff it.

全然HTMLのかけらもないように見えますが、これがMarkdownという記法で書かれたHTMLです。HTMLの書き方を変えただけなので、何も難しいことはありません。ここによく使うHTMLのタグを書いておきます。あとはこちらを見るともっと詳しく色々書いてあります。

見出し(h1〜h6)

# This is an H1

## This is an H2

###### This is an H6

段落(p)

空白行に囲まれた複数行の文章(一行の場合も含む)がまとめて一つの段落として扱われます。スペースやタブだけの行も空白行に含まれます。) 通常段落の行頭にスペースやタブがあってはいけません。

改行(br)

その行の末尾を二つ以上のスペースを記述してから改行する。

引用(blockqute)

> This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,
consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus.
Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus.

> Donec sit amet nisl. Aliquam semper ipsum sit amet velit. Suspendisse
id sem consectetuer libero luctus adipiscing.

リスト(ul li)

*   Red
* Green
* Blue

番号付きリスト(ol li)

1.  Bird
2. McHale
3. Parish

ソースコードを表現(pre code)

単純に各行の冒頭に4つ以上のスペースもしくは1つ以上のタブを挿入。

    This is a code block.

リンク(a)

This is [an example](http://example.com/ "Title") inline link.

[This link](http://example.net/) has no title attribute.

↓ こうなる。

<p>This is <a href="http://example.com/" title="Title">
an example</a> inline link.</p>

<p><a href="http://example.net/">This link</a> has no
title attribute.</p>

blog::2310より一部を抜粋

ただ、htmlを置き換えるだけなので、全然難しくないですね。メールのような感じでHTMLが書けるので、慣れればHTMLを書くより早く書けるかも。では、実際に「KUROIGAMEN-massage-board」のREADMEを書いてみたいとおもいます。

# KUROIGAMEN message board
## これ何?

これはhttp://kuroigamen.comを読んだ人が好きにメッセージを書いていくものです。
いまのところHTML一枚だけです。

## 書き込む手順

1. KUROIGAMEN-message-boardをフォークする
2. 手を加える
3. pull requestを送る

## 作った人

町田哲平(KUROIGAMEN FJORD,LLC)
Copyright (c) 2011 KUROIGAMEN.

こんな感じで書きました(おもいっきり日本語で)。次に、READMEファイルが今のところ何も拡張子がない状態ですが、それに「.md」もしくは「.markdown」を付けます。これで、「これはMarkdownで書かれたファイルですよ」というのがgithubにも伝わるので、github上の「KUROIGAMEN-massage-board」のリポジトリのページにHTMLが適用されたREADMEが表示されるはず。

gitでは、拡張子を変えたり、ファイル名、ディレクトリ名を変えると別なファイルとして認識するので、「README.md」をaddします。

git add README.md

では、commitしてpushしましょう。

git commit -a -m 'added README.md'
git push origin master

では、githubに反映されているか確認。

githubに反映された!githubに反映されているか確認。

では、今回はこれで終わり。デザイナーの皆さんもガシガシgithubにリポジトリを置いて、置いたら僕に教えてくださいね!

この記事を書いた人
machida

今回はプログラマーにとってはもう必須なサービス、「gituhub」に我々デザイナーも挑戦していこうと思います。このサイトのヘッダーにある、「デザイナーもforkしたりpull request送ったり」というサブタイトルがありますが、この「fork」も「pull request」も実は「github」でよく使う用語です。

一応、今のところKUROIGAMENではgithubに置いてあるオープンソースにデザインを入れて作者に送りつける、っていうのを目標にしていて、とりあえずはそれが出来るようになるまでの記事を書いていく予定です。今回でgithubが使える設定が完了して、次回は実際にgithubを使ってみて、それからgithubにあるRubyのアプリをローカルで動かせるようになって…ってところまで頑張ろうと思います。

まずは「git(ギット)」について

「git」とは?

プログラマーが開発をするときは大体バージョン管理を行うのですが、「git」はそれをするためのバージョン管理システムの一つです。
バージョン管理システムとは、コンピュータ上で作成、編集されるファイルの変更履歴を管理するためのシステムのこと。MacのTime Machineみたいに、プロジェクトを前の状態に戻したりとかをするためのものです。
もしかしたら、この記事を読んでいるデザイナーの中にはSubversionというバージョン管理システムを触ったことがある人もいるかもしれません。まぁ、プログラマーに怒られそうですが、それと同じようなやつです。ただ、gitを使ってる人のほとんどが曰く、「gitの方がいいもの」だそうです(僕もgitに関する知識はこれくらいなので、今のところはここまで)。ちなみにgitの作者はLinuxの作者であるリーナス・トーバルズさんです。

「git」をインストール。

色々説明を聞いても実際にgitを使うまではいまいちどんなものかはわかりづらいと思います。やればわかりますので心配しなくて大丈夫。とりあえずHomebrewでgitをインストールしてgitが使える環境を作ってみましょう。

$ brew install git

これでgitコマンドが使えるようになりました。実際に使うのはもう少し先(次回までお待ちください)。今回のテーマは「git のプロジェクトホスティングサービス gituhub に挑戦(準備編)」なので、「git」を使う前に「github」について調べておこうと思います。

「github(ギットハブ)」について

「github」とは?

gitのプロジェクトを置いておくホスティングサービス。プロジェクトのソースコードやそこに使われてる画像ファイルなどを置いておく倉庫のようなものです。webデザイナーなら一度は必ず訪れたことがある「SourceForge.JP」と同じようなものですね。

githubが面白いのは、単なる倉庫として使うだけでなく、githubのユーザーそれぞれが個別のページを持っていて、この人は何を開発しているのかが見れたりすることが出来ます。また、githubに置いてあるプロジェクトを自分のところに持ってきて、元のプロジェクトに手を加えて自分が手を加えたバージョンとして分岐させることも出来たり、その分岐したものを作者に送りつけることも出来ます。

用語から見る、「github」って何が出来る?

  • 「フォロー」

    気になるユーザーが今github上でどんな活動をしているのかをウォッチする機能を「フォロー」と言います。twitterと同じですね。相互フォローを要求してくる人は多分githubにはいないのでご安心ください。

  • 「ウォッチ」

    フォローと同じように、気になるプロジェクトをウォッチする機能もあります(誰がこのプロジェクトをforkしたのか、誰がpushしたのか、誰がプロジェクトのissueに書き込んだのか…など)。こっちはそのまま「ウォッチ」と言います。

  • 「issue(イシュー)」

    プロジェクトのtodoリスト機能を「issue」と呼びます(githubを日本語表示にすると「課題」と出るのですが、みんな訳される前の「issue」と呼んでます)。issueを使ってバグ報告をしたり、今後の開発部分と内容を書いたり、作業が完了したことを報告したりにも使えます。

  • 「push(プッシュ)」

    自分のコンピューター上(ローカル環境)で開発したものをgithubに置くことを「push」と言います。「push」はgitの用語なので、githubに関わらず「git」を使って自分で作ってたものを外のどこかに置くことを「push」と言います。

  • 「fork(フォーク)」

    githubに置いてあるプロジェクトを自分のところに持ってきて、元のプロジェクトに手を加えて自分が手を加えたバージョンとして分岐させることを「fork」と言います。

  • 「pull request(プルリクエスト)」

    folkして手を加えた自分のバージョンをfolk元の作者に「ここをこういう風に変えたから本家に取り込んでよ」とメッセージを送ることを「pull request」と呼びます。

このサイトのヘッダーにある、「デザイナーもfolkしたりpull request送ったり」というサブタイトルのイメージが湧いてきたでしょうか?

githubに登録。

では、githubのユーザーになるために登録をしましょう。登録はこちらの新規登録(日本語表示で解説してます)から。

これをクリックこれをクリック

色々な種類のアカウントが表示されますが、一番上の無料アカウントでOKです。

無料アカウントはこれ無料アカウントはこれ

POINT!

githubには「無料アカウント」の他に、「Micro」、「Small 」、「Medium」という有料アカウント、さらにビジネス用に組織で使える「Bronze」、「Silver」、「Gold」という有料ビジネスプランもあります。

有料と無料、どちらも「公開リポジトリ 無制限」、「公開協力者 無制限」という条件は変わりません。非公開で特定の人しか見れないリポジトリを作る場合のみ、作れる数や、共同でそれを開発できるメンバーの数がアカウントの種類によって異なります。
また、ビジネスプランは個人だけでなく、組織としてのアカウントを作成することが出来ます。まぁ、仕事で使うんじゃなければ公開してしまっても全然問題はないので、無料でOKですね。

これでアカウントが出来ましたが、もう一つ、厄介な作業があります。「公開鍵と秘密鍵」を作成し、「公開鍵」をgithubに登録です。これをやらないとgithubでpushをすることが出来ないのでこの作業は必須なのですが、ちょっと手順が長いので、その説明をする前に一発タイトルタグを入れておきます。

「公開鍵」と「秘密鍵」

はい、タイトルが入りました。では、「公開鍵と秘密鍵」を作成し、「公開鍵」をgithubに登録する、の手順を説明していきます。鍵の説明については下のほうでやってますので、とりあえず作業を進めていきましょう。

「公開鍵」と「秘密鍵」の作成。

まずは、以前にここで紹介しました「TinkerTook」を使って隠しファイルを見えるようにする設定を行います。

すいません、この部分書き直しました(2011年1月10日)

まずは黒い画面を呼び出します。以下のコマンドを打ってください。

$ ssh-keygen

これは鍵を作成するためのコマンドです。これを打つと、

Enter file in which to save the key (/Users/machida/.ssh/id_rsa): 

と、表示されます。「この場所に鍵を作っていいの?」と黒い画面が聞いてます。「enter」キーを押してください(machidaの部分はあなたのユーザー名が入ります)。

今度は、

Enter passphrase (empty for no passphrase):

…と、パスフレーズを聞いてきます。ここは「sudo」でも使ったMacにログインするときに入れるパスワードを入力してください。

Enter same passphrase again:

もう一回入れて、って言ってくるので、もう一度入力。

以上で「公開鍵」と「秘密鍵」の作成は完了。もっと何か作業をしたかったですか ? がっかりさせてゴメンナサイ。これだけです !

「公開鍵」と「秘密鍵」の作成の一連の流れもっと何か作業をしたかったですか ? がっかりさせてゴメンナサイ。これだけです !

最後にgithubに戻り、右上にある「アカウントの設定」をクリック。

「アカウントの設定」をクリック「アカウントの設定」をクリック

そして「SSH公開鍵」タブを開き、「別の公開鍵の追加」をクリック。ここに「id_rsa.pub」の中身を丸々コピペ。

ここに「id_rsa.pub」の中身を丸々コピペ。

以上で「公開鍵と秘密鍵」を作成し、「公開鍵」をgithubに登録の作業は完了。では、「ところでこれって何なの?」の説明に入ります。

「公開鍵」と「秘密鍵」とは?

「id_rsa」の方を秘密鍵、「id_rsa.pub」を公開鍵と呼びます。この二つの鍵はペアで使うものなのですが、公開鍵の方は誰にでも知らせて構わないのですが、秘密鍵の方は絶対に他人の手には渡らせてはいけません。なので、秘密鍵はweb上に置いたりしてはいけません。

黒い画面とgithubを連動させて使います。よくwebデザイナーの皆さんが使ってるFTPのようにファイルを送ったりするのですが、githubの場合、黒い画面からgitコマンドを使ってgithubにファイル送信などを行います。そのときに、自分のアカウントに登録した公開鍵と対になる秘密鍵が自分のコンピューターにあることで、「あなたはmachida本人ですね」、とgithubが認識し、machidaのgithubのリポジトリにファイルを送信することが出来るのです。FTPの場合、ユーザー名やパスワードを入れますが、それの代わりになるのが「公開鍵」と「秘密鍵」です。パスワードを入力するのと違って、こちらの場合は鍵のファイルを持っているだけでいいのです。秘密鍵が誰かの手に渡ってしまったら、その人がmachidaのなりすましをすることが出来てしまうので、秘密鍵は他人の手には渡らせてはいけない、という訳です。

まぁ、一回上記の作業をしてしまったら、今後はあんまり鍵について意識することもなくgithubが使えるのでなんだかよくわかんねぇなぁ、って方も安心してください。コンピューターを新しく買った場合なんかは注意です。古いほうのマシンを初期化する前に鍵をちゃんと新しいマシンに移しておきましょう。

それと、鍵自体の仕組みの話は飛ばしてしまいましたが、気になる方はRSA暗号でググるのがおすすめ。

次回はいよいよ実際にgithubを使う方に挑戦します。

最新の実績

  • Remember The Wordpress
  • happy1000days
  • happy1000days
  • happy1000days

こちらも合わせてどうぞ

  • webデザイナーの為の「本当は怖くない」“黒い画面”入門

アフィリエイト