プロジェクトの作業中に、ローカルブランチの名前を変更する場合があるかもしれません。でも、Git ではどのようにすればいいでしょうか？

この記事では、Git で管理しているローカルブランチ名を変更する方法を 2 つご紹介します。

ブランチ名を変更する方法 - #1

ステップ 1: プロジェクトのルートディレクトリであることを確認します

まず ターミナルを開いてください。次に、cd (ディレクトリ変更) コマンドで、プロジェクトのルートに移動します。

たとえば、ターミナルでホームディレクトリを開き、デスクトップ上にあるプロジェクトに cd コマンドで移動したい場合は、このようなコマンドとなります。

cd Desktop/project-name

こちらは、デスクトップ上の Happy_Messages_Bot というディレクトリ名のプロジェクトに移動する例です。

ステップ 2: 名前を変更したいブランチに切り替えます

git checkout コマンドで、他のブランチに切り替えることができます。

git checkout branch-name

こちらは、test-branch として作成済みのブランチに切り替えたい場合の例です。

ステップ 3: -m フラグをつけてブランチ名を変更します

ブランチ名を変更したい場合には、このコマンドを使います:

git branch -m new-branch-name

こちらは、test-branch から test-branch2 へ変更したい場合の例です。

git branch -m test-branch2

git status を使って、新しいブランチ名に変更されたかどうかを確認できます。

ブランチ名を変更する方法 - #2

git checkout コマンドで変更したいブランチに切り替えなくとも、コマンド 1 つで名前を変更することができます。

ステップ 1: master / main ブランチ上で作業していることを確認します

git status を使って、master あるいは main ブランチ上で作業しているかどうかを確認します:

master あるいは main ブランチ以外で作業している場合は、master あるいは main ブランチに切り替えます。git checkout master または git checkout main コマンドで切り替えます。

ステップ 2:  -m フラグをつけてブランチ名を変更します

元のブランチ名を他の新しい名前に変える場合は、この構文が利用できます。

git branch -m old-branch new-branch

test-branch から test-branch2 へ名前を変更する場合は、このようになります。

git branch -m test-branch test-branch2

新しいブランチ名を確認するには、git branch コマンドを実行します。その結果、全てのブランチ名が表示されます。

これらの 2 つの方法で、Git で管理しているローカルブランチの名前を変更することができます。

コミット前の git add を取り消すには git reset <file> を実行します。すべてのファイルの変更を対象とする場合には git reset を実行します。

古いバージョンの Git では、それぞれ git reset HEAD <file>、git reset HEAD というコマンドでした。この変更は Git 1.8.2 で対応されました。

その他のよく使われる Git の操作については下記の記事を参照してください。

• Git checkout (英語版)
• Git pull vs Git fetch (英語版)
• Gitignore (英語版)

Git に関する予備知識

Git プロジェクトの 3 つのセクションを理解する

Git プロジェクトには以下 3 つの重要なセクションがあります。

1. Git ディレクトリ
2. ワーキングディレクトリ (またはワーキングツリー)
3. ステージングエリア

Git ディレクトリ (YOUR-PROJECT-PATH/.git/ にあるディレクトリ) は、Git がプロジェクトを正確に追跡するために必要なすべてのものが保存されている場所です。その中には、メタデータと、圧縮されたプロジェクトファイルの各バージョンを含むオブジェクトデータベースが含まれます。

ワーキングディレクトリは、ユーザーがプロジェクトに対してローカルで変更を行う場所です。ワーキングディレクトリは Git ディレクトリのオブジェクトデータベースからプロジェクトのファイルを取得し、ユーザーのローカルマシンに配置します。

ステージングエリアは、次のコミットに含める予定の情報を保存しているファイルです (「index」「stage」「cache」とも呼ばれます)。コミットとは、ステージングエリアに追加された変更を保存するよう Git に伝えるタイミングです。Git はその時点のファイルの状態のスナップショットを撮り、スナップショットを Git ディレクトリに永続的に保存します。

