GitHubアカウントの、特にメアド公開設定について
・GitHubアカウントとしてのおもなセットアップ要素は、ユーザ名、メールアドレス、パスワード、二要素認証用のセットアップ、API用のトークン（っていう表現が適切か不明）、といったあたりか。
・ユーザ名やメアドについては、
［A］上述のGitHubアカウントの要件としてのもの
とそれより小さい粒度で、
［B］各リポジトリ毎に設定するもの
とで、区別されている模様。
・前者［A］は、アカウント作成の要件で、メアド（とユーザ名？）はおそらく、外部に隠ぺいする設定が可能。GitHubのアカウント設定的な項目がきっとあるんだろうなと（未確認）。
・後者［B］について、用途（の一つ？）としては、当該リポジトリでのコミット作業時などに、ログに自動付与されるアレ
Author: 名前 <xxxx@yyyy.zzzz.com>
のユーザ名やメアドになるようだ。
で、これは［A］のものと同じ値にする必要はない。また、外部からコミットログを通じて見られうる、とのこと。なので、メアドについてはスパム対策としてダミーに変えてみるのも手かもしれない。もちろん仕事やプロジェクトなどできちんと決められているならそれに従うべきだが。
ともあれ変えてみる。ユーザ名のほうもついでに合わせて。やり方は、
（当該ローカルリポジトリのディレクトリで）
> git config user.email "ore_sono1@tekitou.detarame.com"
> git config user.name "ore_sono1_name"
これでそのリポジトリのコミット時の記録には
>git config user.email
ore_sono1@tekitou.detarame.com
というメールアドレスと、
> git config user.name
ore_sono1_name
というユーザ名が用いられることになる。
なお --global を用いて、
> git config --global user.email "you@example.com"
> git config --global user.name "Your Name"
ってのもあるそうでどうやら、ローカルで複数リポジトリを扱っているときにそれら全体に対して一括で設定できるようだ。ただ自分の場合、ちょっと試した感じ、ユーザ名だけ一括で変わって、メアドは各リポジトリ毎の設定値のまま変化しなかった。
優先度としては、 個別リポジトリの設定 ＞ 全体での設定 のようなので、とりあえずは、
「おまじない的に--globalで一括設定したあと、リポジトリ個別でちゃんとオーバーライドしてやる」
とでも覚えておくことにしよう。
リモート名
GitHubのcodeなどの左上に「ユーザ名/app1_hontara」のように表示される、このapp1_hontaraがリモートリポジトリ名。このリモートリポジトリ名に付けられる別名・エイリアスがリモート名。デフォルトが「origin」っていう、よく見るアレの正体が、コレだったのか。
このリモート名は変えることが可能で、やり方は、
> git remote rename old_name new_name
てことで例えば origin から hogehoge に変えるなら、
> git remote rename origin hogehoge
こうすると、従前 "origin/ブランチ名" などととしていたところが、"hogehoge/ブランチ名" になる感じだろうか。
（リモート名 hogehoge に変更後のコマンド例）
> git push -u hogehoge main
> git log hogehoge/main
など
fetch
・フェッチ。リモートリポジトリ（のあるブランチについて）の変更情報をローカルリポジトリに取り込む。
・ここで「取り込む」とは、単に変更情報を持ってくる／検知する、くらいの意味合い。リモートから引っ張ってきた変更内容をローカルのソースに対して適用する行為＝マージ とは、明確に区別する。
fetchコマンドは、リモートリポジトリから最新の情報をダウンロードして、ローカルリポジトリのリモートブランチを更新するためのコマンドです。具体的には、リモートリポジトリにある最新のコミットやブランチ、タグなどの情報をローカルリポジトリに取得します。この際に、取得した情報はローカルリポジトリ内に保存されるだけで、実際にローカルの作業ディレクトリには反映されません。
・フェッチしてそれをマージすることが、プルと同義、ということだそうだ。（普段のプルの中身がそうであるという意識づけのため、当面のプルの実作業としてフェッチ→マージ という手順を踏むことにしようと思う）
・ところでこのフェッチした変更情報のありようを調べたところ、 その文脈上に トラッキングブランチ なる用語が出てきた。
トラッキングブランチ
・「追跡ブランチ」などとも？ 「リモートトラッキングブランチ」などとも？ その追跡される（トラッキングされる）ほうのリモートブランチを「上流ブランチ」などとも？ このへんはフワフワしてるので今は深追いしない。
・ローカルリポジトリ内にあり、やや隠れた存在の特殊なブランチ、といったところか。～ブランチと付いてはいるものの、いわゆる普通のブランチがコードの派生や統合を管理するために用いられているのとは、いささか趣を異にしているようだ。
・調べてみると、ローカルのブランチとリモートのブランチの関係を定義するための仕組み、といった説明が多いので、そのように解釈しておく。
・ではトラッキングブランチを設定して、何が嬉しいのか、どんな効能か。どうやら一つは、git pullやgit pushなどのコマンドで、その対象となるリモートリポジトリ名やリモートブランチ名を明示的に指定する必要がなくなる、ということのようだ。
他には何かあるのだろうか。自動的にトラッキング対象のリモートブランチの変更状況を見てくれたり？ このへんはまだ分からない。
・ともあれトラッキングブランチを実際に設定してみる。コマンド例は、
> git branch --set-upstream-to=<リモート名>/<ブランチ名> <ローカルブランチ名>
-u を使って、
> git branch -u <リモート名>/<ブランチ名> <ローカルブランチ名>
でも可。
こうすることで、<リモート名>/<ブランチ名> と <ローカルブランチ名> との関係・紐づけが定義される。
通常、トラッキングブランチを設定するなら、「一つのリモートブランチに対して、一つのローカルブランチ」という 1:1 の関係性にすべきとのこと。一つのリモートブランチに対して複数のローカルブランチを紐づけて １:N の関係性にすることは可能だが、管理が複雑になったりコンフリクトを誘発したりするので、特殊な状況でない限りはやらない。
・あるリモートブランチに対応するトラッキングブランチとして設定したローカルブランチがあるとき、その状態は git status で確認できる。
>git status
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean
「Your branch is up to date with 'origin/main'.」の部分がトラッキングブランチとしての状態を言っている。この場合はおそらくだが、現在いるローカルの main ブランチが、（リモート名 origin という）リモートリポジトリの main ブランチと同期しており、ローカルの変更がないことを示している。つまり新しいコミットがリモートリポジトリにプッシュ済みだから、git pull コマンドを実行する必要はないよ、ということか。
・トラッキングブランチの解除は、ローカルのブランチに対して行なう。具体的なコマンドは、
> git branch --unset-upstream <ローカルブランチ名>
とする。
・フェッチとの関係性だが、以下のようだ。うーん、分かったような分からんような。無理してフェッチと絡めて理解しようとせんでもいいのかしらね。
また、fetchコマンドでは、取得した最新情報をローカルのトラッキングブランチに反映することもできますが、明示的にマージを行わない限り、ローカルの作業ディレクトリには反映されません。つまり、fetchは最新の情報を取得することが主な目的であり、ローカルの作業ディレクトリに反映するためには別途マージやリベースなどの操作が必要になります。
なお、fetchコマンドの実行によって取得した最新情報は、git logなどのコマンドで確認することができます。
いったんここまで。