1. はじめに

本記事は、GitHubを使ったことのない人を対象に、今日学んだこと¹をプッシュして草を生やせるようにするための記事です。

個人開発のバージョン管理をGitでしたい！ 草を生やしてモチベーションを維持したい！ という人のために、今回はTILリポジトリを作成しプッシュするところまで解説します。

GitHubに学習記録を残すついでに、Gitの動作を学ぶ。Gitの解説記事を読んだ時に頭の中でイメージがつき、理解がしやすくなる。Git学習の足掛かりとして作成しました。

■対象読者
動かしながらGitの理解を進めたい！
とりあえず個人でしかGitHub使わないよ！
GitHub登録したけど草生やしたことないよ！という方向け

2. 前提

GitHubアカウント作成済み

3. 環境

Windows10
Git version 2.31.1

4. 用語説明

・リモートリポジトリ

GitHub上に存在するリポジトリ（保管庫）

ローカルリポジトリ上でステージング→コミット→プッシュすることで、リモートリポジトリにローカルリポジトリの内容が更新されます。

プッシュした段階でリモートリポジトリが更新され、GitHubに草が生えます。

・ローカルリポジトリ

PC上に存在するリポジトリ（保管庫）

・ブランチ

ブランチはその名の通り"枝"という意味ですが、イメージ的には"作業場"をイメージすると分かりやすい気がします。

//新規ブランチを作成します。
git branch ブランチ名

mainブランチは"動作保証の済んだ完成品"を置くブランチとして、もう1つ開発作業用のブランチを作ります。ローカルのmainブランチから切り出した開発作業用のブランチを仮にdevelopと名付けます。

ローカルのdevelopブランチ上で作業をし、プログラムが完成しました。テストも完了済みで品質は保証されています。これをローカルのmainブランチにマージ（結合）します。

最後にローカルのmainブランチの内容をリモートのmainブランチにプッシュすることで、ローカルの内容がリモートに更新されます。

このようにブランチを分けるのは、他人の作業の影響を受けないようにするためです。
また、マージ後に問題が発生しても、コミット履歴を参照すれば追跡調査が容易になります。

GitFlowによるとmainブランチには直接プッシュせず、マージ専用にするべきという考え方があります。GitaFlowの概要については以下の記事が参考になりました。
Git-flow ～Gitのブランチモデルを知る～

・クローン

リモートリポジトリをコピーしてローカルに持ってくること。

//カレントディレクトリにリポジトリを作成
git clone

//指定したパスにクローンを作成
git clone 作成先のディレクトリパス

・ステージング

コミットを行う前準備。
ステージングエリアに変更内容を追加します。

//カレントディレクトリ配下の更新ファイルを全てステージング
git add .  

//Git管理下の全ての更新ファイルをステージングエリアに追加 
git add -A  

//ステージングするファイルを選択することも可能
git add ファイル名

・コミット

ステージングエリア内の変更内容を記録します。
イメージ的には、ゲームでいうセーブ²に近いです。
コミットした時点で変更内容が記録され、いつでもその地点に戻すことが出来ます。

//変更内容をコミット
git commit -m "コメントメッセージ"

コミットの際には、変更内容を表すメッセージを入力してコミットします。

コミットの粒度は、以下の記事が参考になりました。
【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた

・プッシュ

コミットの内容をローカルリポジトリからリモートリポジトリへ送信し、リモートリポジトリに反映させます。 つまりローカルの内容をリモートに更新させる作業です。

//リモートリポジトリの指定したブランチにプッシュ
git push origin ブランチ名

ここで登場するブランチ名ですが、初期設定のままだと"main"³です。
originはGitHubのリポジトリURLが設定されています。
言い換えれば下記のコマンドでも実行が可能です。

git push https://github.com/GitHubユーザ名/リポジトリ名.git ブランチ名

・フェッチ/マージ/プル

フェッチは、リモートブランチの情報をリモート追跡ブランチに反映させます。

//指定したブランチに移動
git checkout ブランチ名

//指定したブランチの情報を取得し、現在のリモート追跡ブランチに反映させる
git fetch origin ブランチ名

//上記画像例の場合：main(リモート)→origin/mainを更新
git checkout main
git fetch origin main

マージは、ブランチとブランチを結合します。
2つのブランチの差分を出し、その差分を結合するイメージです。

//指定したブランチに移動
git checkout ブランチ名

//指定したブランチを現在のブランチにマージ
git merge マージするブランチ名

//上記画像例の場合：developにorigin/mainをマージ
git checkout develop
git merge origin/main

プルは、フェッチとマージを連続して行います。

//指定したブランチに移動
git checkout ブランチ名

//指定したブランチを現在のブランチにマージ
git merge マージするブランチ名

//mainブランチとdevelopブランチがある場合、次のコマンドでmainにdevelopをマージ
git checkout main
git merge develop

5. 事前準備

Gitコマンドを打つ前に事前準備として、リモートリポジトリとローカルリポジトリを作成しましょう。今後Gitで管理するリポジトリ達です。
GitHubアカウントは事前に作成しておいてください。

GitHubにリモートリポジトリを作成

Repository name：筆者は既にTILが存在するので、TIL-testとして作成しています。
Description：空欄でもOKです。
Public/Private：とりあえずPrivateで作成しています。外部に公開したい方はPublicで。
Initialize this repository wtih：とりあえずREADMEファイルだけ作成するように設定しています。
最後にCreate repositoryを押下します。

リモートリポジトリTIL-testが完成しました。

デスクトップにローカルリポジトリフォルダを作成

必須作業ではありませんが、リモートリポジトリをクローンする先のフォルダを作成します。
名前はなんでもいいです。とりあえずGit-LocalRepositoryという名前のフォルダを作成しました。

