Pro Gitを読んでいくシリーズの記事
<ol>
<li><a href="https://aki-note.vercel.app/notes/pro-git-01" target="_blank" rel="nofollow noopener noreferrer">Pro Git第1章を読む</a></li>
<li><a href="https://aki-note.vercel.app/notes/pro-git-02" target="_blank" rel="nofollow noopener noreferrer">Pro Git第2章を読む</a>（本記事）</li>
</ol>
本記事の目的などは<a href="https://aki-note.vercel.app/notes/pro-git-01" target="_blank" rel="nofollow noopener noreferrer">Pro Git第1章を読む</a>にまとめてあります。
<h2>第2章&quot;Git Basics&quot;を読む</h2>
<a href="https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository" target="_blank" rel="nofollow noopener noreferrer">Git Basics</a>
<h3>Getting a Git Repository</h3>
<ul>
<li>この章ではgitの基本的な使い方を網羅する</li>
<li>設定の仕方、レポジトリの初期化の仕方、ファイル追跡の始め方やめ方、変更のステージングとコミットの仕方を学ぶ</li>
<li>また.gitignoreの書き方、ミスの巻き戻し方、コミットの履歴の見方、コミット間の差分の見方、pushとpullの仕方を学ぶ</li>
<li>gitレポジトリを生成する方法は<code>git init</code>をするか、既存のレポジトリを<code>git clone</code>するかの二つの方法がある</li>
</ul>
<h3>Recording Changes to the Repository</h3>
<ul>
<li>working directory内の全てのfileにはtrackedかuntrackedの二つの状態がある。</li>
<li>tracked fileは最新のスナップショットに含まれているか、現在stagedであるfileのことである。</li>
<li>tracked fileにはunmodified、modified、stagedの三つの状態がある。</li>
<li>tracked fileはgitがそのファイルのことを把握しているファイルである。</li>
<li><code>git status</code>コマンドによってどのファイルがどの状態であるかを把握することができる。</li>
<li><code>git add</code>は新しいファイルの追跡を開始したり、ファイルをステージングしたり、merge-coficted filesを解決されたものとしてマークしたりする。</li>
<li><code>git add</code>でステージングされるのは<code>git add</code>したときのファイルの状態のスナップショットである。</li>
<li><code>git status -s</code>で簡略化された表示になる。左の記号はステージングエリアにおける状態で右の記号はworking directoryにおける状態である。</li>
</ul>
<pre><code>$ git status -s
 M README
