実務未経験エンジニアの社会人インターン2日目

今回はGitの概要と基本操作、GitHubについて解説しました。

Gitとは？

Gitとは、開発時に用いられるプロジェクトのバージョン管理が行えるツールです。
Gitでは、「リポジトリ」という「プロジェクト（やその変更履歴）を保存・管理するための箱」単位で各プロジェクトを管理します。

リポジトリについて解説

リポジトリには2種類存在します。
「リモートリポジトリ」と「ローカルリポジトリ」です。

共同開発を例にこちらをご紹介します。

リモートリポジトリ

先程、「各プロジェクトとはリポジトリという単位で保存・管理されている」というように記述しましたが、その保存・管理を行う場所がリモートリポジトリになります。

リモートリポジトリでは、各開発者が書いたコードをそれぞれ取得し、差分を読み取って反映していきます。

いわば「本番の保管庫」であり、リモートリポジトリを最新の状態にしておくことで、チーム全体が同じソースコードを取得できます。

ローカルリポジトリ

ローカルリポジトリとは、各開発者がリモートリポジトリから作業用にコピーしてきたリポジトリの事です。
こちらでは、ブランチといった単位で作業を行い、作業完了時にリモートリポジトリへ変更を適用します。

ローカルリポジトリとリモートリポジトリの作業フロー

①ローカルリポジトリにコードを書き、新たな変更を加える
②ローカルリポジトリの状態をリモートリポジトリに反映する
③リモートリポジトリは、差分を読み取り更新する

参考：
https://qiita.com/True-one/items/d698ebc2346ad184fd3f
https://backlog.com/ja/git-tutorial/intro/02/

また、開発時にGitを利用すると下記のような利点があります。

・過去の更新を開発中のプロジェクトに反映できる = 常にバックアップが復元できる状態
・更新時に、誰がどんな変更を加えたかを保存する = 信頼性の確保や改ざんを防止できる
・複数人で同じファイルを編集して統合できる = 同じファイルを触っても上書きにならない

参考：https://qiita.com/a_goto/items/0fe40b17105d1ac1c40b

GitHubとは？

GitHubとは「Gitをホスティングするクラウドサービス」です。
GitはPCや社内サーバーで動作しますが、GitHubではクラウド上でGitを用いることができます。

またGithubには、Gitには無い便利な機能が存在しています。
代表的な便利機能としては、CI/CD、Pull Request、Issueなどがあります。

Gitはあくまでツールそのものであり、GitHubはWebサービスの名前というのがイメージしやすいかと思います。

この2つの関係は「メールとGmail」の関係に似ています。
Gmailはメールを利用するためのWebサービスですし、メールのWebサービスはGmail以外にもYahoo!メールなどがあります。

参考：https://qiita.com/True-one/items/d698ebc2346ad184fd3f

GitHubでリポジトリを作成していく大まかな流れ

1. 作業用ディレクトリの作成

まずはmkdirコマンドで任意のフォルダを作成し、作業用ディレクトリに指定します。

PS C:\Users\yusuke> mkdir enviroment_to_try

  ディレクトリ: C:\Users\yusuke

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2025/11/07     13:45                enviroment_to_try

PS C:\Users\yusuke> cd enviroment_to_try
PS C:\Users\yusuke\enviroment_to_try>

2. GitHubの画面からリモートリポジトリを作成

ホームページまたはマイページのRepositoriesにある「New」ボタンをクリックして以下の画面へ。

設定項目について説明

Repository name：任意のリポジトリ名を記載します。

Description：リポジトリに関する説明を記載します。必須ではありません。

Choose visibility：リモートリポジトリの公開/非公開を選択できます。

Add README：READMEファイル は、GitHubのリポジトリにおける「説明書」のような存在です。
こちらを追加するか選択できます。

Add .gitignore：Gitの管理下におきたくないファイルを指定するファイルのことです。
ドロップダウンから、.gitignoreテンプレートを言語別に選択できます。

Add license：リモートリポジトリにライセンスを付与することができます。
様々なライセンスが用意してあります。

基本的には、リポジトリ名のみの設定で作成が可能です。
説明欄や公開/非公開の設定等は状況に応じて設定してください。
また、Add READMEやAdd .gitignore、Add licenseは基本的にNoneで問題ないかと思います。
※後で作成が可能です。

参考：
https://qiita.com/daikideal/items/819f63e5f936bd5155fd
https://qiita.com/The_Past_of_Dice/items/3e59f9c7246d38328bf7

3. ローカルリポジトリの作成

作業ディレクトリでgit initを実行すると、空のローカルリポジトリが作成されます。
このベースを元に、後ほどリモートリポジトリを登録します。