この 3 つのセクションにより、ある時点のファイルの状態は主に以下 3 種類のいずれかの状態を取ります。「変更済 (modified)」「ステージ済 (staged)」そして「コミット済 (committed)」です。ワーキングディレクトリにあるファイルに変更を加えると、そのファイルは「変更済」となります。次にそのファイルをステージングエリアに追加すると (訳注: git add コマンドによりこれが行われる)「ステージ済」となります。最後に、コミットすると「コミット済」となります。

Git のインストール方法

• Ubuntu の場合: sudo apt-get install git を実行
• Windows の場合: ダウンロードページ
• Mac: ダウンロードページ

Git 環境の設定

Git 環境をカスタマイズできる git config というツール (コマンド) があります。特定のコンフィグ変数を設定することで、Git の見た目や機能を変更できます。これから説明するコマンドは、コマンドラインインターフェースで実行します (Mac ならターミナル、Windows ならコマンドプロンプトか PowerShell)。

コンフィグ変数の保存場所には次の 3 つのレベルがあります。

1. システム: /etc/gitconfig に保存されている変数は、そのコンピューターのすべてのユーザーに適用されるデフォルト設定です。このファイルに変更を加えるには、git config コマンドと --system オプションを使用します。
2. ユーザー: ~/.gitconfig または ~/.config/git/config に保存されている変数は、ある特定のユーザーの設定として適用されます。このファイルに変更を加えるには、git config コマンドと --global オプションを使用します。
3. プロジェクト: YOUR-PROJECT-PATH/.git/config に保存されている変数は、そのプロジェクトだけに適用される設定です。このファイルに変更を加えるには、git config コマンドを使用します。

互いに競合する設定がある場合、プロジェクトレベルの設定はユーザーレベルの設定より優先され、ユーザーレベルの設定はシステムレベルの設定より優先されます。

Windows ユーザー向けの注意: Git は、ユーザーレベルの設定ファイル (.gitconfig) をあなたの $HOME ディレクトリ (C:\Users\$USER) の中から探します。Git はまた /etc/gitconfig も探しますが、これは MSYS のルートディレクトリからの相対パスであり、インストーラーの実行時にあなたが Git を Windows システムのどこにインストールするよう指定したかによって変わります。あなたが Git for Windows のバージョン 2.x 以上を使用しているなら、システムレベルの設定ファイルが下記の場所にも存在します。

• Windows Vista 以降なら C:\ProgramData\Git\config
• Windows XP では C:\Documents and Settings\All Users\Application Data\Git\config

この設定ファイルは、git config -f <file> コマンドを管理者として実行する方法でのみ変更が可能です。

ユーザー名とメールアドレスの追加

Git は、ユーザー名とメールアドレスをコミットの情報の一部として含めます。下記コマンドでこの情報をユーザーレベルの設定ファイルに設定できます。

git config --global user.name "My Name"
git config --global user.email "myemail@example.com"

テキストエディタの変更

Git は自動でデフォルトのテキストエディタを使用しますが、変更することも可能です。下記は、代わりに Atom エディタを使用するよう設定する例です。(--wait オプションは、シェルにテキストエディタを待つように指示します。これにより、プログラムの実行が先へ進む前に、テキストエディタで作業することができます。)

git config --global core.editor "atom --wait"

出力の表示色の設定

このコマンドで、シェルが Git の出力に色を付けるように設定できます。

git config --global color.ui true

すべての設定を確認するには、git config --list コマンドを使用します。

プロジェクト内で Git を初期化する

Git のインストールと設定後、バージョン管理機能を使い始めるためには、プロジェクトディレクトリ内で Git を初期化する必要があります。コマンドラインで、cd コマンドを使用してあなたのプロジェクトの一番上 (ルート) のディレクトリに移動します。次に、git init コマンドを実行します。このコマンドは、Git があなたのプロジェクトを追跡するのに必要なファイルやオブジェクトを含んだ Git ディレクトリを設置します。

