今日からはじめるGitHub ～ 初心者がGitをインストールして、プルリクできるようになるまでを解説

GitやGitHubという言葉を聞いたことはあるでしょう。GitとGitHubは、それぞれ指し示すものが違います。まずは、GitとGitHubがそれぞれ何なのかを簡単に説明しましょう。

Gitは、分散型バージョン管理システムの名称です。このあと解説しますが、GitはローカルのPCで編集作業を行い、ファイルの修正履歴も管理できます。

Gitgit-scm.com

ソフトウェアのバージョン管理システムとして、以前はCVSやSubversionがよく使われていましたが、いまではGitが採用される場合が多いでしょう。

一方、GitHubは、Gitを用いたソフトウェア開発プロジェクトのための共有ウェブサービスの名称です。

How people build software · GitHubgithub.com

Gitでソースコードを管理するだけでなく、GitHub上でレビューをしたり、他のメンバーとコラボレーションしたりすることで、 Gitの真の力が発揮されるでしょう。

Gitはシステム、GitHubはGitを用いたサービス。混同しないようにしましょう。

Gitではローカルで開発を進めることができる

Gitの特徴を簡単にまとめると、次のようになります。

• ローカルで作業ができる
• 同じ情報を持ったリポジトリ（バージョン管理対象のファイル群）を、開発者ごとに持つことができる

CVSやSubversionでは、いつでも全員が共有するリポジトリに対し修正内容を反映（コミット）します（集中型）。そのため、気をつけないとコミットの際に開発中の不完全なソースコード、実験的なソースコードが共有されてしまう危険性があります。

集中型のバージョン管理システムの危険性

一方、 分散型のGitであれば、ローカルのPC上でコミットができます。手元でコミットを続けたのち、任意のタイミングでプッシュできます。そのため、開発途中のソースコードがいきなり共有しているメンバー全員に影響を与える心配がありません。

分散型のGitではローカルで開発してマージできる

例えるならば、CVSやSubversionのときは公開済みのブログを推敲しなければならなかったものが、Gitになれば非公開の下書き状態で推敲できるようになった、というイメージです。

Gitの基礎用語

Gitを扱う上で、押さえておきたい用語をまとめます。

GitHubでは公開ソフトウェアに修正提案できる

GitHubの最大の特徴は、ソースコードを通じて他の開発者とコミュニケーションがとれることです。GitHub上には、数多くのソースコードが公開されています。それらに修正依頼することはもちろん、自らが修正したソースの提案も可能です。

OSSとして公開されているソースコードで気になる点がある場合、これまでの流れを確認しつつソースコードを修正し、プルリクエスト（pull request）を出すことにより、OSSに自分の修正が取り込まれることもあります。そのため、GitHubにより、OSSにも参加しやすくなりました。

他の開発者のソースコードを見るだけでなく、自分の成果物も公開できます。レビューの内容も含めて公開し、フィードバックを受けることに価値があるといえるでしょう。エンジニア採用では、GitHubのアカウントを伝え、自分のソースコードを見てもらうこともあります。

コミュニケーション以外にも、バグや改善要望をイシュー（issue）として管理する、開発者ごとの活動状況を表示する（「芝を生やす」ということもあります）など、開発時に便利な機能がそろっています。

Gitの真の力を発揮するために、GitHubは欠かせない存在です。

GitHubの基礎用語

GitHubの基本用語も押さえておきましょう。

環境の構築（1） ローカル環境でGitを使えるようにする

Git/GitHubを使うためには、ローカル環境でのGitの構築と、リモートのGitHubアカウントの用意が必要です。

まず、Gitをローカル環境で使えるように準備します。

Gitのインストールと準備

Gitコマンドを使えるようにしましょう。次の手順で、Gitをインストールします。

• Windowsの場合
  • Git for Windows（git-for-windows.github.io）からGit for Windowsをダウンロードし、インストールします。
• Macの場合
  • OS XにはGitが付属しています。
    もしインストールされていなかったり、より新しいバージョンのGitを利用する場合は、（前述の公式サイトから）別途インストールします。

インストールできたら、Gitコマンドを操作するコマンドライン環境を準備します。

• Windowsの場合
  • Gitコマンド付属のGit Bashを開きます。
• Macの場合
  • ターミナルを開きます。

Gitコマンドが実行できることを確認する

コマンドライン環境でgit --versionと入力し、Gitのバージョンが表示されることを確認します。

$ git --version
git version 2.10.1 (Apple Git-78)

MacでXcodeをインストールしていてライセンスに同意していない場合、以下のようなレスポンスになる場合があります。

