(No.2) おじさんが、Git・GitHubを利用できるようにしてみる - GitHubを利用してみる

前回までのあらすじ

• GitHubにユーザを登録した。
• (No.1) おじさんが、Git・GitHubを利用できるようにしてみる - GitHubにユーザを登録する

目的

• おじさんの成果物を、GitHub上で共有出来るようにしたい。
• 試しに適当なファイルを作成してテストしてみる。
• おじさん、小心者だから、いきなりあれもこれも出来ないよ。
• 石橋を撫でながら慎重に進めていくよ。

環境

• 内緒にしてたけど、おじさんが利用するコンピュータは、Macなんだよ。（照）
• OSがmacOSだから、Windowsとは少し手順が異なるかもだけど、基本的には同じことが出来るはずだよ。

GitHubにおじさんの成果物の保管場所を作成する

• GitHub上に成果物の保管場所を作成する必要があるようだよ。
• 保管場所のことをリポジトリ（Repository)と呼ぶらしいよ。横文字って何だかかっこいいよね（照）
• GitHubの画面右上にある「+」をクリックするとメニューが表示されるよ。
• メニューの「New repository」をクリックすると、保管場所（リポジトリ）を作成することが出来るよ。

成果物の保管場所（リポジトリ）に必要な情報を入力するよ

• Owner:
  リポジトリの所有者だよ。所有者はもちろんおじさんだよ。

• Repository name:
  リポジトリの名前だよ。今回お試しだから「test」と入力するよ。本当はかっこいい名前にしたいよね。

• Description:
  リポジトリの概要を書くことが出来るようだよ。おじさん、面倒なこと苦手だから、今回は空欄にするよ。

• Public/Private:
  Publicにすると、全世界に公開されちゃうよ（汗）。Privateはおじさんと、おじさんが許可した人に公開を限定することが出来るみたい。

• 今回はPublicを選択したよ。ちょっとドキドキするね。

• Initialize this repository with a README:
  READMEと呼ばれるテキストファイルが親切に作成された状態で、リポジトリが登録されるみたいだよ。よくわからないから今回はチェックしないよ。

• Add .gitignore:
  リポジトリに含めたくないファイルを予め指定出来るみたいだけど、今回は無視するよ。（Noneのまま）

• Add a license:
  公開する成果物のライセンス内容を記したLICENSEファイルを作成してくれるようだよ。でもライセンスに関して勉強不足だから今回は無視するよ。（Noneのまま）

• 「Create repository」を押下するよ。

リポジトリが作成されたようだけど、なんだか色々書いてるよ・・・

• 次の4つの選択肢があるようだよ、急に難しそうになってきたね・・・

1. Quick setup — if you’ve done this kind of thing before:
   以前にもこのようなことをしたことがある場合といった旨が書かれてるけど、おじさんやったことないよ。
   これは無視したら良いのかな？？　ちょっとおじさんが、気になるのは、
   前手順で無視したREADMEやLICENSEや.gitignoreを、リポジトリに含めることが推奨されているよ。
   どのような影響があるのかわからないけど、必要になってから考えることにするね。
2. ...or create a new repository on the command line:
   コマンドラインでリポジトリを作成するってどういうこと？？
   既にリポジトリは作成したはずなんだけど・・・。　それとコマンドラインって何？
3. ...or push an existing repository from the command line:
   コマンドラインから既存（作成済み）のリポジトリをプッシュする？
   もうおじさん混乱だよ。横文字が目に染みるよ。プッシュって何なの・・・。
4. ...or import code from another repository:
   他のリポジトリから、コード（おじさんがこれから書くはずのプログラムのこと？）を取り入れる？
   何書いているのかわからなくて、おじさんの心は折れそうだよ。

おじさんの頭のなか整理しないと爆発しそうだよ・・・

• 保管場所（リポジトリ）は作成したはずだよね？
  なのに、コマンドラインでリポジトリを作成する（create a new repository on the command line）とは？
• そもそもコマンドライン(command line)って何？
• 4種類の選択肢の意味

おじさん、そもそもGitをよくわかってなかったから、少し調べてみたよ

• バージョンコントロールについて

• Gitのような成果物を管理するシステムについての実現方法・種類の概要が書かれているよ。