Git ディレクトリはプロジェクトのルートディレクトリに設置されていることが重要です。Git はサブディレクトリ内のファイルを追跡することができますが、Git ディレクトリから見て親ディレクトリにあるファイルは追跡できません。

Git のヘルプを表示する

Git コマンドの使い方を忘れた場合、コマンドラインから Git のヘルプにアクセスする方法がいくつかあります。

git help COMMAND
git COMMAND --help
man git-COMMAND

このコマンドは、指定されたコマンドのマニュアルページを表示します。シェルウィンドウに表示されたマニュアルは、上下キーでスクロールするか、下記のキーボードショートカットを使用して操作できます。

• f またはスペースキー: 次のページ
• b: 前のページ
• q: 閉じる

SVN や CVS のような比較的古い集中型のバージョンコントロールシステムとは異なり、Git は分散型です。完全な履歴とコードを操作する権限を、各開発者がローカルまたはリモートに持っています。また、必要に応じて、コードの複数の部分をどこからでも変更できます。

有名な Linux OS カーネルの作者である Linus Torvalds が、2005 年、Linux カーネルの開発用に Git を作成し、その後 Git は世界中でもっとも広く使われているモダンなバージョンコントロールシステムとなりました。

この記事では、Git clone と Git branch のワークフローを紹介し、必要に応じて特定のブランチを clone する方法を説明します。では始めましょう。

必要なもの

• ターミナルについての基礎知識
• ターミナルにコマンドを入力できること
• Git のインストール (以下でも説明します)
• GitHub のアカウント
• 笑顔で楽しんで取り組む姿勢

Git と GitHub の簡単な紹介

Wikipedia では下記のように説明されています。

Git（ギット）は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。

一方 GitHub は、Git を使用したバージョンコントロールのための、ウェブ上のホスティングサービスを指します。GitHub は、Git が持つ分散型バージョンコントロールとソースコード管理の全機能に加え、コンピューターコードのための追加機能も提供します。

Windows に Git をインストールする方法

最新の Git for Windows インストーラー をダウンロード、インストールしてください。

Linux に Git をインストールする方法

以下の中からあなたの Linux ディストリビューションに合わせてコマンドを実行してください。

Debian または Ubuntu

sudo apt-get update
sudo apt-get install git

Fedora

sudo dnf install git

CentOS

sudo yum install git

Arch Linux

sudo pacman -Sy git

Gentoo

sudo emerge --ask --verbose dev-vcs/git

Mac に Git をインストールする方法

最新の Git for Mac インストーラー をダウンロード、インストールしてください。

または下記のコマンドを実行してください。

brew install git

これで Git がインストールできました。ではチュートリアルに進みましょう。

Git クローン入門

Git を使うと、「リポジトリ」の中であなたのプロジェクトにバージョンを付けて管理できます。このリポジトリを GitHub のようなバージョンコントロール用のウェブベースホスティングサービスに保存します。

このリポジトリはあなたのローカルマシンにクローン (clone) することができ、すべてのファイルとブランチをローカルに持つことができます。(ブランチについては後ほど説明します。)

例えば、freeCodeCamp のリポジトリを SSH を使用して clone するには、次のコマンドを使用します。

git clone git@github.com:freeCodeCamp/freeCodeCamp.git

Git ブランチ入門

プロジェクトの作業中、さまざまな機能の開発をすることになります。そして複数のコントリビューターが、そのプロジェクトと各機能の作業をすることでしょう。

ブランチを使用すると、master ブランチと同じファイルで自由に作業できる「プレイグラウンド (playground)」と呼ばれる環境を作ることができます。本番環境のコードを壊したり影響を与えることのないように、このブランチで、独立した機能を作成したり、新しい機能を試したり、破壊的な変更を行ったり、修正を行ったり、ドキュメントを書いたり、アイデアを試したりできます。作業が完了したらそのブランチを本番の master ブランチにマージ (merge) します。