$ git --version
        
Agreeing to the Xcode/iOS license requires admin privileges, please re-run as root via sudo.

この場合はsudoで実行し、ライセンスに同意します。

$ sudo git --version
Password:
        
        
You have not agreed to the Xcode license agreements. You must agree to both license agreements below in order to use Xcode.
        
Hit the Enter key to view the license agreements at '/Applications/Xcode.app/Contents/Resources/English.lproj/License.rtf'

Apple Inc.
        
Xcode and Apple SDKs Agreement
        
PLEASE SCROLL DOWN AND ...
...(snip)...
Software License Agreements Press 'space' for more, or 'q' to quit

q

By typing 'agree' you are agreeing to the terms of the software license agreements. Type 'print' to print them or anything else to cancel, [agree, print, cancel] 

agree

You can view the license agreements in Xcode's About Box, or at /Applications/Xcode.app/Contents/Resources/English.lproj/License.rtf
        
git version 2.10.1 (Apple Git-78)

ユーザー名とメールアドレスを設定する

Git上で使いたい情報を入力します。下記のコマンドで【ユーザー名】と【メールアドレス】の部分を、自分の情報に置き換えてください。

$ git config --global user.name "【ユーザー名】"
$ git config --global user.email 【メールアドレス】

以下のコマンドで設定を確認できます。

$ git config --list
user.name=【ユーザー名】
user.email=【メールアドレス】
...

環境の構築（2） SSHの鍵を取得する

次に、リモートのリポジトリとやり取りするため、SSHの鍵を用意します。鍵の生成は、GitHubのヘルプでも説明されています。

ssh-keygenコマンドで鍵を生成する

WindowsであればGit Bash、Macではターミナルを開いて、以下の手順で鍵を作成しましょう。

$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

• -tオプションで、鍵のタイプを指定しています。
• -bオプションで、鍵の長さを指定しています。鍵が短いとセキュリティ的に危険です。
  ssh-keygenのデフォルト値2,048ビットのまま生成・利用される場合も多いのですが、GitHubの推奨は4,096ビット。より安全性の高い値を利用します。
• -Cオプションで、鍵にコメントを付加できます。なくても問題ありません。
  複数の鍵を管理するときは、何の鍵なのかを分かりやすくするため、コメントを有効的に利用しましょう。

鍵の生成場所とファイル名を確認する

上記のssh-keygenコマンドを入力すると、生成される鍵のファイル名と出力場所を確認するメッセージが表示されます（※ここで示すファイルのパスはMacの例です。Windowsでは適宜読み替えてください）。

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

「id_rsa」というファイル名のままでよければ、そのままEnterを押します。今回は、複数の鍵管理を想定し、この鍵がGitHub用であることが分かるよう、ファイル名を変更します。

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

パスフレーズを入力する

次に、パスフレーズを入力します。

空のまま生成することもできますが、セキュリティ面を考えてパスフレーズを指定しておきましょう。GitHubのヘルプでもパスフレーズの利用を推奨しています。

Enter passphrase (empty for no passphrase): 【パスフレーズを入力。画面には表示されません】
Enter same passphrase again: 【パスフレーズを入力。画面には表示されません】

パスフレーズの再入力が完了すると、秘密鍵（id_rsa_github）と公開鍵（id_rsa_github.pub）のペアが生成されます。秘密鍵は、自分しかアクセスできない場所で保管しましょう。

.pub拡張子がついている公開鍵は、GitHubなど、SSHで接続したい先のサービスに登録しておくものです。SSH通信をする際に、手元の秘密鍵と通信先に登録してある公開鍵が照合されて、認証が成功します。これにより、秘密鍵を持っている自分のみが通信を許可される仕組みです。

Your identification has been saved in /Users/hoge/.ssh/id_rsa_github.
Your public key has been saved in /Users/hoge/.ssh/id_rsa_github.pub.
The key fingerprint is:
SHA256:【略】 your_email@example.com
The key's randomart image is:
+---[RSA 4096]----+
...(snip)...
+----[SHA256]-----+

生成時に指定した場所に鍵が配置されています。

$ ls ~/.ssh/id_rsa_github*
/Users/hoge/.ssh/id_rsa_github     /Users/hoge/.ssh/id_rsa_github.pub

生成された秘密鍵のパーミッションを600に変更します。

$ chmod 600 ~/.ssh/id_rsa_github

「-rw-------」になっていれば正しいパーミッションに変更できています。