• 成果物の管理方法？方式？は、次の３種類があるみたいだよ。
  - ローカルバージョン管理システム:
  おじさんのコンピュータのなかで、作成した成果物の変更内容や履歴を持つようだよ。
  この方法だと、おじさん以外の人が、おじさんの成果物の変更内容や履歴にアクセスすることは出来ないよ。
  おじさんのコンピュータの中にしか、成果物がないのだから当たり前だよね。
  　　

   - 集中バージョン管理システム:  
  

  複数の人がアクセス出来るようにしたコンピュータの中に、変更内容や履歴を持つようだよ。
  この方法だとおじさんの作成した成果物を複数の人に共有することも可能そうだよ。
  CVS、Subversion(SVN)と呼ばれるGitの競合は、この方式のようだよ。
  弱点としては、成果物を管理するコンピュータが故障したら、成果物の変更内容や履歴のすべてを失う危険性があるみたいだよ。
  　　

   - 分散バージョン管理システム:  
  

  前記2つの問題を解消したもののようだよ。Gitはこの方式だよ。
  おじさんのコンピュータや、おじさんの成果物の保管先(GitHub）など様々なコンピュータに、
  おじさんの作成した成果物の複製（クローン）を持たせる（分散する）仕組みのようだよ。
  例えば、おじさんの開発したプログラムを利用したい人が現れたときは、
  その人におじさんの成果物を複製（クローン）させることからはじまるみたいだよ。
  この方法なら、おじさんのコンピュータが故障しても、他の複製（クローン）が存在すれば復旧することも出来そうだよ。

• Gitの歴史

  • Gitが必要となった背景が書かれているよ。
  • Gitの特徴が書かれているよ。
  • おじさん思うに、理解出来ていない情報を鵜呑みにするのは良くないと思うから、
    特徴については一旦忘れることにするよ。

• Gitって何？

  • Git以外の方法（例えばCVSやSVN）の場合、成果物の変化の差を記録する方式のようだよ。

    • なんでそのような方式になったのかな？ おじさん気になるよ。
      • 変更差分を記録して管理する方法は、管理するファイルサイズの総量を削減出来そうな気がするよ。
      • 最新の成果物の内容を取り出すとき、差分管理の場合だと、過去の差分ひっくるめて追いかける必要がありそうだね・・・。それって、何だか大変そうだね。

  • Gitは差を記録するのではなくて、成果物（ファイル）の変化の前後をごっそり記録（スナップショット）するみたい。

    • なんでそのような方式になったのかな？ おじさん気になるよ。
      • 最新の成果物の内容を取り出すとき、スナップショットを記録する方式の方が、差分管理の方式よりも簡単で速そうな気がするよ。
      • 変更差分を記録する方式よりも、スナップショットを丸ごと記録する方が、管理するファイルサイズは大きくなりそうな気がするよ。
        • でも素人のおじさんが気になるぐらいだから、さすがに何かしらの対策を考えてそうだよね。

  • 成果物の変更内容や、変更履歴は、作業するコンピュータ上に保管されるようだよ。 この保管場所をローカルデータベースと呼ぶようだよ。

  • Gitには3つの状態があるんだって。

    • コミット済み(Committed):
      ファイルの変更をローカルデータベースに安全に記録した状態のようだよ。
    • 変更済み(Modified):
      ファイルは編集済みだけど、変更をローカルデータベースには記録していない状態のようだよ。
    • ステージング済み(Staged):
      ローカルデータベースに記録する対象に含まれている状態を意味するようだよ。コミットと呼ばれる作業をすると、ステージング済みのファイルの変更内容や履歴が、ローカルデータベースに記録されるようだよ。

  • わかりやすいようで、わかりにくい絵があるよ
    

    • .git directory(Repository):
      ファイルの変更内容や履歴を管理するデータベースのようだよ。 これは他のコンピュータからリポジトリを複製（クローン）して作られると書いてあるよ。おじさんは少しずつ、イメージがわいてきたけど、おじさんのコンピュータに作られるローカルデータベースのことだと思うよ。
    • Working Directory:
      ファイルを編集したり使用するために、前記の.git directory内にある、圧縮済みデータベースから取り出されると書いてあるよ。（圧縮されてるんだ！すごい!） 名前の通り、編集するファイルが配置されるフォルダ（ディレクトリ）を意味するのだと思うよ。
    • Staging Area:
      .git directoryに変更内容や履歴を記録する対象のファイルが何であるのか、といった情報が格納される場所のようだよ。

  • 基本的なGitの流れは次のようになるらしいよ。

    1. (Working Directoryにある）ファイルを編集する
    2. 修正されたファイルのスナップショットをStaging Areaに追加する。（ローカルデータベースに記録する対象に含める）
    3. コミットと呼ばれる作業を行うと、Staging Areaに追加されたファイルを.git directoryに記録する。

ぐちゃぐちゃになってきたから、おじさんここで一度まとめてみるよ

• Gitでは、成果物（ファイル）の変更内容や履歴の管理は、一箇所のコンピュータで管理するのではなく、その成果物（ファイル）を必要とするコンピュータに複製（クローン）させる方式のようだ。
• 成果物（ファイル）の複製元のひとつが、GitHubのようだ。
• 成果物（ファイル）の変更内容や履歴は、成果物（ファイル）を複製（クローン）したコンピュータそれぞれのローカルデータベース上で管理するようだ。
• 成果物（ファイル）を必要とするコンピュータそれぞれで、変更内容や履歴を持っているので、インターネットが使えない環境でも作業が出来る。
• 成果物（ファイル）の変更内容や履歴を共有するには、ローカルデータベース上の変更内容や履歴をGitHub上のリポジトリに反映する必要があるのではないか。（これはおじさんの想像だよ）

再び、GitHubと向き合ってみるよ

1. Quick setup — if you’ve done this kind of thing before:
   この選択肢は一旦無視するよ。
2. ...or create a new repository on the command line:
   この「repository」とは、複製（クローン）先のローカルデータベース（.git directory)を意味するものと理解したよ。
   つまり、おじさんのコンピュータ上にはまだローカルデータベースが存在しないから、この手順を実行すれば良いと判断したよ。
3. ...or push an existing repository from the command line:
   既におじさんのコンピュータにローカルデータベースが存在する状況で、ローカルデータベースの内容をGitHub上のリポジトリに反映したいときに行う手順だと思うよ。(だから今回は関係ないよね)
   それって、GitHub上でリポジトリを作成する前に、おじさんのコンピュータ上に、ローカルデータベースを作成することが出来るってことだよね？たぶん。
4. ...or import code from another repository:
   SubversionなどのGit以外のリポジトリから成果物（ファイル）を取り込みたい時の手順と理解したよ。

結論、2番目の選択肢を実行することにしたよ

• 引き続きおじさんはコマンドライン(command line)を調べる必要があるよ。
  

コマンドラインとやらを使って、GitHubとやりとりするには、Gitをインストールする必要があるようだよ

Gitのインストール

• macOSの場合は、ここからダウンロードすることが出来るみたい。

  • 他にも「GitHub for Mac」や、「Xcode Command Line Tools」をインストールする方法もあるみたいだけど、おじさんは利用しないことにするよ。

• 上記リンクには、macOSだけではなく、Windowsの手順も書いてあるよ。

• インストーラを実行するよ。

• セキュリティ警告が表示されるので、許可するよ。

• システム環境設定

• セキュリティとプライバシーより、「このまま開く」を押下

• インストーラ起動後、「続ける」を押下する。

• 「インストール」を押下する。

• 「閉じる」の押下でインストール完了。

おじさん、コマンドラインについて、ググってみたよ（笑）

コマンドラインインタプリタ

• 命令（コマンド）みたいなものをキーボードから入力して、OS（オペレーティングシステム）に指示するものみたい。
• macOSでも、次の手順でコマンドラインが使えるらしいよ。 Windowsでもコマンドラインは使えるみたいだよ。

1. 「Launchpad」
2. 「その他」
3. 「ターミナル」
4. こんな感じでコマンドを入力する画面が出てくるよ。
   

おじさん、いよいよコマンドラインを使ってみるよ

ターミナルの表示と、コマンドの入力

• 前記の手順で、ターミナルを開くと、次のように表示されているよ。 この「$」以降に命令（コマンド）を入力するよ。
  • コンピュータ名:~ ログインユーザ名$ ここに何かコマンドを入力する
• ここから先、おじさんが汗かきながらググって調べたコマンドについて書き残すよ。
  • おじさんにはコマンドのマニュアルがどこにあるのか、いまだによくわからないから、嘘や主観が含まれてるかもしれないよ・・・。

pwd(ターミナルが作業中のフォルダ（ディレクトリ）位置を表示）

• 次のコマンドを入力してエンターキーを押下すると、現在ターミナルがどのフォルダ（ディレクトリ）で作業しているのかがわかるよ。
  • コマンド: pwd
  • 結果: /Users/oyaji
  • 解説: 「/Users/oyaji」はパスといって、ファイルやフォルダ（ディレクトリ）の位置を文字で表現したものだよ。フォルダ（ディレクトリ）の区切りは「/（スラッシュ）」で表現されているよ。 先頭の「/(スラッシュ)」は、ルートディレクトリと呼ばれる、根本にあるフォルダ（ディレクトリ）のことだよ。
    現在ターミナルが作業中のフォルダ（ディレクトリ）は、「ルートディレクトリ」内にある「Users」フォルダ（ディレクトリ）内にある「oyaji」フォルダ（ディレクトリ）との意味になるよ。

mkdir(フォルダ（ディレクトリ）の作成)

• 次のコマンドを入力してエンターキーを押下すると、「test」という名前のフォルダ（ディレクトリ）を作成することになるよ。
  • コマンド: mkdir test
  • 結果: ターミナルが作業中のフォルダ（ディレクトリ）以下にtestフォルダ（ディレクトリ）が作成される。

ls(現在作業中のフォルダ（ディレクトリ）内のファイルやフォルダ（ディレクトリ）を表示）

• 次のコマンドを入力してエンターキーを押下すると、oyajiフォルダ（ディレクトリ）内のファイルやフォルダ（ディレクトリ）が表示されるよ。
  • コマンド: ls -l
  • 結果: 省略(実際に確認してみてね)
  • 解説: testフォルダ（ディレクトリ）が作成されていることがわかると思うよ。

cd(ターミナルが作業するフォルダ（ディレクトリ）を移動）

• 次のコマンドを入力してエンターキーを押下すると、/Users/oyaji/testに作業中のフォルダ（ディレクトリ）が移動するよ。
  • コマンド: cd /Users/oyaji/test
  • 結果: 作業中のフォルダ（ディレクトリ）が移動する
  • 解説: 本当に移動したかどうかは、pwdコマンドで確認してみて。（/Users/oyaji/testと、変化するはずだよ）

ここでFinderから、コマンドで作成したフォルダ（ディレクトリ）を眺めてみるよ

• Finderの「移動」メニューにある「フォルダへ移動」をクリック。
• 先程作成したフォルダ（ディレクトリ）までのパスを入力して「移動」を押下。大文字小文字を区別するから気をつけて。
• 空っぽだが、フォルダ（ディレクトリ）が作成されていることがわかる。

echo コマンドでREADME.mdファイルを作成してみる

• 次のコマンドを入力してエンターキーを押下すると、README.mdファイルが/Users/oyaji/test以下に作成されるよ。
  • コマンド: echo "# test" >> README.md
  • 結果: 作業中のフォルダ（ディレクトリ）に、ファイル名がREADME.meのテキストファイルを作成。テキストファイルの中身は"# test"。
  • 解説: ここでは解説しないよ。別の機会におじさんが解説するからね。興味のある人は「リダイレクト コマンド」などのキーワードで調べてみて。

再びFinderから確認

• 実際にファイルが作成されたことを確認。

GitHub上で指示されていたコマンドを入力してみるよ(1)

• コマンド: git init
  • マニュアル: init
  • 結果: Initialized empty Git repository in /Users/oyaji/test/.git/
  • 解説: 空のリポジトリを作成するか、既存のものを初期化するとあるよ!! .git directoryがつくられるはずだよ!

Finderで確認

• おじさん、なんだか嬉しいよ。.git directory（ローカルデータベース）が作成されたよ。
• この中に変更内容や履歴が記録されていくと思うと、おじさん、胸が熱くなるよ。

GitHub上で指示されていたコマンドを入力してみる(2)

• コマンド: git add README.md
  • マニュアル: add
  • 結果: 画面上は特に変化なし。 README.mdのスナップショットをStaging Areaに作成する。
  • 解説: README.mdのスナップショットをStaging Areaに追加する。つまり、ローカルリポジトリに変更内容や履歴を記録する対象の候補になるということだよ。

コミット（編集の確定）する前に、コミッタ（コミットする人）を判別するための情報を登録する必要があるよ（１度設定すればOKだよ）

• GitHubのEmail settingsを開く。
• 下図の青枠内に記載のメールアドレスをコピーする。
• この例では「[e-mail]」をコピーしたものとするよ。
• 次のコマンドを入力して、コミッタ（コミットする人）がおじさんであることを設定するよ。
• コマンド1: git config --global user.email "[e-mail]"
• コマンド2: git config --global user.name "コミッタの名前" （おじさんの場合は、コミッタの名前をresojisanにしたよ)
  • マニュアル: First-Time Git Setup

GitHub上で指示されていたコマンドを入力してみる(3)

• コマンド: git commit -m "first commit"
  • マニュアル: commit
  • 結果: 省略
  • 解説: Staging Areaにあるスナップショットを、ローカルリポジトリに記録する。成果物の追加または編集が確定したことを意味するよ。

GitHub上で指示されていたコマンドを入力してみる(4)

• コマンド: git remote add origin https://github.com/resojisan/test.git
  • マニュアル: remote
  • 結果: 省略
  • 解説: GitHub上に作成したリポジトリを、originという名前でリモートリポジトリ（共有する保管場所)として登録する。

GitHub上で指示されていたコマンドを入力してみる(5)

• コマンド: git push -u origin master
  • マニュアル: push
  • 結果: GitHub上のユーザ名とパスワードを求められるので入力する。
    • Username for 'https://github.com': GitHub上のユーザIDを入力してエンター。(おじさんの場合は、resojisanだよ）
    • Password for 'https://[e-mail]': パスワードを入力してエンター。
    • 次のように結果が表示される。
      Enumerating objects: 3, done.
      Counting objects: 100% (3/3), done.
      Writing objects: 100% (3/3), 230 bytes | 115.00 KiB/s, done.
      Total 3 (delta 0), reused 0 (delta 0)
      To https://github.com/resojisan/test.git
      [new branch] master -> master
      Branch 'master' set up to track remote branch 'master' from 'origin'.
  • 解説: 先程登録したリモートリポジトリ（origin)のmasterブランチに対して、ローカルデータベースにコミットした内容で更新する。
    • ブランチって何？　おじさん後で調べないとね。

GitHub上のリポジトリを確認する

• おじさんが作成したREADME.mdファイルが、GitHub上に反映されているよ〜。うれしいよ、おじさん。
• これまで自分で何も出来なかったおじさんが、少しだけど前進することが出来たよ。
  

あとがき

• GitHubのリポジトリを登録することが出来たよ。
• Gitをインストールしたよ。
• おじさんのコンピュータ上に、Gitのリポジトリを作成する必要があったよ。様々な呼び名があって、.git directoryや、ローカルデータベースや、単にローカルリポジトリと呼ばれることもあるみたいだよ。単語が多いとおじさんは混乱するよ。
• おじさんも含め、Gitで成果物を管理する人それぞれのコンピュータに、Gitのリポジトリを作成する必要があるんだよ。
• 手元で編集した成果物を、GitHub上のリポジトリに反映することにも成功したよ。
• まだ次のことが出来ていないよ。
  • GitHub上のリポジトリの成果物を、おじさんのコンピュータ上のリポジトリに反映する。
  • 実際の開発を想定したGitコマンドの利用。
• 次のことが理解出来ていないよ。
  • ブランチとは何か。
  • masterブランチって何者？
• 単語を適切に整理して使えるようになりたいよ。おじさん、難しい言葉は苦手だよ。
  （リモートリポジトリ、.git directory、ローカルデータベース、ローカルリポジトリ、Working Directory...などなど）
• おじさん、ちょっぴり後悔しているよ。こんなにも大変なことだとは思わなかったよ。
• お風呂も入っていないから、汗でギトギトだよ。

メモ

• GitHubのリポジトリと、ローカルデータベース（.git directory)との関係について。
• GitとCVSやSVNとの違いと、それぞれのメリット／デメリットを考えてみる。
• Gitの特徴とは。
• Gitを利用するうえで、GitHubは必須なのか、必須ではないのか。
• Gitの基本的な手順について。
• Gitの3つの状態について、この状態管理があることで得られるメリットは何か。

参照

• Git Book
• Git Reference
• Git Architecture
• ソフトウェア構成管理、SCM(software configuration management)
• バージョン管理システム
• リポジトリ
• Why GitHub? - Features
• https://git-scm.com
• https://ja.wikipedia.org/wiki/GitHub
• https://ja.wikipedia.org/wiki/Git
• コマンドラインインタプリタ