この記事はド素人によるGitHubの覚え書きです。
はじめに
FirefoxでGitHubにログインしファイル編集からマージまでを行うことはできたが、このままでは新規ファイルのアップロードや新規フォルダ（ディレクトリ）を作ることができない。そこで必要になるのがGitである。一月半ほど四苦八苦した末に体得した、GitのインストールとGitHubへのアップロードを覚書。個人的な学習ノート第二弾。基本事項
- GitとGitHubは似て非なるもの。
- Git ≒ ソフトウェア開発の管理システム。自分のPCで使う。
- GitHub ≒ 世界中の開発者が Git で作っているソフトウェアが集まるWEBサイト。
- GitとGitHubの目的は「いつ誰が何をどのように編集したか」を管理すること。
- Gitは端末を使う。
- ディレクトリ＝フォルダ。
- リポジトリ（Repository）＝Git及びGitHub上のソフトウェア本体及び付随するデータベース。
1. 自分のPCにGitをインストールする
まず、自分のPC内で Git を使えるように準備する。Linuxの場合はパッケージマネージャを使うと良い。 その後、端末を開き、GitHubのアカウント名やメールアドレスを登録する。詳細は参考リンク参照のこと。$ git config --global user.name "GitHubのアカウント名"
$ git config --global user.email GitHub登録のメールアドレス
参考リンク
2. GitHub上のリポジトリを自分のPC（ローカル）に複製する
既にGitHubに存在するリポジトリに参加するには、GitHubに自分のアカウントを作った後、複製元のリポジトリをフォークする。 次に、PC内の任意の場所で右クリックして端末を開き、下記コマンドを実行する。$ git clone リモートリポジトリのurlここで指定するリモートリポジトリのurlは、GitHubのCodeタブにある「Clone or download」ボタンを押すと表示される。 コマンドを実行すると、フォルダ内に複製したリモートリポジトリができる。 今後はこれをローカルリポジトリと呼ぶ。 端末を使って複製すると、自動的にリポジトリ内に「.git」が作られる。 「.git」は、「Git 用ですよ」という印に相当するので、うっかり捨てないよう気をつけよう。
注意点
ちなみに、自分のリポジトリを「ローカルリポジトリ（local repository）」といい、 GitHub上のリポジトリを「リモートリポジトリ（remote repository）」という。remoteとは“自分から遠く離れた場所”という意味であり、ローカルリポジトリ以外は全てリモートリポジトリとなるので、「自分以外の人が保有するリポジトリは全てリモート」と覚えると良い。開発者にとって常識的な概念でもあるので、解説サイト等では単に「リポジトリ」という文言で済ませていることが多い。
注1） 自分のPCでの作業環境のみ整えたい場合
「とりあえずGitを使えるようにしておきたい」という場合は、自分のPC内に任意のフォルダを作り、右クリックして端末を開く。 端末に「git init」と入力して実行。$ git initすると、不可視フォルダ「.git」が内部に作られる。
注意点
GitHubからZIPファイルをダウンロードして複製した場合は、解凍後のフォルダ内で右クリックして端末を開き、「git init」を実行すること。3. 自分のPC（ローカル環境）で作業する。
Gitのインストールとリポジトリの準備ができたら、ファイルの追加修正等の作業を行う。 今回は、サンプルとしてKinagaCMSの日本語カラーテンプレートに「紺鼠」を追加する。4. 編集後のファイルにGit印をつける（ステージング）
編集後のファイルを放置したままでは、単なるPC内の雑多ファイルで終わってしまうため、作成したファイルに「いつ誰がどのように変更したか」という印をつける。この作業を「ステージング」「ステージする」という。 具体的には、「.git」があるフォルダ内で端末を開き「git add」コマンドを実行する。- (a) 指定したファイルをステージングする場合
$ git add ファイル名
- ファイルが入れ子になっている場合は、$マークの前に記された階層から辿る。
- 下の画像ではKinagaCMSフォルダ内で端末を開いているため、直下のincludesフォルダから辿っている。
- (b) フォルダ内全てのファイルをステージングする場合
$ git add --all
スナップショットとは、「変更部分を捉えた写真」と考えれば理解しやすい。
蛇足1. 「ステージング」の語源について。
素人には「ステージング」及び「スナップショット」が最も理解に苦しむ箇所だろう。それは「ステージ」という名のフォルダが存在しないからである。実は、ステージングについては抽象的な概念として理解せねばならない。 ちなみに、IT用語におけるステージングとは、ソフトウェア等の開発の最終段階で、実際の運用環境と変わらない環境を用意して稼働テストを行うことを意味している。ところで、「認可待ち」や「試験運用」という文言を用いず、「ステージング」という文言を使っているのは何故だろうか。 理由を邪推した結果、一つの仮説に辿り着いた。 要するに、開発者といえどもスキルには雲泥の差が有り、得意分野も異なる故、作った物が全てOKということはあり得ない。故に、開発過程で追加修正されたファイルを選抜する必要がある。ここで、開発者やファイル数が多くなるほど、その選抜行程が古今東西のアイドル養成番組に近づくことから、“ステージング”という名称にしたというものだ。 もう少し平たく言うと、様々な修正や変更を行ったファイル（歌や踊りを練習したアイドルの卵）が、いったんステージ（舞台）に上がり、「git add」という審査を受けた末に、「git commit」というお墨付きを得てリポジトリに登録される（デビューする）という流れが、スタア誕生やXフ●クターと似ている訳だ。ちなみに「スナップショット」は、ファイル（アイドル）のプロフィールといえる位置付けに相当する為、写真を想起する名称なのも道理といえよう。 一般人には概念を理解し辛いステージングという文言採用の背景を知る術はないのだが、仮にこの説が当たらずと雖も遠からずとすれば、情報化社会の初期開発者達の高い知性とユーモアセンスが伺える。さながら、economyを経済、bankを銀行と翻訳した明治期の方々のようだ。5. 編集内容をローカルリポジトリに登録する
次に、ステージングしたファイルを自分のPC内のリポジトリ（ローカルリポジトリ）にコミット（commit : 登録）する。 コミットとは「保存」と同義と考えて良い。ちなみに、ステージングしていないファイルをリポジトリに追加することはできない。 具体的には、「.git」があるフォルダ内で端末を開き「git commit」コマンドを実行し、ステージングしたファイルの差分（スナップショットという）をローカルリポジトリに登録する行為を意味する。その際には、「AをBに変更しました」等のメッセージを残すのが礼儀。$ git commit -m “メッセージの内容"メッセージは英語で書く。片言でOK。
注意点
自分のPC内で作ったファイルを、なぜわざわざステージングして、ローカルリポジトリに登録するのか疑問に思うかもしれないが、すぐにリモートリポジトリに登録しない理由は、コミットとはローカルとリモートの差分を登録する行為なので、片方だけ登録することができないからである。 「スナップショット」には「AをBに変更しました」という内容が記されるため、ローカルリポジトリからリモートリポジトリへの登録は変更部分だけで済む。すると、送信する情報量が少ない上、復数の開発者が同じ場所を修正・変更した場合に、管理者がそれぞれの差異を確認しやすくなるという利点がある。 Git ではあくまでも管理者にとって便利なことが最優先になる以上、開発者が多少面倒くさいと感じたとしても致し方ない。また、日常生活ではごく簡単な「差分の認識」をプログラムで行う難しさも物語っている。蛇足2. 最初のコミット後にスナップショットが増えている理由
最初のコミット後に「.git」フォルダ内の「objects」フォルダを除くと、スナップショットが増えている。 なぜかというと、Gitで管理するために、全てのファイルに印をつける必要があるからだ。 ちなみに、次回以降のコミットからは、変更箇所のスナップショットだけが保存される。注2） ブランチ（branch : 分岐）について
最初にコミットすると、masterブランチ(開発の本流)というものが作られる。 ブランチとは枝を意味する英語だが、Gitにおいては分岐を意味する。 分かりにくい場合は、「ある時点におけるリポジトリのコピー」と考えれば良い。 masterブランチはローカルリポジトリ内の元データに相当するため、失敗した時に元に戻れるよう、編集専用のブランチを作ることも可能。ブランチを作る作業は、「ブランチを切る」とも呼ばれる。具体的には、端末で下記コマンドを実行する。- (a) 新規ブランチを作成
$ git branch 新規ブランチ名
- 復数のブランチを扱う場合に必須となるコマンド。
- (b) 新規ブランチを作業可能にする
$ git checkout 新規ブランチ名
- 「いま作業中のブランチから出て新規ブランチに移動する」という意味。
- 実行すると、編集したファイル名と「Switched to branch '移動先名'」のメッセージが出る。
- チェックアウトという文言は一般常識の概念でOK。ホテルのチェックアウトが意味する所と同義。
- (c) ブランチ一覧および現在のブランチを確認する場合
$ git branch -a
- 現在のブランチ名が一覧で表示される。作業中のブランチは緑色で表示され、*印がつく。
- (d) ブランチの削除
$ git branch -d 削除するブランチ名
- 後述するpush後のブランチは削除し、必要最低限のブランチだけに留めると管理が楽。
6. GitHubのリポジトリアドレスをGitに登録する
次に、GitHubの自アカウントにフォークしたリポジトリのアドレスをGitに登録する。 GitHub内の当該リポジトリにて、アドレスをコピー。 作業フォルダ内で右クリックして端末を開く。 以下のコマンドを実行。$ git remote add 略称 リモートリポジトリのアドレスGitのデフォルト設定では、リモートリポジトリが「origin」となるので、略称を省略しても良い。 登録されたか確認するには、以下のコマンドを実行
$ git remote -v無事に登録されていれば、下記のように表示される。
7. GitHubのリポジトリにpushして編集内容を反映させる
この段階では、自分のPC内にあるローカルリポジトリにしか編集内容が反映されていないので、GitHubの自アカウントにあるリポジトリに対して内容を反映させる。具体的には端末で下記コマンドを実行。$ git push 略称 master上記コマンドは、前項で登録したアドレスのmasterブランチに反映させる場合に使う。
ちなみに、解説サイトでよく見かける下記コマンドは「リモートリポジトリのmasterブランチにpushしろ」という意味になる。
$ git push origin master
注意点
pushというコマンドは「ローカルリポジトリの変更内容をリモートリポジトリに登録する」という、強制上書き的なコマンドなので、リモートリポジトリの管理者権限が無ければ使えない。注3） pushできなかった場合の対応
理由は色々あるが、リモートリポジトリの内容が変更されていたパターンが最も多い。 その場合は、pushの前にプル（pull）を行い、リモートリポジトリの変更内容をローカルリポジトリに反映させる。具体的には下記コマンドを実行。$ git pull origin masterそれでもpushできない場合は、思い切って、GitHub上のリポジトリを一旦削除し、新たにフォークした方が早い。
注4） GitHubリポジトリの削除方法
削除したいリポジトリのSettingタブを開く。 一番下にある「Delete this repository」のボタンを押して、粛々と手続きを済ませる。8. GitHubの自アカウント内でプルリクエストを送る
問題なくpushできれば、Githubの自アカウントにメッセージが表示される。 この段階では、自分がフォークしたリポジトリに編集内容が反映されているだけなので、 フォーク元のリポジトリに対してプルリクエストを送る。 フォーク元のリポジトリに移動後、Codeタブの「New pull request」ボタンを押す。 次の画面で「compare across forks」のリンクを押す。- 左側の「base fork」にフォーク元、「base」に対象ブランチ名を指定。
- 右側の「head fork」に自アカウントのリポジトリ、「compare」にpushしたブランチ名を指定。
- 緑色の「Create pull request」ボタンを押す。
注5） pushとfetchとmergeとpullについて
GitHub上でファイルを編集した場合、自アカウント内でプルリクエスト後にマージ（merge）を行うことで編集内容が制式採用されていたが、端末からプッシュ（push）すると、いきなり制式採用されている。 これは何故かというと、pushはリモートリポジトリにローカルリポジトリの変更を反映させるコマンドなので、強制上書きされた状態になるからである。 従って、フォーク元の最新版リポジトリを自アカウントにフォークした直後なら、 フォーク元（GitHub）＝自アカウント（GitHub）＝ローカルリポジトリ（自分のPC） という状態なので特に支障を来さないが、どこかで内容変更があった場合には、それに合わせて整合性を保たねばならない。 どこの変更を反映させるかによって手段が異なる。a. フォーク元（GitHub）の変更を自アカウント（GitHub）に反映させたい場合
フォーク元（GitHub）≠自アカウント（GitHub）の場合に行う。 フォーク元のリポジトリのCodeタブにて「New pull request」を押す。 次のページで「compare across folks」というリンクを押す。 左側のドロップダウンメニュー「base folk」を自アカウントに設定し、右側のドロップダウンメニュー「head folk」をフォーク元に設定。この時、ブラウザの画面が自アカウントに切り替わる。 変更箇所が無ければ「There isn’t anything to compare.」というメッセージが出る。 変更箇所があれば該当する部分が表示されるのでマージ（merge）する。b. 自アカウント（GitHub）の変更をローカルリポジトリ（自分のPC）に反映させたい場合
自アカウント（GitHub）≠ローカルリポジトリ（自分のPC）の場合に行う。 基本的には、3のコマンド「pull」で良いが、変更箇所を確認してからマージしたい場合は1〜2を行う。- 1. 自アカウント（GitHub）の変更を『とってこい（fetch）』する
$ git fetch origin
- 2. とってきた変更を『反映（merge）』する
$ git merge origin/master
$ git merge 略称/リモートブランチ名
- 3. あるいは、自アカウントの変更を『とってきて反映』する
$ git pull origin master