$ ls -la ~/.ssh/id_rsa_github
-rw-------  1 hoge  staff  **** 1 1 00:00 /Users/hoge/.ssh/id_rsa_github

次に、SSHのconfigファイルを編集します。GitHubへSSH接続する際に、どの秘密鍵を指定するのかを管理するのが目的です。

以下の設定を、ファイルが存在しない場合は新規作成し、すでにあれば追記します。

$ vim ~/.ssh/config

Host github
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_github

この設定により、ssh githubと入力するだけで、ここで指定したホスト名、ユーザー名、秘密鍵が自動で指定されます。

環境の構築（3） GitHubのアカウントを作成する

ローカル環境は準備できたので、GitHub側の準備をします。

How people build software · GitHubgithub.com

まだアカウントを持っていなければ、上記サイトの右側のテキストボックスにそれぞれ、取得したいユーザー名、メールアドレス、設定したいパスワードを入力し、「Sign up for GitHub」をクリックします。

次に、無料版か有料版かを選択します。個人で使用するならまずは無料版でよいでしょう。「Unlimited public repositories for free.」を選択し、「Continue」をクリックします。

最後は、アンケート画面です。回答して「Submit」するか、そのまま「skip this step」でスキップできます。

以上で、ユーザー登録は完了です。

ただし、利用開始するにはアカウントを認証する必要があります。

登録したメールアドレスに認証用のメールが届いているので、文面中にある「Verify email address」をクリックします。

次のように「Your email was verified.」が表示されれば認証完了です。

先ほどと同じメッセージが再び表示されていますが、ここで「Start a project」をクリックします。

リポジトリを作成する

続いて、リポジトリを作成します。「Repository name」欄に作成したいリポジトリ名を入力します。ここでは、テスト用の「test」リポジトリを作成しています。

「Initialize this repository with a README」にチェックを入れて「Create repository」をクリックすると、次のような画面が表示されます。リポジトリの完成です。

これから、このリポジトリに対する操作はこのページを中心に行っていきます。

GitHubに公開鍵を登録する

先ほど作成した公開鍵をGitHubに登録します。保存した公開鍵（/Users/hoge/.ssh/id_rsa_github.pub）をエディタで開き、中の文字列をコピーします。コピーする際に改行や余分な文字列が入らないように注意しましょう。

GitHubのページの右上端にあるアイコンをクリックして、アカウントメニューの中にある「Settings」を開きます。

プロフィールの設定画面が開きます。

左側のメニューから「SSH and GPG keys」タブを選択します。

「New SSH key」をクリックすると、公開鍵の登録画面が開きます。

• 「Title」には任意の値を設定可能です。
  どのPC・サーバに置かれた鍵に対する公開鍵なのか分かるよう、PC名・サーバ名を入れておくと管理しやすくなります。
• 「Key」には、先ほどコピーした公開鍵の値をそのまま貼り付けます。

入力したら「Add SSH key」をクリックします。

GitHubへのSSH接続を確認する

続いて、GitHubへSSH接続ができるか確認をします。

$ ssh github

SSHのconfigファイルを先ほど設定したので、このように「github」と指定するだけで、記載したホスト名、ユーザー名、秘密鍵が自動的に使われます。

途中でパスワードを求められたら、鍵の生成時に設定したパスフレーズを入力します。次のように「You've successfully authenticated」と表示されたら成功です。

Hi github-sample! You've successfully authenticated, but GitHub does not provide shell access.

ただし、これはSSH接続を確認しただけです。実際の操作は次から説明するようにGitコマンドで行います。

GitHubを使う（1） Gitコマンドでリポジトリをコピーする

それでは、GitとGitHubの基本的な操作を、実際の開発の流れに沿って説明します。先ほど作成した空の「test」リポジトリが存在する段階から始めます。

まず、Gitの作業ディレクトリとして、ソースを配置するディレクトリを任意の場所に用意します。

$ mkdir git
$ cd git

GitHubで作成したリポジトリ名をコピーする

GitHubのサイトで、リポジトリのページの右側の「Clone or download」をクリックし、「Use SSH」を選択します。

「git@github.com:【ユーザー名】/【リポジトリ名】.git」という文字列をコピーします。

リポジトリをローカルにクローンする

ローカルのコマンドライン環境で、git cloneコマンドに続けて、いまコピーした文字列を入力します。

$ git clone git@github.com:【ユーザー名】/【リポジトリ名】.git
Cloning into '【リポジトリ名】'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

これでクローンが完了しました。リモートリポジトリの内容がローカルにコピーされています。

ローカルリポジトリに移動します。

$ cd 【リポジトリ名】

