Visual Stusdio Code（以下VS Code）でGitを使えるようになりたい、Atom + SourceTree から卒業しよう！ということでVS CodeでGitについて調べたものの、分からないことだらけだったのでGit（GitHub）についてイチから学習しようと思いました。
Visual Studio Code の git 連携機能と git コマンドについて (2018/05/23) - Qiita
とても今後役立ちそうなこちらの記事に「Git-itがおすすめ（日本語で解説してくれる）」とあったのでやってみました。
本日のつまづき
ずばりなかなか「Git-it」が見つからなかったことです。
しょうもない...。
最初にページを開いて真っ先に目に入る、この緑のボタン「Read the guide」を押して、GitHubのガイドを読んでリポジトリを作ってブランチを作ってコミットしてプルリクをしてマージして...ということをしましたが、一向に日本語が出て来ず。
次に同じページの緑のボタン「Clone or download」を押して確認しましたが、違いました。
正解はこのページの「releases」というアンカーテキストから移動したページ
Releases · jlord/git-it-electron · GitHub
からダウンロードです。
「Git-it」からの発見
ProgateのGitレッスンと内容は同じかと思いきや、こちらの方が盛りだくさんでした。
Git-itでは、練習で作成したローカルリポジトリをGit-itに登録して、レッスンの区切りごとに「VERIFY」ボタンでできているかチェックできます。
以下GitHub、gitコマンド初心者である私が引っかかったところをメモします。
git commit の前は git add する
Git-itでは練習として
一回コミットしたファイルをもう一度変更・保存して
git diffで差分を確認して、コミットしましょう
と出てくるので、その通りにすると、
On branch master
Changes not staged for commit:
modified: readme.txt
no changes added to commit
と、コミットできないようなことを言われました。
調べると、
“はじめのGit”――超基本的な作業フローと5つのコマンド (3/3)：こっそり始めるGit／GitHub超入門（2） - ＠IT
「Changes not staged for commit」はファイルが変更されているのに変更がステージングエリアにない（インデックスされていない）ときに出てくるメッセージだそうです。
確かにSourceTreeでもコミット前に毎回ファイルをチェックする操作をしていました。
git add と git commit はセット！覚えます。
user.username はGit−it独自のもの
git config の設定値でuser.username というものが出てきます。Git-itの日本語版では「GitHubと同じユーザー名にしてください」と出てきます。
英語版では↓
user.username はGit−itでしか使わないもののようです。
フォーク、クローン
GitHubで人様のリポジトリをコピーして自分のアカウントに置くフォーク。これはGitHub上で操作します。
さらにそのリポジトリをローカルにコピーするクローン。
コピー先に移動して
git clone <URL>
です。
フォークは初めて知りました。
プルリクのための機能、元のリポジトリを汚さずにコピーしたリポジトリを更新してプルリクする。共有されていないリポジトリに対して行うことが多いようです。
共有されているリポジトリ、同じプロジェクトを複数人で触るときなどは、フォークを使わず、そのままブランチを切って更新、プルリクをする、というパターンを取ります。
GitHub Pages
GitHubは'ph-pages'という名前のブランチにあるファイルを自動的に静的なWebサイトとしてホストしてくれる機能があります。
すごいですね。なんて太っ腹！
2020年5月現在では、ブランチ名は自由に設定できそうです。
【初心者向け】Github pagesでwebページを公開する方法 - Qiita
ページを作るときが来たらまた調べようと思います。
ブランチ
ブランチの作成： git branch ブランチ名
ブランチの確認： git branch 今どのブランチにいるか * で記されます
ブランチの切り替え（チェックアウト）： git checkout ブランチ名
pushするときの注意点
push先のリポジトリ、ブランチを意識する
コマンドで push するとき
git push origin ローカルリポジトリのブランチ名:リモートリポジトリのブランチ名
となります。
ローカルとリモートでブランチ名が同じ場合は : で区切らずブランチ名1つでOKです。
Git-itではGitHubの「patchwork」というリモートリポジトリをフォーク、クローンして、ローカルリポジトリに「add-<USERNAME>」というブランチを作りました。
ファイル更新後のpushコマンドは git push origin <BRANCHNAME> なのですが、
そこで何を思ったか勘違いをしてgit push origin patchwork と、リポジトリ名を入れてしまいました。すると
error: src refspec patchwork does not match any error: failed to push some refs to 'リモートリポジトリのURL'
というエラーが出ました。
勘違いにつぐ勘違いで、それじゃあ git push origin add-<USERNAME>:patchwork だ！とpushしたところ、「VERIFY」とチェックしてもOKとなりませんでした。
リポジトリ名とブランチ名の混同問題。気をつけます。
リモートリポジトリにローカルと同名のブランチがなければ新しく作られる
しっかりした確証はないのですが、そのようです。
前述のようにブランチ名が異なるpushをしたのですが、リモートリポジトリにこれまでなかった「patchwork」ブランチが作られていました。
新しくリモートに作られたブランチが自分には見えるのにリポジトリを共有している人には見えなかったりなど、いろいろ問題が起こるそうなので、覚悟しておきます。
コラボレーター（Collaborators）
GitHubの Settings >Manage access というメニューにありました（2020年5月現在）
フェッチ
gitがバージョンアップして「pull = fetch + merge」という解釈で良いとありました。
【入門者向け】Gitのfetchコマンドについて図を用いて解説
フェッチをすると、リモートの変更を追跡するためのブランチ「リモートトラッキングブランチ（origin/master）」がローカルに作成されます。
そしてローカルのmasterブランチを最新にするためには、masterブランチから
git marge origin/master とマージします。
これまで謎だった origin/master の正体が少しわかりました。
またGit-itには、
git fetch --dry-run で「Pullする前にリモート上で行われた変更を見てみる」
とありました。
pullではなくfetch？引っかかる表現だな...という印象なのですが、おそらく --dry-run は処理のシュミレートをするオプションなので、fetch時により詳細な内容が表示されるのではないかと想像しました。おいおい確認できれば。
最後までやらずに終了
Git-it最後のステップは、練習用のGitHubリポジトリにプルリクを送り、マージされた内容をプルする、というものでした。
こちらに自分のユーザー名のテキストファイルが追加されます。
patchwork/CONTRIBUTORS at gh-pages · jlord/patchwork · GitHub
Git-it修了生の方々がずらり。
おもいっきり日本人とわかるユーザー名にしてしまったことを少し後悔して、操作の流れを読んで終わりにしました（いくじなし）。
＊＊＊
コマンドでGitを覚えると、SourceTreeなどのGUIの操作はこういうことだったのか、という気付きがありました。嫌でも黒い画面の英文を読まなくてはいけないので、ちゃんとした理解が必要で、「なんとなく」の操作が減りそうです。
...忘れてはいけないのは、私はVS CodeでGitを使う方法を模索しているということです。
黒い画面慣れしてきたので、VS Codeでもやっていけそうです。
