第7章　Gitの使い方

サイトができあがったらGitHubにアップロードして公開します。 アップロードをGitではプッシュといいます。

プッシュするときによく使われる一連の手続きは次のようなものです。

これらについて見ていきましょう。

ワークツリーの状態確認

ワークツリーとはgitの対象になっている作業ディレクトリです。 このチュートリアルの例でいえば、ローカルのサイトを保存しているディレクトリです。 ワークツリーである程度まとまった作業が済んだら、その結果をgitの管理するレポジトリに保存します。 保存はコミットによって行われます。

ワークツリーが前回のコミットからどう変更されたかを確認するには「git status」を使います。

$ git status
ブランチ main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   _config.yml

追跡されていないファイル:
  (use "git add <file>..." to include in what will be committed)
        .jekyll-cache/
        Gemfile
        Gemfile.lock
        _site/
        index.md

no changes added to commit (use "git add" and/or "git commit -a")

これはあくまで一例で、あなたのローカルで示される内容とは異なると思います。

いろいろ表示されていますが、ここで注目したいのは「Changes not staged for commit（コミットのためにステージされていない変更）」と「追跡されていないファイル」のところにあるファイルです。 Gitは最後にコミットした時点までの情報を隠れディレクトリ「.git」に保存しています。 その記録と現在のディレクトリを比較してこのようなメッセージを表示しています。

この例ではGitHubからのクローン以後、一度もコミットしていません。

クローン元のGitHubのレポジトリではどのようなコミットをしていたでしょうか？

クローンした後、

これらが「git status」で表示されているファイルなのです。

ここまでの仕事をGitを使って記録しましょう。 ここで考えなければならないのは、すべて記録しておくべきだろうか、ということです。

.gitignore

記録しないファイルは「.gitignore」というファイルに記述します。 それにより、Gitはそれらのファイルを記録対象から外します。 エディタで次のように書き、「.gitignore」という名前で保存します（ファイル名の先頭のドット（.）を忘れないようにしてください）。

Gemfile.lock
# Cache directory
.jekyll-cache

# HTML directory created by Jekyll
_site

一般的にGitで記録すべきでないファイルは

です。 再度「git status」してみましょう。

$ git status
ブランチ main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   _config.yml

追跡されていないファイル:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        Gemfile
        index.md

no changes added to commit (use "git add" and/or "git commit -a")

.gitignoreに書かれたファイルが表示されなくなりました。 なお、.gitignore自身が追跡されていないファイルに追加されました。 .gitignoreは原則としてレポジトリに記録します。

git add

ここに表示されたファイルは記録に残しますが、その手順がさきほどの画面に出ています。

  (use "git add <file>..." to update what will be committed)
  (use "git add <file>..." to include in what will be committed)

この2行から、「git add <file>」とコマンド入力することによって、アップデート（変更）とインクルード（追加）ができる、ということが分かります。 全てのファイルをaddするには、カレントディレクトリ「.」をaddすれば良いので、

$ git add .

とタイプします。 このコマンドで変更されたファイルと追加されたファイルがステージの状態になります。 この状態ではまだレポジトリに記録されたわけではありません。 記録の準備の段階が完了したということです。 再び状況確認します。

$ git status
ブランチ main
Your branch is up to date with 'origin/main'.

コミット予定の変更点:
  (use "git restore --staged <file>..." to unstage)
        new file:   .gitignore
        new file:   Gemfile
        modified:   _config.yml
        new file:   index.md

記録すべきファイルがすべて「コミット予定の変更点」に書かれています。 このことは、表示されているファイルがステージに登録されたということを意味します。 なお、ステージに誤ってファイルを入れてしまった場合はアンステージ（ステージから除くこと）できます。

  (use "git restore --staged <file>..." to unstage)

「git restore --staged <file>」でアンステージできると書かれています。 このように、Gitは親切で、そのときに使えるコマンド（の主なもの）が表示されます。

git commit