リポジトリの「ブランチ」について

作成された段階のリポジトリには、次のように「master」ブランチのみが存在します。

$ git branch
* master

Gitで開発する際には、直接masterブランチを修正するのではなく、作業用のブランチを作成して、そちらを修正していきます。新たにブランチを作成することを「ブランチを切る」と呼びます。

Gitのブランチの切り方には、git-flowやGitHub Flowといったワークフローがあります。それぞれメリット・デメリットがあるので、チームメンバーの好みやリリース頻度、リリースフローなどを考慮して、一番やりやすいルールを決めていきましょう。

ブランチ名の命名規則もチームで決めておくと管理しやすいでしょう。RedmineやJIRAでチケット管理をしている場合、そのチケット番号をブランチ名の接頭辞にすると、どの案件の開発なのかが分かりやすくなったりします。

今回はGitHub Flowを採用し、masterブランチと作業ブランチを使う流れで進めていきます。

作業ブランチを作成する

作業ブランチを作成します。ここでは「ファイルを新しく追加する」作業を行うため、ブランチ名は「add-new-file」としておきます。

$ git branch add-new-file

ブランチが作成されているか確かめます。ここで、アスタリスク（*）が付いているブランチと、付いていないブランチが確認できるでしょう。

$ git branch
  add-new-file
* master

アスタリスクが付いているブランチが、現在選択中のブランチです。この例では、masterブランチとadd-new-fileブランチが存在し、現在はmasterブランチで作業しているということが分かります。

作業したいadd-new-fileブランチに移動します。

$ git checkout add-new-file
Switched to branch 'add-new-file'

再度現在のブランチを確認すると、add-new-fileに移動できたことが分かります。

$ git branch
* add-new-file
  master

GitHubを使う（2） ファイルを追加してコミットする

このadd-new-fileブランチにファイルを追加してみます。エディタでsample.txtファイルを作成します。

$ vim sample.txt
hoge.

新規に作成したファイルを、バージョン管理の対象（Gitのコミット対象）に追加します。

$ git add sample.txt 

詳細を理解するには「ステージング領域」などの説明が必要になりますが、この段階では「新規ファイルは、コミットする前にaddする必要がある」と覚えておきましょう。

コミットする内容を確認する

現在行っている修正で、まだコミットをしていない内容を確認します。

$ git status
On branch add-new-file
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
    
    new file:   sample.txt

先ほどaddしたので、新規ファイルとしてsample.txtが認識されています。

もし、addを忘れていると、以下のようにコミットの対象にならないUntracked filesとして認識され、修正内容をコミットすることができません。

$ git status
On branch add-new-file
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    
    sample.txt

コミットする

前述のようにきちんとaddされた状態でコミットします。

$ git commit -a

-aオプションは、ここまでの修正をすべてコミットさせるものです。ファイル個別にコミットすることもできます。

実行すると、Vimが開かれるので、コミットに対するコメントを追加します（※Vim以外のエディタを開くよう設定を変更することもできます）。

  1 新規ファイルの追加
  2 # Please enter the commit message for your changes. Lines starting
  3 # with '#' will be ignored, and an empty message aborts the commit.
  4 #
  5 # Committer: 【ユーザー名】
  6 #
  7 # On branch add-new-file
  8 # Changes to be committed:
  9 #   new file:   sample.txt
 10 #

Vimでコメントを保存、終了すると、コミットが完了します。

$ git commit -a
[add-new-file c55282b] 新規ファイルの追加
 1 file changed, 1 insertion(+)
 create mode 100644 sample.txt

この段階でgit statusしてみると、コミットが完了しているので、以下のような状態になります。

$ git status
On branch add-new-file
nothing to commit, working tree clean

GitHubへプッシュする

この段階では、ローカル環境でコミットが完了しています。この内容を、次のコマンドでGitHubへ反映させます。

$ git push origin add-new-file
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 319 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:github-sample/test.git
 * [new branch]      add-new-file -> add-new-file

GitHubのサイトで確認をすると、ブランチの数が2になり、以下のようなモジュールも表示されます。

ブランチを切り替えることにより、それぞれの状態をブラウザ上で確認することもできます。

GitHubを使う（3） プルリクエストしてみる

基礎知識として説明したように、GitHubはソースコードを通じて開発者がコミュニケーションできることが特徴で、プルリクエスト（pull request）はそのための機能です。

GitHubの画面からプルリクエストを出してみましょう。「Compare & pull request」もしくは「New pull request」をクリックします。