MM Rakefile
A lib/git.rb
M lib/simplegit.rb
?? LICENSE.txt
</code></pre>
<ul>
<li>
READMEは変更されたがaddされていない
</li>
<li>
Rakefikeは変更されてaddされたがもう一度変更された。その変更はまだaddされていない。
</li>
<li>
lib/git.rbは新しいファイルでありaddされた。
</li>
<li>
LICENSE.txtは追跡されていない
</li>
<li>
.gitignoreで使えるパターン
</li>
<li>
*は長さ0以上の文字列にマッチする。
</li>
<li>
[abc]はaまたはbまたはcにマッチする。
</li>
<li>
\で始めると再帰的にルールを適用しなくなる
</li>
<li>
\で終えるとディレクトリごと適用できる
</li>
<li>
?は長さ1の文字列にマッチする
</li>
<li>
**は全てのネストされたディレクトリにマッチする
</li>
<li>
.gitignoreは大抵プロジェクトのルートにのみ存在するものだが、プロジェクトのサブディレクトリにあっても良い。サブディレクトリにある.gitignoreに書かれたルールはそのディレクトリ以下において有効である。
</li>
<li>
変更の詳細を見たいときには<code>git diff</code>コマンドを使用する。
</li>
<li>
<code>git diff</code>はworking directroryとステージングエリアの差分を表示する。最新のコミットとの比較ではない。ステージングされていない変更だけが表示される。
addすればステージングエリアとworking directoryの差分はなくなるので<code>git diff</code>は何も表示しなくなる。
</li>
<li>
<code>git diff</code>は「何かまだaddされていないか」を確認するときに使う。
</li>
<li>
最新のコミットとステージングエリアを比較したいなら<code>git diff --staged</code>を使う。
</li>
<li>
<code>git diff --staged</code>は「どんな変更をaddしたか」を確認するときに使う。
</li>
<li>
<code>git config --global core.editor</code>でコミット時のメッセージを書くためのエディタを設定できる。
</li>
<li>
<code>git commit -v</code>を使うとより正確なdiff（ステージングエリアと最新のコミットとのdiff）がデフォルトでコミットのメッセージに含まれるようになる。
</li>
<li>
<code>git rm</code>を使うとuntracked fileにすることができる。正確にはworking directoryとステージングエリアからそのファイルが除去される。
</li>
<li>
普通にファイルを削除するとその削除はunstagedになるが、<code>git rm</code>を使うとステージングエリアからも除去されるため<code>git rm</code>実行直後にstagedとなる。
</li>
<li>
削除したいファイルがステージングエリアにあるとき<code>-f</code>オプションを使って強制的に削除できる。
</li>
<li>
ファイルはworking directoryに保持したいがステージングエリアからは削除したい（untrackedにしたい）ときは<code>git rm --cached hoge.hoge</code>を使うと良い。.gitignoreに書き忘れてadd
してしまったときに使える。
</li>
<li>
gitは明示的にファイルの移動を追跡しない。ファイルの名前を変更したときにgitはそれに関するメタデータを保存しない。
</li>
<li>
リネームしたいときは<code>git mv</code>コマンドを使用すると便利である。
</li>
<li>
<code>git mv README.md README</code>は以下のコマンド群と等価である。
</li>
</ul>
<pre><code>mv README.md README
git rm README.md
git add README
</code></pre>
<h2>Viewing the Commit History</h2>
<ul>
<li>コミットの履歴を見るには<code>git log</code>を使う。</li>
<li><code>git log -p -2</code> とすればpatch outputになりコミット履歴を2つ分表示する。</li>
<li><code>--pretty</code>オプションでコミット履歴の表示の仕方を変更することができる。</li>
<li>authorとcommiterの違いはauthorはその仕事をした人でcommiterはその仕事をプロジェクトに取り込んだ人のことである。</li>
<li><code>--graph</code>オプションでコミットのグラフを表示することができる。</li>
<li><code>git log --since=2.weeks</code>で過去2週間のコミットを見ることができる。</li>
<li><code>git log -S hoge</code>で文字列hogeが変更されたコミットを見ることができる。</li>
</ul>
<h2>Undoing Things</h2>
<ul>
<li>
コミットに含めるべき変更のあったファイルをコミットに含め忘れてしまったときやコミットメッセージを間違えてしまったときは<code>git commit --amend</code>を使う。
</li>
<li>
<code>git commit --amend</code>は前回のコミットと取り替える操作である。
</li>
<li>
もし前回プッシュされたコミットをamendしてそれを強制的にpushしてしまうとコラボレーターに問題を引き起こす可能性がある。
</li>
<li>
異なるコミットに分割したい変更を同時にステージングエリアにaddしてしまったとき<code>git reset HEAD &lt;file&gt;</code>を使うとステージングエリアから&lt;file&gt;を取り除くことができる。
</li>
<li>
<code>git reset</code>は--hardフラグを使うと危険なコマンドである。
</li>
<li>
<code>git checkout -- &lt;file&gt;</code>はローカルでの変更を破棄し、ステージングエリアと同じ状態か最新のコミットと同じ状態に強制的に戻される。ユーザーが変更を破棄してよいと確信しているときにしか使ってはいけない危険な操作である。
</li>
<li>
変更を保持しつつ、現在はその変更が必要ないときにはstashingとbranchingを使う。
</li>
<li>
gitではコミットされた変更はほとんど場合回復可能である。<code>--amend</code>を使った上書きからでさえ回復可能である。しかし、コミットされていないことに関しては回復できない可能性が高い。
</li>
<li>
<code>git restore</code>はv 2.23.0で導入された新しいコマンドであり、基本的には<code>git reset</code>の代わりとなる。addを取り消すには<code>git restore --staged &lt;file&gt;</code>を使用する。
</li>
<li>
<code>git restore &lt;file&gt;</code>でworking directoryの変更を破棄する。危険な操作である。
</li>
</ul>
<h3>Working with Remotes</h3>
<ul>
<li>
<code>git clone</code>コマンドでは取り扱っている全てのリモートのショートネームが表示される。<code>origin</code>とはクローンしたリモートリポジトリのデフォルトの名前である。
</li>
<li>
<code>git clone</code>は暗黙的に<code>origin</code>を追加する。明示的にリモートを追加するには<code>git remote add &lt;shortname&gt; &lt;url&gt;</code>を利用する。ショートネームはURLの代わりに使用できる名前である。
</li>
<li>
<code>git fetch &lt;remote&gt;</code>するとローカルでそのリモートリポジトリのブランチにアクセスできるようになる。それらのブランチをマージしたり、調査することができるようになる。
</li>
<li>
<code>git fetch</code>はローカルのブランチに自動的にマージすることはない。マージは手動で行う必要がある。
</li>
<li>
current branchがリモートブランチを追跡する設定をしているなら<code>git pull</code>は<code>fetch</code>してcurrent brunchに自動的に<code>merge</code>する。
</li>
<li>
<code>git clone</code>を行うと自動的にローカルのmainがリモートのmainブランチを追跡するように設定される。
</li>
<li>
<code>git push &lt;remote&gt; &lt;branch&gt;</code>コマンドで&lt;remote&gt;にローカルブランチ（&lt;branch&gt;）のコミットをpushすることができる。このコマンドは&lt;remote&gt;に対して書き込み権限を持っていてかつ誰もpushしていないときにのみ実行される。
</li>
<li>
他の人にpushによってrejectされたときはその変更をfetch and mergeしてからpushする。
</li>
</ul>
<h2>Tagging</h2>
<ul>
<li>コミット履歴のある時点にタグをつけることができる。典型的な使い方としてはrelease point(v 1.0やv 2.0など)をマークするのに使う。</li>
<li><code>git tag</code>によって既存のタグを列挙することができる。</li>
<li>gitにはlightweightとannotatedの二種類のタグがある。</li>
<li>lightweight tagは特定のコミットを指し示すものでブランチのようなものである。</li>
<li>anotated tagはgitデータベースへfull objectとして保存されるものである。タグ付けした人の名前、email、その日付、タグしたときのメッセージを含めることができ、署名や認証することが可能。</li>
<li>一時的なタグにはlightweight tagを使うと良い。</li>
<li><code>git tag -a v1.4 -m &quot;my version 1.4&quot;</code>のようにするとannotated tagを作ることができる。<code>-m</code>を省くとエディタが起動する。</li>
<li><code>git show v1.4</code>によってタグのデータをコミット付きで確認することができる。</li>
<li>追加の情報なしに<code>git tag</code>を使うとlightweight tagが作成される。</li>
<li>タグを任意のコミットに追加するには<code>git tag -a v1.2 9jd8sd</code>のようにおこなう。</li>
<li>デフォルトでタグはリモートに共有されないので共有したいときは明示的に共有する必要がある。<code>git push origin &lt;tagname&gt;</code>のようにする。</li>
<li>現在lightweight tagのみをリモートに送る方法はないがannotated tagは<code>git push &lt;remote&gt; --follow-tags</code>によって選択的に送ることができる。</li>
<li><code>git push origin --delete &lt;tagname&gt;</code>でリモートのタグを削除できる。</li>
<li>タグが指し示している時点のファイルの状態を見たいときは<code>git checkout &lt;tagname&gt;</code>を使うことができるが、このコマンドは&quot;detached HEAD&quot;の状態になり良くない副作用を起こす可能性がある。</li>
<li>&quot;detached HEAD&quot;の状態でコミットを作成すると、そのコミットはどのブランチにも所属しないコミットになる。そのコミットは直接commit hashを指定することでしかアクセスできない。</li>
<li><code>git checkout -b version2 v2.0.0</code>を行いコミットを作成すると<code>v2.0.0</code>のコミットから分岐できる。</li>
</ul>
<h2>Git Aliases</h2>
<ul>
<li><code>git --global alias.co commit</code>などとすると<code>git co</code>で<code>git commit</code>が実行されるような設定がグローバルに行われる。</li>
<li>~/.gitconfigにグローバルのgit設定が保存されている。</li>
</ul>