ブランチは Git の中核をなすコンセプトであり、GitHub でも 1 つのプロジェクトに異なるバージョンがあるワークフローの管理に使われています。master ブランチは、そのリポジトリのデフォルトブランチで、「本番環境にデプロイ可能なコード」と見なされることが多いです。passwordless-auth や refactor-signup-ux のような新しいブランチは master ブランチから作成できます。

Git ブランチをクローンする方法

リポジトリは git clone コマンドでクローンすることができますが、このコマンドはブランチおよびリモートの HEAD をクローンすることを覚えておいてください。これは通常、デフォルトの設定では master ブランチとリポジトリ内の他のすべてのブランチを含みます。

つまり、リポジトリをクローンすると、master と他すべてのブランチをクローンすることになります。これは、クローンした後あなた自身の操作で目的のブランチにチェックアウトしなければならないということです。

例えば、あるプロジェクトにおけるあなたのタスクがユーザーダッシュボードにパスワードレス認証を追加することだとしましょう。この機能が passwordless-auth ブランチにあるとします。

この場合、あなたの "feature branch" は後で master ブランチにマージされるので、今は master ブランチは必ずしも必要ありません。では、「あなたが必要ないたくさんのファイル」がある他のブランチをフェッチ (fetch) せずにこの passwordless-auth ブランチをクローンするにはどうしたらいいのでしょう。

この説明用に下記のサンプルリポジトリを作成しました。このリポジトリは Nextjs で作成されたシンプルなブログで、下記 4 つのダミーブランチがあります。

• master
• dev
• staging
• passwordless-auth