新たにコミットしたadd-new-fileブランチから、masterブランチへ向けてプルリクエストを送るため、「base」（リクエスト受信側）が「master」ブランチ、「compare」（リクエスト送信側）が「add-new-file」ブランチとなります。

プルリクエストのタイトルと、内容を記載します。内容には、これが何のためのどんな修正なのか、確認できる環境やチケット情報など、必要な情報を詳しく書きましょう。

記載できたら「Create pull request」をクリックします。以上の手順で、プルリクエストのページが作成されます。

このURLを、プルリクエストを確認してもらいたい開発者や、動作確認をしてもらいたい関係者などに伝えます。

プルリクエストを確認する

本来であれば、プルリクエストを送る開発者と確認する開発者は別の人ですが、ここでは説明のため、自分自身でプルリクエストを確認することにします。

先ほど作成したプルリクエストのページを開いて「Conversation」「Commits」「Files changed」のタブで、それぞれ次の内容を確認しましょう。

• 「Conversation」では、プルリクエストの説明
• 「Commits」では、どんなコミットをされているのか
• 「Files changed」では、ファイルにどんな差分があるのか

気になる点があれば、コメントで指摘・質問します。気になる点がない場合には「問題ない」旨をコメントします。

問題の有無だけでなく、効率的なソースコードの書き方や、読みやすい書き方の提案、良いところを褒めるなど、開発者とコミュニケーションをとりましょう。コメントを記載して、「Comment」をクリックします。

コメントが記載されたら、プルリクエストを送った開発者がそのコメントを確認し、必要があれば再度修正し、コメントを追記します。そして、再度確認をもらいコメントのやり取りを両者納得できるまで繰り返します。

プルリクエストの終了とマージ

プルリクエストのコメントのやり取りが完了したら、プルリクエストを終了させます。「Merge pull request」をクリックしましょう。

マージする際のコメントを入力し、「Confirm merge」をクリックします。

今回はadd-new-fileブランチからmasterブランチへ向けてのプルリクエストだったので、add-new-fileブランチがmasterブランチにマージされた状態になります。

作業していたブランチが不要であれば「Delete branch」をクリックし、ブランチを削除します。

以上で、作業していたadd-new-fileブランチも削除され、修正内容がmasterブランチに反映された状態になります。

ローカル環境を最新にする

GitHub上でマージとブランチの削除を行いました。しかし、このままではローカル環境はまだ最新状態ではありません。次回の開発に備え最新状態にしてみましょう。

まず、masterブランチに移動します。

$ git branch
* add-new-file
  master
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

そして、masterブランチをリモート上の最新状態と同期します。

$ git pull
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
From github.com:github-sample/test
   3a45269..5f5191e  master     -> origin/master
Updating 3a45269..5f5191e
Fast-forward
 sample.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 sample.txt

先ほどのプルリクエストのマージによって、作業内容がmasterブランチに反映された状態でローカル環境も同期されました。

ローカルの作業ブランチも不要になったので削除します。

$ git branch -d add-new-file
Deleted branch add-new-file (was c55282b).

もし、マージされる前の状態で削除しようとすると、-dオプションでは以下のようなエラーになります。ローカルのmasterブランチがマージ前の状態であっても同じです。

$ git branch -d add-new-file
error: The branch 'add-new-file' is not fully merged.
If you are sure you want to delete it, run 'git branch -D add-new-file'.

マージ前のローカルブランチを強制的に削除したい場合は -dオプションではなく、-Dオプションを使います。

$ git branch -D add-new-file
Deleted branch add-new-file (was a7ff9d3).

おわりに

今回は基本的な流れを簡単に説明しました。実際に使いはじめたときには、さらに詳しい仕組みやコマンドの知識が必要になってくるでしょう。その際には、自分で本やインターネットを調べながら使ってみてください。手を動かし、調べながら進めることによって、自然と身についていくでしょう。

Git/GitHubはソースコードだけではなくシステムドキュメントや書籍原稿、デザイナーのテンプレートの管理などにも用いられます。実際の現場においても、そのチームに適したルールを考え、有効的にGit/GitHubを使い倒していきましょう。

執筆者プロフィール

池田健人（いけだ・けんと） @ikenyal

サーバサイドエンジニア。学生時代に研究室や学部の各種サーバ・ネットワーク構築などを経験し、プログラミング以外の技術も学ぶ。2011年に某Web系IT企業に入社。エンジニア職でありつつも、校正スキルには自信あり。現在はリーダーとしてマネジメントスキルを習得中。

イラスト素材：いらすとや

編集：薄井千春（ZINE）