【🔰github初心者向け】ローカルからリモートへpush

記載しようと思った経緯

独学でプログラミング学習をスタートしたこともあり、githubの構造をすぐに理解できませんでした..💦
そのため、私と同様に苦しんでいる方が少しでも理解が深まったと感じてくださったら嬉しいなと思い書こうと思いました😊

開発環境

開発を進める中で「ローカル」と「リモート」という言葉をよく耳にします。
では、「ローカル」とは何でしょうか？
「ローカル」とは、自分のPCや個人のコンピューターのことを指します。
ローカルで開発している際にWebブラウザを起動すると、ドメインがlocalhostと表示されます。
一方、「リモート」とは、開発しているプロジェクトの本番環境のことを指します。
本番環境は、Webブラウザで検索をした際に表示されるサイトやWebアプリ等を指します。
つまり、世の中にリリースされているものを指し、ドメインはhttp/httpsと表示されます。
ローカルでは、新たに追加したい機能を追加し、反映させたい変更点をgitコマンド使用してローカルからリモート環境へ反映させるというイメージです。

なんのためにブランチを切るのか？

ブランチを切る主な理由は、異なる作業や変更を分けて管理するためです。
もし、mainブランチに複数人で開発を行ってしまった場合、コードの変更で互いに影響を与えてしまうことがあります。そのため、mainブランチから追加する機能のブランチを切ることによって、同時に複数の機能や修正を開発できます。

料理をするときのキッチンを例えに説明します。

- メインブランチ（mainやmaster)

これは料理をするためのキッチン全体です。
すべての基本的な調理がここで行われますが、特定の一皿や一品に焦点を当てていません。

- ブランチ

ブランチは、特定の料理やディッシュを作るためのエリアです。
例えば、spaghettiブランチではパスタ料理に焦点を当て、sushiブランチでは寿司作りに集中します。

★ブランチを切る理由

料理を作る際、複数の料理やディッシュを同時に作ることは難しいです。
同じキッチンで同時進行すると、材料やスペースが混ざり合ってしまいます。
ブランチを切ることで、それぞれのディッシュに集中できます。
例えば、spaghettiブランチではスパゲッティを作り、同時にsushiブランチでは寿司を作ります。
これにより、スパゲッティのレシピを変更しても寿司作りには影響を与えません。

- 変更の統合（マージ）

料理が完成したら、それぞれのディッシュをメインのキッチンに統合します。
これがブランチのマージです。
各ディッシュが完成したら、それを組み合わせて完全な食事を作り上げます。
同様に、ブランチでの作業が終わったら、その変更をメインブランチに統合します。
これにより、異なるブランチで行った変更が一つの場所にまとまり、プロジェクト全体が進化します。

ブランチを切る前に

※プロジェクトのクローン、開発環境が整っている前提で記載します。
ターミナルを開き、現在のブランチの状況を確認する必要があります。
以下のコマンドを実行してください。

$ git status

この確認を開発中に怠ると、思いもよらない箇所からブランチを切ってしまう可能性があります。

実行すると、現在どこのブランチにいるのか確認できます。
もし、現在のブランチの状況を確認し、思い通りのブランチではない際、移動したいブランチ名を入力し、以下のコマンドを実行してください。

$ git checkout ブランチ名

再度、ブランチがきちんと変更されているのかブランチ状況を確認してください。

ブランチを切る

プロジェクトによってはmainordevelopからブランチを切らなければならないと決まりがあると思いますが、今回はmainからログインページを作成する設定でfeature/login-pageというブランチ名ブランチを切っていきます。
ブランチを切るには、以下のコマンドを実行してください。

$ git checkout -b "feature/login-page"

ブランチが切れたのかgit statusでブランチを確認します。
On branch feature/login-pageと表示されていたらOKです！

ブランチ名の切り方

ブランチ名の切り方は、プロジェクトやチームによって異なることがありますが、一般的なベストプラクティスや標準的な命名規則があります。
ブランチ名はできるだけ明確で簡潔なものにすると良いです。
また、他の開発者が理解しやすいように、意味が通じる名前を付けることが大切です❗
以下は一般的なブランチ名の切り方の一例です。

• mainまたはmaster
  デフォルトのメインブランチ。通常、安定している本番用のコードがここにあります。
• Feature ブランチ
  新しい機能を開発するためのブランチ。例)feature/login-page, feature/user-auth.
• Bugfix ブランチ
  バグ修正のためのブランチ。例)bugfix/fix-navigation-bug, bugfix/issue-123.
• Hotfix ブランチ
  緊急の修正が必要な場合に使用されるブランチ。例)hotfix/urgent-security-patch.
• Release ブランチ
  新しいリリースのためのブランチ。リリース前の最終調整が行われます。例)release/version-1.0.0.
• Support ブランチ
  メンテナンスやサポート目的のブランチ。例)support/legacy-version.
• テスト用ブランチ
  テストのための一時的なブランチ。例)test/feature-xyz-tests.
• 環境別ブランチ
  特定の環境に関連するブランチ。例)dev, staging, qa.

変更点をリモートへ反映させる

変更のステージング

ブランチを切り、機能を追加や変更したファイルをバージョン管理システムに認識させるために、変更をステージングエリアに追加します。
これにより、どの変更を含めるかを選択できます。
反映させるために、以下のコマンドを使用します。
※VSCodeを使用している場合は、手動でもステージング可能です。

$ git add .

コミットの作成

コミットとは
バージョン管理システム（Version Control System, VCS）を使用している場合に、変更をリポジトリに記録してくれるものです。
バージョン管理システムとは、コードやプロジェクトの変更履歴を管理し、異なるバージョンのコードを追跡するためのものです。
コミットは、変更されたファイルやコードに対する 「スナップショット」 を作成し、それをリポジトリに保存します。これにより、プロジェクトの進捗を追跡でき、必要な場合に変更を元に戻すことも可能です。

変更をステージングエリアに追加したことにより、リモートへ反映されるように準備（ステージング）が完了したため、次はコミットメッセージとともにコミットを作成します。
コミットメッセージは変更の要約や目的を簡潔に説明するものです。
今回は、ログインページを作成した旨を説明したいため、以下のコマンドでコミットメッセージを作成します。

$ git commit -m "create login page"

コミットメッセージが作成できたら、リモート環境に反映させます。
以下のコマンドを実行してください。

$ git push origin main

変更の記録

コミットが作成されると、変更がリポジトリに正式に記録されます。

リポジトリとは
バージョン管理システム（VCS）を使用する際に、プロジェクトやコードの変更履歴を保存し管理するためのデータベースのようなものです。リポジトリにはプロジェクトに関連するすべてのファイル、ディレクトリ、およびそれらの変更履歴が含まれます。

これにより、特定の時点のプロジェクトの状態が保存されます。

ローカルをリモートと同じ環境にする

リモート環境には新しく追加や変更したしたファイルがバージョン管理システムに反映されいますが、ローカル環境のmainブランチにはまだ反映されていません。
つまり、ローカル環境とリモート環境に差分が発生しています。
その差分を埋めるために以下のコマンド実行します。
①まず、ブランチをmainブランチに切り替える。

$ git checkout main

②差分をなくし、リモート環境と同じにする。

$ git pull origin main

最後に

GitHubでの内容追加や変更の反映方法についてご説明させていただきましたが、何か誤っている点があればご教示いただけますと幸いです。
また、テキストだけでは理解が深まらないと思うので、実際に手を動かして学ぶのが一番早いと考えます！
私もまだまだ駆け出しのエンジニアであり、理解しきれていないことがたくさんありますが、日々実践を繰り返して成長していきたいと思っています🔥