はじめに
プログラム開発を長らく続けていますが、Git などのソースコード管理ツールは使ってきませんでした。
Git を使っている知人に「なぜ」使うのかを聞いてみたところ、その理由が自分におおよそ当てはまらないことが分かりました。
ところが先日、知人と一緒に GitHub Copilot の Agent モードを使ってプログラム作成していたところ、よろしくない修正してくれたので「元に戻して」と指示したのですが、戻すことができませんでした。
自分で書いていれば修正した内容が分かりますが、生成 AI に書かせたものは分かりません。バージョン管理ツールが必要だと感じました。
Git は以前に一通り使ったことがあります。そのときは SourceTree や TortoiseGit を使っていました。
VS Code は Git 機能が標準で使えますね。これを使おうと思います。
VS Code で Git を使う
VS Code で Git 機能を使おうと思います。
VSCodeでのGitの基本操作まとめ #新人プログラマ応援 - Qiita
VScodeだけでGit操作を完結させるのだ～～ッ!!
VS Code で Git を使う（ソースコード管理）
上記の記事では VS Code の拡張機能「Git History」「Git Graph」「GitLens」も使いますが、自分は VS Code の標準の Git 機能だけにしようと思います。
Git ツールをインストールする
VS Code に Git 機能が標準で用意されているのかと思っていましたが、そうではなくて OS にインストールした Git ツールを呼出する仕組でした。公式サイトから入手してインストールします。
Gitのインストール方法(Windows版) #Git - Qiita
ユーザ設定する
インストールした Git ツールに「ユーザ名」と「メールアドレス」を設定します。インストーラで設定できるようにしてくれてもよさそうですが、そうなっていないので、以下のコマンド入力して設定します。
$ git config --global user.name '(ユーザ名)'
$ git config --global user.email '(メールアドレス)'
VS Code でフォルダを開く
管理したいソースコードのあるフォルダを VS Code で開きます。
リポジトリを作成する（git init）
開いているフォルダに「リポジトリ」を作成します。VS Code のサイドバーで「ソース管理」を開いて、「リポジトリを初期化する」を実行します。
開いているフォルダに「.git」フォルダが作られます。ここに管理情報が記録されます。
ステージングする（git add）
開いているフォルダでファイルを作成したり編集したりすると、VS Code の「ソース管理」の「変更」欄に表示されます。ファイルごとに、あるいは全てのファイルを「変更をステージ」します。
ステージングしないといけないか
Git は以下のエリアを管理するようになっています。
- 作業エリア＝ワークツリー
↓ - ステージングエリア＝インデックス
↓ - リポジトリ
作業エリアからリポジトリに直接記録するのではだめなのでしょうか。
Git の「ステージング」はなんのためにある？【git/add/ステージ】 - サポンテ 勉強ノート
.gitignore を用意する
Git で管理したくない、さらに後述するプッシュ処理で共有したくないファイルは、ステージングから外せばいいのですが、誤って追加してしまうかも知れません。そこで .gitignore ファイルを用意しておきます。
うさぎでもわかる🐰.gitignoreの書き方入門からマスターまで - 完全ガイド｜taku_sid🐰エージェント
コミットする（git commit）
現時点の変更内容をリポジトリに記録します。「コミットメッセージ」を書いて「コミット」を実行します。
「コミットメッセージ」を考えるのは面倒ですね。最新の VS Code はメッセージを生成 AI に考えさせることが可能です。
いつコミットしたらいいか
コミットはいつするのでしょうか。「区切がついたら」でしょうか。その「区切」とはいつでしょうか。
【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた #Rails - Qiita
知人に聞いてみたところ、ある機能を実装している途中でも「今日は終わり」とか「席を立つとき」にしていると回答ありました。コミットは後で整理することもできるので、「保存」くらいの感覚でコミットしているそうです。
変更を取消する
ソースコードの変更を管理して必要なとき戻せるようにするのが、Git を使おうと思った理由の一つでした。「変更の取消」の手順をまとめておきます。
ステージングしていない変更を取消する（git restore）
ファイルを作成したり編集したりすると、VS Code の「ソース管理」の「変更」欄に表示されます。ファイルごとに、あるいは全てファイルを「変更を破棄」できます。直前のコミットに戻します。
「変更」欄でファイルを選択すると「差分表示」できます。
この画面で内容を確認して「変更を破棄」することもできます。
ステージングを取消する（git restore --staged）
ステージングされたファイルは、上記のような「変更を破棄」できなくなります。変更を破棄できる状態にするため、ステージングを取消します。
コミットを取消する（git reset）
コミットされたファイルは、リポジトリに記録され、上記のような「変更を破棄」できなくなります。最後のコミットを取消します。
ブランチを使う
Git の「ブランチ」機能を使ってみます。
ブランチを使うと何がいいのか
ブランチはどんなとき使うのでしょうか。
知人に聞いてみたところ、以下のようなケースがあるとのことでした。
アプリを公開していて、次のバージョンのためにコードを修正していたところ、公開しているバージョンで不具合あって、それを修正したいが手元のコードは次のバージョンのため修正の途中になっている。次のバージョンの公開に合わせて不具合を直してもいいが、公開していたバージョンで直ぐに修正したい。コードを公開していたバージョンの状態に戻して対応するか。
次のバージョンに向けて、複数の機能を追加していて、それぞれ並行して開発していて、ある機能の実装できたら、別の機能の実装が途中でビルドしたい。コード一式をコピーして、別々に作業して完了したらマージ（融合）するか。
次のバージョンに向けて、複数の実装を試してみて、最善のものを採用したい。コード一式をコピーして、切替したり戻したりして作業するか。
デフォルトのブランチ
Subversion では「trunk（幹）」があって「ブランチ（枝）」を派生させると理解していましたが、Git ではリポジトリを作成したときに用意される「main」も「ブランチ」のようです。
以前に Git を使ったときは「master」ブランチが用意されたのですが、「main」に変えたようです。設定によって「master」も使えますね。
GitHub、これから作成するリポジトリのデフォルトブランチ名が「main」に。「master」から「main」へ変更 － Publickey
ブランチを作成する（git branch）
VS Code の画面下部のステータスバーの左端に、現在のブランチが表示されています。ここをクリックして表示されるサブメニューで「新しいブランチの作成」を選びます。
ブランチを切替する（git switch）
編集している途中で「ブランチを切替」できます。
リポジトリから作業エリア（ワーキングツリー）に内容がコピーされます。
チェックアウトする（git checkout）
上記で「ブランチを切替」するのは「git switch」、「変更を取消」するのは「git restore」ですが、従来は「git checkout」を使っていたそうです。
gitのcheckoutはブランチ移動だけじゃなかったという話
gitのcheckoutコマンドには3つ使い方がある
マージする（git merge）
あるブランチで実施していた修正が完了したとき、その内容を他のブランチ、特に「main」に反映しないといけません。以下の手順で「マージ（融合）」を実行します。
「変更先」のブランチ、例えば「main」に切替します。
「ブランチをマージ」を実行します。
「変更元」のブランチを選択します。
「変更元」のブランチに切替してあって「変更先」を指定してマージするのだと思っていましたが、そうではなくて「他のブランチの変更を取込」するようになっているのですね。
コンフリクトする変更をマージしたとき
個人で開発しているときはほとんどないと思いますが、別々にしていた変更がコンフリクト（衝突）する可能性があります。
ブランチを分けて別々の改修していて、一方の変更が他方の変更を壊してしまうような変更していて、マージするとどうなるでしょうか。
Git ツールは、マージを中断して、開発者がコンフリクトを解消するよう指示してくれます。
【徹底解説】これを読めばもう怖くないGitコンフリクト #初心者 - Qiita
リモートリポジトリと連携する
上記の操作は、開発環境のフォルダにリポジトリ「ローカルリポジトリ」に記録していましたが、複数のメンバーで別々の環境で開発するときは、共有できるリポジトリ「リモートリポジトリ」に記録しないといけませんね。
リモートリポジトリを用意する
リモートリポジトリは、それぞれの開発環境からアクセスできるサーバを用意して、自分で用意することができるそうです。
リモートリポジトリを提供するサービスを使うことが一般的でしょうか。「GitHub」「GitLab」「Bitbacket」など多数あります。
Gitを無料で使えるホスティングサービスおすすめ5選【比較表あり】 | 侍エンジニアブログ
例えば GitHub サービスで、リポジトリを作成しておきます。
【超入門】GitHubリポジトリの作り方 #Git - Qiita
リモートリポジトリを登録する（git remote add）
ローカルリポジトリにリモートリポジトリを紐づける登録します。VS Code の Git 機能で設定できそうですが、上手くできなかったので、以下のコマンド入力して設定します。
$ git remote add origin (リモートリポジトリの URL)
リモートリポジトリに反映する（git push）
ローカルリポジトリの内容をリモートリポジトリに反映します。VS Code の「ソース管理」画面で、コミットが済んでいると「変更の同期」できるようになるので実行します。あるいは、「リポジトリ」欄でメニュー表示して「プッシュ」を実行します。
ブランチを作成して反映する
ローカルリポジトリのブランチがリモートリポジトリにないときは、「変更の同期」が「ブランチの発行」になります。あるいは、「リポジトリ」欄でメニュー表示して「ブランチの発行」を選べます。これを実行するとリモートリポジトリにブランチを作成してくれます。
コミットとプッシュについて
「コミット」は、日常では「約束する」になるのでしょうか。データベースでは「変更を確定する」でしょうか。Git や Subversion では「リポジトリに反映する」ですね。
前述した「いつコミットしたらいいか」に戸惑っていました。「約束する」という単語が割当されていること。Subversion のリポジトリは複数のメンバーで共有するもので、そこにコミットするのは作業エリアで OK になった変更であり、気軽にするものではありませんよね。
Git の「コミット」は「セーブ（保存）」くらいであり、「プッシュ」が「コミット（約束）」なのだと考えると、自分としてはしっくりきます。
コンフリクトする内容をプッシュしようとしたとき
自分のローカルリポジトリの変更の内容が、リモートリポジトリの登録の内容と衝突するようなとき、プッシュするとどうなるでしょうか。
Git ツールは、プッシュを中断して、開発者がコンフリクトを解消するよう指示してくれます。
更新内容のプッシュ (衝突が有る場合) - Git によるバージョン管理
リモートリポジトリから取得する（git pull）
別のメンバーがリモートリポジトリに反映（プッシュ）した内容があれば、自分のローカルリポジトリに反映（プル）しないといけません。VS Code の「ソース管理」画面の「リポジトリ」欄でメニュー表示して「プル」を実行します
コンフリクトする内容をプルしようとしたとき
前述のプッシュがリジェクトされたときを含めて、リモートリポジトリの登録が自分のローカルリポジトリとコンフリクトする内容だったとき、プルするとどうなるでしょうか。
Git ツールは、マージのときと同様に、プルを中断して、開発者がコンフリクトを解消するよう指示してくれます。
リモートリポジトリから取得する（git clone）
ローカルの開発環境にリポジトリがない段階で、リモートリポジトリの内容を丸ごとコピーしてきたいことがあります。VS Code でフォルダが閉じている状態で「ソース管理」画面を開くと、「リポジトリをクローンする」が実行できます。
VSCodeでリポジトリをクローンする方法 - Web Creator File
