Git & GitHubの基本的な使い方 第2回

はじめに

前回の記事では、Gitリポジトリの作成から add、commit、push の方法について記載した。
今回は、2回目以降の push の方法、リポジトリのクローン・フォークの方法、ブランチを切って push する方法についてメモを残しておきます。

---

目次

• 1. 2回目以降の push 方法
• 2. クローンとフォーク
• 3. 「ブランチを切って push しておいて」とは？

---

1. 2回目以降の push 方法

GitHubに初回の push をした後、2回目以降の変更を反映するには、以下の手順で実施します。

git add の方法

変更をステージングする方法はいくつかあります。

# インタラクティブモードで追加するファイルを選択
git add -i
git add -p

# 特定のファイルを指定してステージング
git add ファイル名

# 特定のディレクトリを指定してステージング
git add ディレクトリ名/

# すべての変更をステージング（楽だけどあまり使わない方が良い）
git add .
git add -A

慎重に作業したいなら git add -i または git add -p
特定のファイルだけ追加するなら git add ファイル名
特定のディレクトリを追加するなら git add ディレクトリ名/
すべての変更を一括で追加するなら git add .だが、意図しない変更を含めてしまう可能性がある
作業目的に合わせて、最適なオプションを選ぶと安全にgit addできる

コミットと push

# コミットを作成
git commit -m "変更内容の説明"

# リモートリポジトリにpush
git push origin main  # `main` はブランチ名

前回と異なる点は、リポジトリの作成 (git init) やリモートリポジトリの設定 (git remote add origin) を再度行う必要がないことです。

---

2. クローンとフォーク

クローン（Clone）はGitHubにある誰かが作成したリポジトリ情報をローカル環境にコピーする方法です。コピーするときは git clone コマンドを使用します。一方、フォーク（Fork）は他人のリポジトリ情報を自分のGitHubアカウント上にコピーすることです。

クローン（Clone）

GitHubのリポジトリをローカル環境にクローンする際には、通信プロトコルをHTTPSとするかSSHとうるかによって異なる。パブリックなリポジトリであっても、SSHでクローンするためには公開鍵が必要になる。

HTTPS と SSH

• HTTPS：他人が作ったリポジトリをクローンする場合

  • 認証なしでクローン可能（プライベートリポジトリを除く）
  • クローン時のコマンド：

    git clone https://github.com/ユーザー名/リポジトリ名.git
    

• SSH：自分が作ったリポジトリをクローンする場合

  • リポジトリ作成時にSSHの秘密鍵と公開鍵の設定を実施していれば、毎回認証せずに可能
  • クローン時のコマンド：

    git clone [e-mail]:ユーザー名/リポジトリ名.git
    

クローンした際のディレクトリ構成

クローンを実行すると、現在のディレクトリ内に リポジトリ名 のフォルダが作成され、その中にリポジトリのデータがダウンロードされる。

📂 作業ディレクトリ
 ├── 📂 リポジトリ名（ここにクローンされる）
 │   ├── 📂 .git
 │   ├── 📄 README.md
 │   ├── その他のファイル

フォーク（Fork）

git clone はリモートリポジトリのコピーをローカル環境にコピーするのに対し、フォーク（Fork）は他人のリポジトリを 自分のGitHubアカウント上にコピーする** 操作です。

フォーク後の流れ

1. GitHub上で Fork ボタンをクリック
2. 自分のアカウントのリポジトリとしてコピーされる
3. git clone でローカルにコピーし、変更を加える
4. git push で自分のリポジトリに反映

個人開発であれば、ここまでできれば一旦は大丈夫かと思います。
次からは、チーム開発での話になります。いきなりbranchの話からになりますが、そこら辺の詳細は後日まとめます。

3. 「ブランチを切って push しておいて」とは？

チーム開発では、新しい機能を開発するときに「ブランチを切って push しておいて」と言われることがあります。
これは、作業を main とは別のブランチで行い、その変更をGitHubに push して共有するという意味です。

ブランチを作成して push する手順

# 新しいブランチを作成
git checkout -b feature-branch-日付

# 変更を加える
# （コードを編集）

# 変更をステージング
git add ファイル名

# コミットを作成
git commit -m "新機能を追加"

# 新しいブランチをリモートリポジトリにpush
git push origin feature-branch-日付

mainへのmerge は誰がするのか？

通常、feature-branch に加えた変更を main に統合する (merge する) のは、リポジトリの 所有者や管理者 です。

1. 開発者は feature-branch-日付 を作成し作業を進める
2. 作業が完了したら push して Pull Request (PR) を作成する
3. 管理者やレビュアー がコードを確認し、問題がなければ merge する

# `main` に移動
git checkout main

# `feature-branch-日付` を統合
git merge feature-branch-日付

その後、feature-branch-日付 は不要になるので削除できます。

git branch -d feature-branch  # ローカルで削除
git push origin --delete feature-branch  # リモートで削除（削除する際は確認を）

---

まとめ

　今回の記事では、2回目以降のpushの方法、リポジトリのクローン・フォークの方法、そしてブランチを切ってpushする方法について解説しました。git clone を使えばリポジトリをローカルにコピーでき、HTTPSとSSHの違いを目的によって選択します。また、チーム開発ではブランチを活用することで、安全にコード管理ができることをまとめました。

以上です。
自身のメモですが、誰かの役にも立てるなら幸いです。