PS C:\Users\yusuke\enviroment_to_try> git init
Initialized empty Git repository in C:/Users/user/enviroment_to_try/.git/

4. リモートリポジトリの登録

リモートリポジトリをローカルリポジトリに紐づけていきます。
まずは、下記画像の部分から、HTTPS/SSHを選択してURLをコピーしてください。

SSH接続とは？

SSH接続とは、不正アクセスやデータ転送を保護するための接続方法です。 SSH接続には2種類存在し、「公開鍵認証方式」と「パスワード認証方式」が存在します。

GitHubでは、公開鍵認証方式を使用してSSH接続を行うので、今回はこちらに絞って解説しようと思います。

公開鍵認証方式について解説

公開鍵認証方式とは、事前に関連付けられた「公開鍵」と「秘密鍵」を利用した認証方式です。
こちらを押さえるにあたって、まずは下記の事を押さえておく必要があります。

公開鍵 = 誰にでも公開して問題がない鍵
秘密鍵 = 自分だけで管理すべき秘匿な鍵

例として、メール送信を元に解説します。

たとえば、あなたが友人の「田中さん」に大事なメールを送りたいとします。
田中さんは事前に、自分専用の「公開鍵」と「秘密鍵」を持っています。

1. メールを送信する際、田中さんは「公開鍵」をあなたに教えます（これは誰に見られてもOK）。
2. あなたは、その公開鍵を使ってメール本文を暗号化して送信します。
3. 田中さんのもとに届いたメールは、秘密鍵を使わないと開けません。

その秘密鍵を知っているのは田中さんだけなので、他の誰も内容を読むことができません。
これが公開鍵認証方式になります。

※GitHubで公開鍵認証方式を用いたSSH接続を行う手順は、下記URLから確認できます。
URL：https://qiita.com/shizuma/items/2b2f873a0034839e47ce

参考：https://www.value-domain.com/media/ssh/

5. リモートリポジトリを登録

今回はSSH接続を用いてリモートリポジトリを登録します。
git remote add origin <URL>で紐づけが行えます。

PS C:\Users\yusuke\enviroment_to_try> git remote add origin [e-mail]:abe-yusuke-6706/enviroment-to-try.git

6. 登録したリポジトリを確認する

git remote -vで紐づけたリモートリポジトリを確認できます。
ここまでできたらリポジトリの作成は完了です。

PS C:\Users\yusuke\enviroment_to_try> git remote -v
origin  [e-mail]:abe-yusuke-6706/enviroment-to-try.git (fetch)
origin  [e-mail]:abe-yusuke-6706/enviroment-to-try.git (push)

参考：https://qiita.com/daikideal/items/819f63e5f936bd5155fd

プロジェクトを進めるための基本のアクション4つ

Gitを扱うにあたって、4つのアクションを押さえる必要があります。

1. add
2. commit
3. pull 
4. push

イメージとしては下記のようになります。

画像を分解して解説します。

↓
====================================================================
ローカルリポジトリ
↓
pull
※他のユーザーが更新したファイル等のリモートリポジトリの最新情報を取得する機能です。
====================================================================
↓
====================================================================
リモートリポジトリ
pullして、ローカルに反映
====================================================================
↓
====================================================================
ローカルリポジトリ
↓
開発者がコーディングしてローカルリポジトリを更新
↓
add 
※addを行うと、「ステージングエリア」という場所に現在の変更が保存されます。
↓
commit
※commitを行うと、addした情報を元に「内容・日時・作業者」を記録したファイルが生成されます。
↓
push
※ローカルリポジトリにある変更内容を、リモートリポジトリにアップ・反映できます。
====================================================================
↓
====================================================================
リモートリポジトリ
即座に変更が反映、もしくはPull Requestを行う
====================================================================

参考記事では、「この4つを押さえていればGitの基礎の約60％を理解したことになる」とのことでした。
僕自身も、ポートフォリオを作成する中で一番使ったコマンドだと思います。

今回は「add」「commit」「pull」「push」に加えて、いくつか機能面・アクションをご紹介して終わろうと思います。

参考：https://qiita.com/a_goto/items/0fe40b17105d1ac1c40b

その他の機能・アクション

Pull Request

チームでの開発時、新人が作ったコードを何でも「push後にリモートで即反映」という訳にはいかないので、ベテランのエンジニアの方へ一度承認を行う必要があります。

つまり、Pull Requestとは「ローカルリポジトリで開発した内容をメインのブランチに取り込んでもらうように依頼する機能」となります。

clone

cloneとは、既存のリモートリポジトリの取得です。
リモートリポジトリですでに保存されているファイルや、変更履歴を自分のローカルリポジトリとしてダウンロードします。
cloneをすることで、今までの履歴を自分のローカルに取り込み、管理することができます。