コマンドプロンプト表示

ちなみに筆者はVSCodeとGitを連携して、VSCode上のターミナルからGitコマンドを使用しています。
今回はコマンドプロンプトで行いますが、普通に便利なのでVSCode利用者は連携することをおすすめします。

参考：【初心者向け】VSCodeとGithubの連携 for Windows ～連携操作からプッシュまで～

リモートリポジトリをローカルにコピーする（クローン)

はじめに、リモートリポジトリのURLを取得しておきましょう。

次に、先ほどのコマンドプロンプト上で以下のコマンドを入力します。

//リモートリポジトリをクローン（複製）する
git clone リモートリポジトリのURL

//結果
C:\Users\kuron\OneDrive\デスクトップ\Git-LocalRepository>git clone https://github.com/MeidyRouge/TIL-test.git
Cloning into 'TIL-test'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

Git-LocalRepositoryフォルダにクローンが生成されました。
隠しファイルの.gitフォルダはGitがこのフォルダを管理するためのフォルダです。
これで準備はOKです。

6. 演習：個人開発を想定したGit運用（簡易ver）

簡易的なGitの運用演習です。GitHubに草を生やせるようになるレベルになります。
まずこれができれば、Git学習の足掛かりとしては成功です。

README.mdファイルを編集してみる

適当にファイルの中身を変更して保存。

変更内容をステージング⇒コミット⇒プッシュする

//カレントディレクトリを移動（windowsコマンド）
cd TIL-test

//変更内容をステージング
git add .  

//コミット（コミットメッセージはご自由に）
git commit -m "メッセージ" 

//ローカルの内容をリモートへプッシュ（更新）
git push origin main 

リモートリポジトリが更新されました！ もちろん草も生えます。
これで個人開発において、最低限のGit運用ができるようになりました。

6.演習の内容を図に起こすと、このようになります。

7. 演習：個人開発を想定したGit運用（ブランチ利用）

次はブランチについて、動かして学んでみましょう。

ブランチという概念を学ぶことで、ブランチの移動・作成・削除、ブランチ同士のマージなどを扱えるようになります。入門者（自分）にとっては、このブランチが結構くせ者でした。

※Gitコマンド実行前にREADME.mdを好きなように修正しておいてください。

ブランチの作成&移動

//新規ブランチ(develop)作成
git branch develop

//main → developブランチに移動
git checkout develop

ここで、現在のブランチを一度確認しておきましょうか。

//ブランチの確認
git branch -v

//結果
C:\Users\kuron\OneDrive\デスクトップ\Git-LocalRepository\TIL-test>git branch -v
* develop d55785e add:プッシュテスト
  main    d55785e add:プッシュテスト

OK。developブランチになってますね。

ステージング⇒コミット⇒プッシュ

//現在のディレクトリ配下の変更内容を全てステージング
git add .

//コミット
git commit -m "コミットテスト"

//ローカルのdevelop → リモートのdevelopブランチにプッシュ
git push origin develop

//結果
C:\Users\kuron\OneDrive\デスクトップ\Git-LocalRepository\TIL-test>git push origin develop
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 450 bytes | 450.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: Create a pull request for 'develop' on GitHub by visiting:
remote:      https://github.com/MeidyRouge/TIL-test/pull/new/develop
remote:
To https://github.com/MeidyRouge/TIL-test.git
 * [new branch]      develop -> develop

ローカルのdevelopブランチをリモートに向けてプッシュしました。

* [new branch] develop -> develop という一文を見てもらうと分かる通り、リモートリポジトリにdevelopブランチが新たに生成されていることが分かりますね。

なんやかんや開発し、完成したと思ったらマージします。

マージ&プッシュ

//mainブランチに移動
git checkout main

//develop → mainブランチにマージ
git merge develop

//ローカルのmain → リモートのmainブランチにプッシュ
git push origin main  

//使用済みのブランチを削除
git branch -d develop

リモートリポジトリmainブランチにプッシュできたか確認してみる。

できました！

新規ブランチを作成し、開発用のブランチの中で開発 → 完成した時にmainブランチにマージすることで、mainブランチには動作の保証されているバージョンのものだけを管理することができます。

個人開発でブランチは必要なのか？ 当記事を書いている内に興味深いスレが見つかりました。コミットの粒度についても触れており、大変有意義なスレです。補足としてどうぞ。
参考：Git - 一人Gitでブランチは必要か？｜teratail

7．以上、演習で行った内容を図に起こすと、このようになります

8. 演習：チーム開発を想定したGit運用（一例）

最後に、チーム開発を想定したGit運用の一例⁴を紹介します。

mainブランチは品質が保証された完成品をマージさせるためのブランチ。
developブランチは、完成したdevelop-〇ブランチをマージさせるためのブランチ。
develop-A,develop-Bは個人のブランチです。A君、B君の開発用ブランチと考えてください。もしくはA機能開発用ブランチ、B機能開発用ブランチと考えても結構です。

このようにB君にはB君専用のブランチを与えることで、A君の更新内容に影響されずに開発を行うことができます。
7.演習と異なるのは、pushの前にpullを挟んでいるところです。

コマンド自体は7.演習とほとんど変わらないので省略。個人開発の場合、自分以外の開発メンバーがいないので、ここまでする必要はないと思います。

9. おわりに

さて、無事に草が生えたでしょうか。この記事がGit学習の足掛かりになれば幸いです。

もしGitコマンド中にエラーが出て進めない！ これってどういう意味？ なんでステージングする必要があるの？ など疑問が浮かんだ時はチャンスです。人は興味を抱いたことはすんなり覚えられるので、お手持ちのパソコンでググってみましょう！

以上！