ステージされたファイルを記録に残すことをコミットといいます。 英語のコミット（commit）にはいろいろな意味がありますが、その中に「（物事を）（記憶・焼却など）にゆだねる、付す」という意味があります。

commit an idea to writing => 着想を書き留める

「git commit」コマンドでファイルを記録し、メモを残すことができます。 コマンドを発行すると、エディタが立ち上がるので、短くメモを書きます。 例えば「Add Gemfile and index.md.」などです。 上書き保存します。 上書き保存後に下のようにメッセージが表示されます。

$ git commit
[main a516afb] Add Gemfile and index.md.
 4 files changed, 103 insertions(+), 1 deletion(-)
 create mode 100644 .gitignore
 create mode 100644 Gemfile
 create mode 100644 index.md

このように、Gitにはファイルの内容だけでなくモードも記録されます。

（注）Gitのファイルモード「100644」の下三桁はUNIXのファイルパーミッションです。 上三桁の100は通常のファイルを示します。 その他のタイプとしては、「100755」が実行可能ファイル、「120000」がシンボリックリンクです。 ファイルに対してはこの3つのみです。 その他に「040000」がサブディレクトリ、「160000」がGitリンクを表します。 これらの情報はなかなかネット検索でもヒットしないのですが、Gitリファレンスのgit-fast-importに記述があります。 モードが問題になるようなケースはまず無いので、さほど気にする必要はありません。

$ git status
ブランチ main
このブランチは 'origin/main' よりも1コミット進んでいます。
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

Git の状態は、ローカルがorigin/main（リモート・レポジトリ＝GitHubのレポジトリ）よりも1コミット進んでいる、と表示されました。 先程のコミットの分だけローカルのほうが進んでいるわけです。

レポジトリにワークツリーの内容が保存されたので、「ワークツリーの内容＝レポジトリに記録された内容」となっています。 したがって、「ワークツリーは（最後のコミットから）特に変更無くクリーンでコミットするようなものはない」と表示されています。

git push

さきほどの表示に

  (use "git push" to publish your local commits)

とありました。 「git push」を使ってローカルのコミットを（GitHubに）公開できる。 ということです。 ローカルに対してGitHubはリモートといいます。 ローカルからリモートに新たなコミットをコピーするのが「git push」です。 逆にリモートが進んでいるときは「git pull」を使ってローカルに取り込みます。 大事なことは、コミットしたものだけがプッシュされることです。 コミットしていないワークツリーはプッシュされないので、必ずコミットしてください。

GitHubにpushするには、いくつかの方法がありますが、ここではhttpsとパーソナル・アクセス・トークン（PAT）を使うことにします。 PATはパスワードのようなものですが、それよりは強力です。

トークンは以後毎回pushで使えます。 「git push」すると、ユーザ名とパスワードを要求されます。 パスワードにはPATを入力します。

$ git push
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 8 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 1.50 KiB | 1.50 MiB/s, done.
Total 7 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/ToshioCP/jekyll-tutorial-for-beginners.git
   4901be1..a516afb  main -> main

プッシュで気をつけなければならないことがあります。 それは、一度プッシュしたものを訂正したり削除したりしてはいけないということです。 なぜなら、その訂正や削除の前に他のユーザがクローンやプルした場合、そのユーザのローカル・レポジトリが公開レポジトリと異なってしまうからです。 そのユーザは、以後の公開レポジトリの変更をプルできなくなってしまいます。

これを避けるには、一度プッシュした内容の上に、訂正を改めてプッシュすることです。 こういうことにならないよう、プッシュの前には一度冷静に内容を確認しましょう。

なお、プッシュ以前のローカルのコミットは変更、削除して構いません。 その方法については、この章の最後にあるリンクを参照してください。

ローカルでテスト、リモートで公開

ここまでで、ローカルとリモートを同じ状態に保つことができるようになり、しかもローカルでJekyllを使ってテストできるようになりました。 今後は

という手順をくりかえしながら開発をすることになります。

最後にGitの参考ページのリンクを付けておきます。