log

git logとは、Gitのコミット履歴を参照する際に使うコマンドです。
ファイルやディレクトリを追加したり編集したりしたコミットの記録を確認できます。

branch

ブランチとは、履歴の流れを分岐して記録していくためのものです。
分岐したブランチは他のブランチの影響を受けないため、同じリモートリポジトリ内でも同時に開発を進めていくことができます。

開発完了後にはブランチをマージさせ、リモートリポジトリを更新することができます。

参考：
https://qiita.com/a_goto/items/0fe40b17105d1ac1c40b
https://backlog.com/ja/git-tutorial/stepup/01/

Git-flowについて解説

ここからはブランチ運用の方針について触れていきます。

Git-flowとは、リポジトリの乱雑なワークフローに対して運用ルールを徹底し、開発を進めていく手法です。
Git-flowでは6つのブランチを使用して開発を行っていきます。

6つのブランチを解説

1. feature/○○

新機能の追加・変更・不具合修正など、実際の開発作業を行うためのブランチ。
作業が完了したら、developブランチにマージします。
作業単位で短期間使用し、完了後は削除します。

2. develop

開発の基盤となるブランチ。
新機能開発や修正は、ここからfeatureブランチを元に派生します。
develop自体では直接開発を行わず、各featureブランチをマージして進化させていきます。

3. release/x.x

次回リリースの準備や最終調整を行うブランチ。
developから派生し、動作確認や軽微な修正を行います。
準備が整ったらmainにマージしてリリースし、同時にdevelopにもマージして変更を反映します。
releaseブランチを使うことで、リリース作業中もdevelopで次の開発を進めることができます。

4. main（または master）

本番環境用のブランチ。
リリース時にのみ更新され、ここから本番にデプロイします。
開発作業や直接コミットは行わず、他のブランチをマージして反映します。

5. hotfix/x.x

本番リリース後に発生したバグなど、緊急修正を行うブランチ。
mainから派生し、修正後はmainとdevelopの両方にマージして反映します。

下記は乱雑なケースとGit-flowでワークフローを比較したものです。

#乱雑なケース

ブランチA→main
ブランチB→main
ブランチC→main
ブランチD→main

#Git-flowでのワークフロー

1. 実装する機能単位でfeature/○○というブランチを切る → developという開発時の主軸ブランチに集約

開発者A: feature/A→develop
開発者B: feature/B→develop
開発者C: feature/C→develop
開発者D: feature/D→develop

###################################################

2. developを元にreleace/x.x.xブランチを切る → releace/x.x.xでリリースに伴う軽微な修正を行う

develop → releace/1.0
----→ releace/1.0で検証 → UI面のズレや環境変数等の軽微なバグが発生
releace/1.0 → (修正) → releace/1.1

###################################################

3. releace/1.xで修正完了 → リリース時にmasterブランチにマージ → masterブランチを元にデプロイ

releace/1.x → master
----→masterを元にデプロイ
releace/1.x → develop → 開発環境を更新

###################################################

4. デプロイ後に本番環境でバグが発生 → hotfixブランチを切って修正

masterで本番環境動作中 → ✖バグが発生
----→hotfixでバグを修正
　　　(master → hotfix)
hotfix → (修正) → master → デプロイ
hotfix → (修正) → develop → 開発環境を更新

Git-flowの利点としては、ブランチ運用方針が明確化されている点です。

Git-flowを用いることでブランチの作成やマージに決まりを設けられ、複数人での開発時にもブランチをわかりやすい状態に保つことができ、不用意なマージによる問題を避けることが可能です。

参考：
https://tracpath.com/bootcamp/learning_git_git_flow.html
https://qiita.com/Yu-kiFujiwara/items/40b503683d6525c8d274
https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%81%A7%E3%81%AE%E4%BD%9C%E6%A5%AD%E3%81%AE%E6%B5%81%E3%82%8C
https://qiita.com/fujita_shoma/items/cbf79dc97e779cdae2f6

GitHub Flowとは

ドキュメントを読んでみての僕なりの解釈ですが....GitHub Flowでは「ブランチ名をわかりやすく付けて、意味のあるコミットメッセージを残し、使い終わったブランチは削除する」というシンプルなルールになっているようでした。

GitHub Flowは、Git-flowと比較すると正直かなり緩い気がしていますが、これは「Pull Request」というGitにはない、リモートへのマージに対する「承認/拒否」の機能があるからこそ成り立っているのかなと思いました。

参考：
https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E5%9F%BA%E6%9C%AC-%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%81%A7%E3%81%AE%E4%BD%9C%E6%A5%AD
https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches
https://docs.github.com/ja/get-started/using-github/github-flow