Nextjs では、pages/api フォルダー内のすべてのファイルが /api/* パスにマッピングされ、ページではなくAPIエンドポイントとして扱われます。このリポジトリではそれぞれのブランチに差異をつけるため、このディレクトリにダミーのAPIを作成しました。

master ブランチには pages/api/hello.js というファイルがありますが、 passwordless-auth ブランチには pages/api/auth.js というファイルがあります。それぞれのファイルはダミーテキストのレスポンスを返しています。こちらにある master ブランチの hello API のレスポンスを見てみてください。(あなたへの挨拶のメッセージが入っているはずです。)

では、このリポジトリをクローンしてみましょう。

git clone git@github.com:BolajiAyodeji/nextjs-blog.git

これでこのリポジトリ内のすべてのブランチにアクセスできるようになり、簡単にブランチを切り替えてそれぞれのバージョンとファイルを見ることができるようになります。

git branch -a

remotes/origin/.. というブランチはどこから来たのか疑問に思いますか？

リポジトリをクローンする時、リモート (remote) と呼ばれる、インターネット上、あるいは社内のサーバーなどからリポジトリのデータをプル (pull) します。この origin という語は、リモートの URL を置き換える別名として Git が自動で作成したエイリアスです。(別のエイリアスを指定したり、変更することもできます。)

これらの  remotes/origin/.. というブランチは、インターネット上からクローンした際の元リポジトリ (origin) を指しており、origin に対して pull、push などの操作を行うことができます。

つまり master をあなたのマシンにクローンした場合、remotes/origin/master はインターネット上の元の master ブランチで、 master があなたのローカルマシンにあるブランチになります。pull、push などの操作は remotes/origin/master に向けて行います。

まとめると、remote はインターネット上のリポジトリを指す URL で、origin はこの remote URL のエイリアスです。

特定のブランチをクローンする方法

では、デモ用のリポジトリから特定のブランチをクローンしてみましょう。特定のブランチをクローンする方法は 2 つあります。以下いずれかの方法があります。

• リポジトリをクローンし、すべてのブランチをフェッチし、すぐ特定のブランチにチェックアウトする
• リポジトリをクローンし、1 つのブランチだけをフェッチする

方法その 1

git clone --branch <branchname> <remote-repo-url>

または

git clone -b <branchname> <remote-repo-url>

上記の -b は --branch のエイリアスです。

このコマンドにより、リポジトリ内のすべてのブランチをフェッチし、<branchname> に指定したブランチにチェックアウトし、指定したブランチが、git push と git pull の設定がされたローカルブランチになります。しかしこのやり方では、まだ各ブランチから全てのファイルをフェッチしています。やりたいこととは少し違うようですね。

試してみましょう。

 git clone -b passwordless-auth git@github.com:BolajiAyodeji/nextjs-blog.git

このコマンドにより、passwordless-auth がローカルブランチに設定されますが、まだ他のブランチが追跡されています。

方法その 2

git clone --branch <branchname> --single-branch <remote-repo-url>

または

git clone -b <branchname> --single-branch <remote-repo-url>

上記の -b は --branch のエイリアスです。

このコマンドはほとんど方法その 1 と同じことを実行しますが、Git バージョン 1.7.10 以降で導入された --single-branch オプションを使用しています。このオプションにより、他のブランチをフェッチせず、指定のブランチのファイルだけをフェッチすることができます。

試してみましょう。

git clone -b passwordless-auth --single-branch git@github.com:BolajiAyodeji/nextjs-blog.git

このコマンドにより passwordless-auth がローカルブランチに設定され、このブランチだけを追跡している状態になります。

cd pages/api コマンドを実行すると、前述した passwordless-auth ブランチの auth.js ファイルを見つけることができます。

結論

インターネットの帯域やストレージの空き容量が少ない中で、特定のブランチの作業をしたい状況もあるでしょう。他にもさまざまな理由で、ファイルを限定して特定のブランチをクローンしたいことがあるかもしれません。幸い、Git はそれを実現できる柔軟性を持っています。まずは肩ならしにこの記事で学んだことを試してみましょう。Git について学ぶことはまだまだあります。

ここから一つずつ学んでいきましょう。

通常、Git ブランチの削除は簡単です。この記事ではローカルまたはリモートの Git ブランチを削除する方法を学びます。

TL;DR バージョン

// ローカルのブランチを削除する場合
git branch -d localBranchName

// リモートのブランチを削除する場合
git push origin --delete remoteBranchName

ブランチはいつ削除するか

Git リポジトリに複数のブランチがあるのは普通のことです。ブランチは、新しいコードをメインのコードベースから隔離した状態で異なる機能や修正の作業をするための良い方法です。

リポジトリにはメインのコードベース用の main ブランチがあることが多く、開発者は異なる機能の作業をするために別のブランチを作成します。

多くの場合、ある機能の作業が完了したら、そのブランチを削除することが推奨されます。

ローカルのブランチを削除する

Git では現在のブランチを削除することはできません。そのため、削除対象以外のブランチに切り替える (チェックアウトする) 必要があります。

例: git checkout main

ブランチの削除は git branch -d <branch> で実行します。

例: git branch -d fix/authentication

-d オプションは、削除対象のブランチがリモートブランチにプッシュおよびマージ済みの場合のみ削除を実行します。プッシュ、マージされていないブランチを強制的に削除したい場合は、代わりに -D を使用します。

これでローカルのブランチが削除されました。

リモートのブランチを削除する

こちらがリモートのブランチを削除するコマンドです。

git push <remote> --delete <branch>

例: git push origin --delete fix/authentication

これでリモートのブランチが削除されました。

こちらの、より短いコマンドでもリモートブランチを削除できます。

git push <remote> :<branch>

例: git push origin :fix/authentication

下記のエラーが発生した場合、すでに他の誰かがそのブランチを削除した可能性があります。

error: unable to push to unqualified destination: remoteBranchName The destination refspec neither matches an existing ref on the remote nor begins with refs/, and we are unable to guess a prefix based on the source ref. error: failed to push some refs to 'git@repository_name'

下記のコマンドであなたのブランチ一覧を同期してみましょう。

git fetch -p

-p フラグは "prune" (取り除く) を意味します。フェッチ実行後、リモートに存在しないブランチは、ローカルからも削除されます。

このチュートリアルがお役に立ちましたら、ぜひ周りにも共有してください😉

英語版ではこのような記事を 8,000 件以上無料で公開しています。日本語、他言語も順次対応中です。