目的

Trac+Subversion, Redmine+Subversion/Git, GitLab CE などを時代に合わせてオンプレで運用してきたが、サーバーの管理・維持などの関係もあり、Trac+Subversion は廃止し、GitLab あるいは Redmine+Git に移行したくなってきた。

ところで、10年以上前に、CVS で運用していたリポジトリーを cvs2svn¹ により SVN に移行したことがあるが、この記事を書くのにGitHubに移行されたものを見ると、SVN だけでなく Git/Mercurial/Bazaar にも移行できるっぽい。VSS=Microsoft Visual SourceSafeで運用していたリポジトリーは闇に葬った…。（余談）

参考

• Pro Git book - 9.2 Gitとその他のシステムの連携 - Git へ移行する
• git-svnでSVN→Gitへの移行をやってみたログ

基本的に Pro Git book の手順や上記 Qiita 記事やブログ記事などで見つかるもので良いと思うのだが…

実際の移行とハマったところなどを記載していく。

SVNディレクトリー構成

いわゆるtrunk,branches,tagsのスタンダードレイアウト。基本的にこれで運用していたので良かった。もちろんプロジェクト毎に別のSVNリポジトリーとして分離していた。

たとえば、 Apache Software Foundationの様に全社のプロジェクトが同一SVNリポジトリーにフラットにぶら下がっている様なものや、trunk,branches,tagsを使わない独自形式だと、git svnのオプション指定も異なってくるはず。

環境

あんまり関係なさそうだけど一応。

• 移行元: Subversion
  • CentOS 7 + Subversion 1.7.14 (r1542130) (標準 RPM package)
• 移行作業: git-svn
  • macOS 10.15.5 + git-svn 2.27.0 (svn 1.10.4) (brew版 git)
• 移行先: Git
  • CentOS7 + GitLab CE 13.1.4 (Omnibus package版)

移行手順

生SVNリポジトリーの入手

外部のSVNホスティングサービス利用ならまだしも、自分がSVNサーバー管理者だっり、他のSVN管理者でもgit-svnで移行するということならその管理者の協力が得られるはずなので、生のSVNリポジトリーをローカルにコピーして作業するのが良いと思われる。

Pro Git Bookや各種記事には次のようなコマンド例があり（時代的に2016に終了した、Google Code²のSVNからの移行でしょうか？）

$ git svn clone http://my-project.googlecode.com/svn/ \
      --authors-file=users.txt --no-metadata -s my_project

この、http(WebDAV)のリモートからの取得で失敗することが多いので、git svn init してから git svn fetch し、失敗した場合そのリビジョンから git svn fetch -r1234:HEAD にて再開するという記事が多いですが、生のリポジトリーが入手できるなら、ローカルで完結させたほうが絶対楽です。いまだにcommitされ生きているSVNリポジトリーならこの限りではないですが…結局どこかのタイミングで運用停止して変換するでしょうし…

以下、/var/lib/svn/myproj にSVNプロジェクトがあるものとして話をすすめます。

authors 一覧ファイルを作る

ここは基本的に Pro Git Book の通りです。

SVN は http などの認証ユーザー名が Author になるが、Git の場合は、 user.name と user.email が Author になるのでその変換テーブルが必要。

いや、cvs2svn なんかで変換した年代物のリポジトリーなんて、遠い昔にそんなヤツいた？ってのをみんなに聞いたり、誰かを辿るのにすごく時間がかかる面倒くさい作業。まあ、わからなければ適当な名前とメールアドレスを入れちゃえばよいのですが…。

チェックアウト

$ svn checkout file:///var/lib/svn/myproj myproj-svn

抽出

$ cd myproj-svn
$ svn log --xml | grep author | sort -u | \
  perl -pe 's/.*>(.*?)<.*/$1 = /' > /tmp/myproj-authors.txt

username1 =
username2 =
.
.

というファイルができるので

username1 = Taro Yamada <taro@example.com>
username2 = Hanako Toire <hanako@example.com>
.
.

svn checkout したワーキングコピーはAuthor一覧を抽出するだけなのでここで消しても良い。

実際の移行

いろいろなところに書かれている事例の通り、自分もhttps://でやったことがあるがリビジョン数やタグ・ブランチの少ないテスト用のリポジトリーでは成功するが、実運用しているリポジトリーに関しては何度も失敗しました。前に書いたとおり、ローカルに持ってきて、file:///でやるとネットワークの影響がなく成功しているのか？しかし、ローカルでもとても時間がかかります。

$ git svn init file:///var/lib/svn/myproj/ --no-metadata -s myproj
$ cd myproj
$ git svn fetch --authors-file=/tmp/myproj-authors.txt

--no-metadata はcommit logにgit-svn-idを付与しないためにつけています。そもそも、file:///var/lib/svn/myproj/とローカルのリポジトリを指定しているのでgit-svn-idにローカル情報が見えてかっこ悪くなるし、そもそもGit移行後は不要な情報と自分は判断しました。

タグとブランチの変換

Pro Git bookでは、

タグを Git のタグとして扱うには、次のコマンドを実行します。
次に、refs/remotes 以下にあるそれ以外の参照をローカルブランチに移動します。

と言うところの方法として、.git/ディレクトリの中をcp,rmにて操作しているが、自分の環境ではこれで失敗しました（24時間以上変換にかかったGitリポジトリーをバックアップ取らずに台無しに…）。ちょっと情報元のスニペットのリンクは失念したけど、次の方法で成功しました。

ブランチ

$ for BRANCH_NAME in $(git branch -r | grep -ve 'origin/tags\|origin/trunk\|.*@\d*' | sed -e 's:origin/::'); do
    git checkout -b "$BRANCH_NAME" "origin/$BRANCH_NAME"
done;
$ git checkout master

タグ

$ for TAG_NAME in $(git branch -r | grep -e 'origin/tags' | grep -ve '.*@\d*' | sed -e 's:origin/tags/::'); do
  git tag "$TAG_NAME" "origin/tags/$TAG_NAME"
done

リモートリポジトリーへのpush

こちらは、普通の方法。GitLabにpushしたが何でも良いかと。

$ git remote add origin git@gitlab.example.com:mygroup/myproj.git
$ git push -u origin --all
$ git push -u origin --tags

つづく

SVNのリポジトリー形式により、変換したGitリポジトリーを更に変換操作した場合もあったので、その点を書くかも。

---

1. 2020-07-01に閉鎖につきWebArchiveのリンク ↩

2. Bidding farewell to Google Code ↩

目的

Trac+Subversion, Redmine+Subversion/Git, GitLab CE などを時代に合わせてオンプレで運用してきたが、サーバーの管理・維持などの関係もあり、Trac+Subversion は廃止し、GitLab あるいは Redmine+Git に移行したくなってきた。

ところで、10年以上前に、CVS で運用していたリポジトリーを cvs2svn¹ により SVN に移行したことがあるが、この記事を書くのにGitHubに移行されたものを見ると、SVN だけでなく Git/Mercurial/Bazaar にも移行できるっぽい。VSS=Microsoft Visual SourceSafeで運用していたリポジトリーは闇に葬った…。（余談）

参考

• Pro Git book - 9.2 Gitとその他のシステムの連携 - Git へ移行する
• git-svnでSVN→Gitへの移行をやってみたログ

基本的に Pro Git book の手順や上記 Qiita 記事やブログ記事などで見つかるもので良いと思うのだが…

実際の移行とハマったところなどを記載していく。

SVNディレクトリー構成

いわゆるtrunk,branches,tagsのスタンダードレイアウト。基本的にこれで運用していたので良かった。もちろんプロジェクト毎に別のSVNリポジトリーとして分離していた。

たとえば、 Apache Software Foundationの様に全社のプロジェクトが同一SVNリポジトリーにフラットにぶら下がっている様なものや、trunk,branches,tagsを使わない独自形式だと、git svnのオプション指定も異なってくるはず。

環境

あんまり関係なさそうだけど一応。

• 移行元: Subversion
  • CentOS 7 + Subversion 1.7.14 (r1542130) (標準 RPM package)
• 移行作業: git-svn
  • macOS 10.15.5 + git-svn 2.27.0 (svn 1.10.4) (brew版 git)
• 移行先: Git
  • CentOS7 + GitLab CE 13.1.4 (Omnibus package版)

移行手順

生SVNリポジトリーの入手

外部のSVNホスティングサービス利用ならまだしも、自分がSVNサーバー管理者だっり、他のSVN管理者でもgit-svnで移行するということならその管理者の協力が得られるはずなので、生のSVNリポジトリーをローカルにコピーして作業するのが良いと思われる。

Pro Git Bookや各種記事には次のようなコマンド例があり（時代的に2016に終了した、Google Code²のSVNからの移行でしょうか？）

$ git svn clone http://my-project.googlecode.com/svn/ \
      --authors-file=users.txt --no-metadata -s my_project

この、http(WebDAV)のリモートからの取得で失敗することが多いので、git svn init してから git svn fetch し、失敗した場合そのリビジョンから git svn fetch -r1234:HEAD にて再開するという記事が多いですが、生のリポジトリーが入手できるなら、ローカルで完結させたほうが絶対楽です。いまだにcommitされ生きているSVNリポジトリーならこの限りではないですが…結局どこかのタイミングで運用停止して変換するでしょうし…

以下、/var/lib/svn/myproj にSVNプロジェクトがあるものとして話をすすめます。

authors 一覧ファイルを作る

ここは基本的に Pro Git Book の通りです。

SVN は http などの認証ユーザー名が Author になるが、Git の場合は、 user.name と user.email が Author になるのでその変換テーブルが必要。

いや、cvs2svn なんかで変換した年代物のリポジトリーなんて、遠い昔にそんなヤツいた？ってのをみんなに聞いたり、誰かを辿るのにすごく時間がかかる面倒くさい作業。まあ、わからなければ適当な名前とメールアドレスを入れちゃえばよいのですが…。

チェックアウト

$ svn checkout file:///var/lib/svn/myproj myproj-svn

抽出

$ cd myproj-svn
$ svn log --xml | grep author | sort -u | \
  perl -pe 's/.*>(.*?)<.*/$1 = /' > /tmp/myproj-authors.txt

username1 =
username2 =
.
.

というファイルができるので

username1 = Taro Yamada <taro@example.com>
username2 = Hanako Toire <hanako@example.com>
.
.

svn checkout したワーキングコピーはAuthor一覧を抽出するだけなのでここで消しても良い。

実際の移行

いろいろなところに書かれている事例の通り、自分もhttps://でやったことがあるがリビジョン数やタグ・ブランチの少ないテスト用のリポジトリーでは成功するが、実運用しているリポジトリーに関しては何度も失敗しました。前に書いたとおり、ローカルに持ってきて、file:///でやるとネットワークの影響がなく成功しているのか？しかし、ローカルでもとても時間がかかります。

$ git svn init file:///var/lib/svn/myproj/ --no-metadata -s myproj
$ cd myproj
$ git svn fetch --authors-file=/tmp/myproj-authors.txt

--no-metadata はcommit logにgit-svn-idを付与しないためにつけています。そもそも、file:///var/lib/svn/myproj/とローカルのリポジトリを指定しているのでgit-svn-idにローカル情報が見えてかっこ悪くなるし、そもそもGit移行後は不要な情報と自分は判断しました。

タグとブランチの変換

Pro Git bookでは、

タグを Git のタグとして扱うには、次のコマンドを実行します。
次に、refs/remotes 以下にあるそれ以外の参照をローカルブランチに移動します。

と言うところの方法として、.git/ディレクトリの中をcp,rmにて操作しているが、自分の環境ではこれで失敗しました（24時間以上変換にかかったGitリポジトリーをバックアップ取らずに台無しに…）。ちょっと情報元のスニペットのリンクは失念したけど、参考として載せたgit-svnでSVN→Gitへの移行をやってみたログの次の方法で成功しました。

ブランチ

$ for BRANCH_NAME in $(git branch -r | grep -ve 'origin/tags\|origin/trunk\|.*@\d*' | sed -e 's:origin/::'); do
    git checkout -b "$BRANCH_NAME" "origin/$BRANCH_NAME"
done;
$ git checkout master

タグ

$ for TAG_NAME in $(git branch -r | grep -e 'origin/tags' | grep -ve '.*@\d*' | sed -e 's:origin/tags/::'); do
  git tag "$TAG_NAME" "origin/tags/$TAG_NAME"
done

リモートリポジトリーへのpush

こちらは、普通の方法。GitLabにpushしたが何でも良いかと。

$ git remote add origin git@gitlab.example.com:mygroup/myproj.git
$ git push -u origin --all
$ git push -u origin --tags

つづく

SVNのリポジトリー形式により、変換したGitリポジトリーを更に変換操作した場合もあったので、その点を書くかも。→ いまさらだけどSubversionからGitへ移行する（その２）

---

1. 2020-07-01に閉鎖につきWebArchiveのリンク ↩

2. Bidding farewell to Google Code ↩

1.目的

最近、GCP上でcloud shellからGSRへのadd, commit, pushといった基本的な一連の流れはだいぶ慣れてきたものの、実際の開発はjupyter Labとかでやることも多いから、cloud shellからじゃなくてJupyter Labからpushできると便利だなと思い、基本の流れをまとめました。

具体的には、GCPのAI Platformからノートブックを立ち上げます。

2.早速やってみよう

(1)先にリポジトリを作っておく

「Qiita」というリポジトリをGSR上で作り、「test.txt」を事前にcloud shellからpushしておきました。
（下記はGSRのQiitaリポジトリの画面）

(2)Jupyter Labの立ち上げ

GCPのハンバーガーメニュー（左側のメニュー）から「AI Platform」を選択。
※私はピン止めしているので上の方に出てきますが、実際は結構下の方にあります。

その後、ノートブックを選択し、インスタンスを作成します。
※私はリージョンはasia-northeastにしています。

(3)ディレクトリの作成

下記のように、新しいフォルダを作っておきます。
今回はQiita_notebookというディレクトリを手動で作っておきました。
※clone_jupyterというディレクトリは別途私が個人的に作っているだけなので、無視してください。

(4)Git用のnotebookを作成→GSRからクローンする

(3)で作成したQiita_notebookディレクトリ内にnotebookを作ります。
今回は「Qiita.ipynb」です。

このnotebook内で、下記のようにコマンドを打っていきます。

①初期設定
ここは通常のGitと同じ流れです。

②クローン
GSRのQiitaリポジトリをクローンします

→これを実行すると、上のキャプチャの③のように、突如ぽこっと「Qiita」リポジトリがクローンされます

(5)テキストファイルを修正してみる

Qiitaリポジトリに移動し、test.txtを開き、下記のように追記
→保存して閉じておきます。

※ここが、実際は開発時にコードを修正しているイメージです。

(6)Qiita.ipynbをQiitaリポジトリ内に移動

手動になりますが、今はQiitaリポジトリの外にいるQiita.ipynbをCutして、QiitaリポジトリにPasteしておきます。
※こうしないと、この後pushができませんでした。

(7)いよいよ、pushしていく

下記のようにコマンドを打つと、GSRへpushされます！

(8)GSRで確認

無事にjupyter Labからpushできていました！

3.結び

いかがでしたでしょうか。
私はGitの学習をし始めたのが最近なので、jupyter lab(notebook)からpushできることを知りませんでした。
この後はブランチやマージ、コンフリクトの解消についても学習し投稿していきたいと思います！

初投稿！

非常に感動した内容だった為、備忘録！

ブランチを切って作業をしていると、マージするまでの間にmasterに追加された更新で表示が変わってしまったり、コンフリクトするようになってしまいますよね。
それを防止するためには定期的にブランチにマスターの内容を反映させる必要があります。
その方法をメモ。

1. 反映したいブランチに切り替える

作業してるディレクトリ%　git checkout ブランチ名

２. マスターの内容をブランチに反映させる

作業してるディレクトリ%　git merge master

以上

参考にさせていただいたサイトhttps://hacknote.jp/archives/11191/

参考記事

• https://qiita.com/uasi/items/69368c17c79e99aaddbf

大変参考になりました?‍♂️

想定読者

• 上流ブランチ？
• 追跡ブランチ？
• リモート追跡ブランチ？

こんな人。三時間前の私である。

用語解説

上流ブランチ

ローカルブランチが、更新を追いかけるローカルにあるブランチのこと。（一見、無駄に見えますが次の「リモート追跡ブランチ」が理解できればわかると思います。）

ではでは、例を出していきます。

$ git remote
origin

これでリモートリポジトリが分かります。今回はoriginリポジトリが登録されています。

$ git branch
* master

これでローカルブランチが分かります。ワークツリーと近いところですね。今回はmasterにいますね。

$ git branch -vv
* master a4fd79e [origin/master] first commit

はい、これが問題の上流ブランチです。こいつがローカルブランチから見たときの上流ブランチです。ローカルのmasterブランチが、この上流ブランチの更新を追いかけています。

リモート追跡ブランチ

はい、リモート追跡ブランチはorigin/masterのことです。

、、、は？と思いましたね。そうなんです。ここが混乱しやすいところなんですよ。解説していきます。

まず、リモートにはoriginリポジトリがありますよね。そしてその中にはmasterというリモートブランチがあります。この更新を追いかけているのがリモート追跡ブランチ（origin/master）なのです。つまりはこういうこと。

• ローカルブランチ（master）は上流ブランチ（origin/master）を監視している。
• リモート追跡ブランチ（origin/master）はリモートブランチ（master）を監視している。

こういうことなのです。ではではその更新するコマンドを見ていきましょう

git fetch

これは、origin/master（リモート追跡ブランチ）がリモートブランチ（master）の内容を元に更新されるということです。だから特に手元のファイル内容が変わるわけではありません。（ローカルブランチが変わるわけではないからね。）

git merge

こちらは、上流ブランチ（origin/master）の内容を元にローカルブランチ（master）を更新するということです。

ちなみに、この二つを合わせたのが、git pull

間違ってたらごめん。

こんな人におすすめ

『あああコミットしたけど元にもどしたいなー』『マージしたけどブランチ内で昔の履歴みたいなー』
なんて時、履歴を見て、ささっと取り消してしまいましょう。

環境

ruby 2.5.1
Rails 5.0.7.2

手順

１）自分がいるブランチのコミットログを調べる

git log

こういうのが出てきます。

ユーザー名@ユーザー名noMacBook-Pro アプリケーション名 % git log
commit 8af1dXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (HEAD -> 今いるブランチ名, origin/今いるブランチ名)
Author: ユーザー名 <メールアドレス>
Date:   Sun Jul 12 15:28:51 2020 +0900

    コミットした時のコメント

commit 239b0XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Author: ユーザー名 <メールアドレス>
Date:   Thu Jun 25 23:36:58 2020 +0900

    コミットした時のコメント

commit ed8ccXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Author: ユーザー名 <メールアドレス>
Date:   Thu Jun 25 17:31:52 2020 +0900

    コミットした時のコメント

２）戻したい場所のハッシュ値を確認

commit ed8ccXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

３）リセットする

git reset --hard ed8ccXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

完了done！

はじめに

Macを初期化すると、git branchしたとき、

* develop
  master
(END)

というように結果がページャ（lessコマンドなどのようにページ送りできる昨日）で表示されるようになっていた。

おそらくgitのバージョンが変わったためだと思われるが、
もともと

± % git branch                                                             !542
* develop
  master

といった感じでcatしたみたいにコマンドの下に結果を表示してくれる設定に慣れていたので、その設定に戻した。

個人的にこの設定方法を見つけにくかったので、メモをここに残しとく

設定方法

gitconfigのpage.branchで設定できるようなので、

git config --global pager.branch cat

とするか

直接~/.gitconfigに

[pager]
        branch = cat

と書いてしまえばOK

参考

• Git の branch とかが less になるのをやめたい

環境

• Windows10 64bit
• Git-2.27.0-64-bit

WindowsでVScode+PowerShellで使う位の意図で環境構築しています。

インストーラの入手

https://gitforwindows.org/
DownLoadをクリックしてexeを落とす。
本記事では以降 Git-2.27.0-64-bit.exe のインストール手順です。

インストーラの実行

先ほど落としたexeを実行。
「このアプリがデバイスに変更を加えることを許可しますか？」と聞かれるので「はい」を選択。

インストーラ起動後、ライセンス同意

同意するなら Next > を押下。

インストール先の指定

特に拘りがなければ初期設定のまま Next > を押下。

コンポーネント選択

デフォルトではWindows Explorer integrationが有効になっているが、これはファイル/フォルダの右クリックからgitを使えるようにするもの。不要なら外してよいと思います。
それ以外はおよそデフォルトでOKのはず。

スタートメニューへの追加

スタートメニューへのGit追加を選択できます。
こちらもデフォルトで良いと思います。

gitを使用するエディタの選択

使用するエディタのものを選択すればよいかと思います。
私はVScodeを使っているのでVScodeにしています。

環境変数

PowerShellなどから使用できれば良いのでデフォルトのまま。

SSLライブラリ選択

詳しく知りませんがデフォルトで使用しています。（気が向いたら真面目に調べて追記します）

改行コード

コミット時にさえ修正してくれていればよいので真ん中を選択しています。

コンソールの選択

今回windowsのコンソールから使いたかったのでwindows標準のコンソールを選択。

git pull 時の動作選択

デフォルトのまま Next >

オプションの設定

今回シンボリックリンク有効にしましたが、デフォルトでもよいと思います。

Pseudo Console(UNIX疑似端末)のサポート

まだバグがあるかもね、とあるのでそのままにしてInstall。

インストール

しばらく待つとこの画面になればインストール完了です。

はじめに

Pull Requestについて「プルリクを送る相手側のアカウントも必要」だと思っていませんか？
プルリクは自分のGitHubのアカウントだけで手軽に行なえます。
5分程度で終わるので「プルリクが分からないから怖い」という方は是非やってみて下さい。

対象ユーザ

• gitを始めてばかりの人
• はじめてPull Requestをする/したい人
• 仕事やインターンでする必要が出た人
• その他、gitを使っている人など

準備

Githubのアカウントがなければできないのでこちらから作成してください。
gitの導入などは他サイトを参照してください。

リポジトリを作成する

https://github.com/[ユーザー名]?tab=repositories
から右上のNEWを押下。
Create a new poresitory で新しくリポジトリを生成します。
この時、Initialize this repository with README にチェックを入れて下さい。
今回はこれを編集して「自分で自分にプルリクを送って、自分で承認してマージする」という手順を踏みます。

自分のリポジトリに「自分のユーザ名/[自分できめた名前。ここではAtCoder]」というリポジトリができたと思います。

以下、スクショに従ってやっていきます。

1.README．MDの編集

README.mdの編集[鉛筆マーク]をクリック

2.編集を保存してプルリク用のブランチを生成

README.mdの中身を編集して、Commit directory to the master branch.の方ではなく
Create a new branch for this commit and start pull request.のラジオボタンをチェック。
ここで[ユーザー名]-patch-1というbranchが生成されます。
Propose changes を押下。

3.自分宛てにプルリクエストを生成

マスターブランチに対して、
base:master ← compare:[ユーザー名]-patch-1
というブランチの内容を送るから、確認してマージして下さい～という依頼を生成します。
適切なタイトルと詳細を書いた後、Create pull requestボタンを押下。
※変更点は下部に書いてあります。

4.相手からプルリクが送られてきました。

相手からプルリクエストが送られてきた画面に遷移します。
上のタブを見ると、Pull requests 1 となっているのが分かりますね。
This branch has no conflicts with the base branch.となっているので、
今回は直接マージしても問題ありませんよ、と言う意味になります。
Merge pull requestを押下。

5.相手のプルリクの内容を確認してマージの確認

プルリクしてきた相手の内容を確認して、現在のリポジトリに変更点があるbranchをマージするかどうか判断します。
今回は自分でやっていて問題ありませんのでConfirm Mergeを押下。

6.相手のプルリクを承認してリクエストを取り込んでマージ成功

これで、相手からリクエストが来たマージが成功した画面に遷移します。
Pull request successfully merged and closed の右側に Delete branch ボタンがあります。
今回は相手のbranchを残す必要がないのでDelete branchを押下。

7.完了

README．MDが新たに変更されているのが分かります。これで
・相手にプルリクを送る
・相手から来たプルリクを承認してマージする
双方の作業が完了しました！

おわりに

何か改善点などあればコメントにてご教授お願いします！

なぜgit switchを使うか？

オシャレだからです

結論

以下コマンドを打ちます。
originなどのリモートブランチを指定しないのがポイントです。

$ git fetch
$ git switch feature/branch01

何をしたか

feature/branch01というブランチで、(例えば)GitHub上にプルリクが作られています。
そのプルリクのレビューをするために、手元(ローカル)で色々確認したいとします。

$ git fetch  #まずはリモートから取得
$ git switch origin/feature/branch01  #そのリモートブランチにswitchしたい
fatal: a branch is expected, got remote branch 'origin/feature/branch01'

え、何このエラー
試しにgit checkoutの方でやります

$ git checkout origin/feature/branch01
Note: switching to 'origin/feature/branch01'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

チェックアウトできたけど、よく見ると「HEADがdetached状態だよ」と警告されてますね

参考: detached HEAD から脱出する方法を git の内部構造から探る

調べた

そもそも、検索した限りでこの方法でリモートブランチを確認する人間はいなかったです。笑

• この方法ではリモートのorigin/feature/branch01にあるコミットを直接参照している
• よって、トラッキングもattachもされていない
• よって、この中で例えば変更を行うと、リモートブランチへの反映は面倒
• よって、普通はこの方法ではなくローカルブランチにトラッキング・attachさせる方法を使う(推測)
• よって、git switchではこの方法でのチェックアウトは想定されていない(推測)
• よって、エラーとなった

のようです。

それで、普通はどう行うのかというと、以下の方法です。

$ git branch feature/branch01 origin/feature/branch01  #リモートブランチからattachさせたローカルブランチを作成し、
$ git checkout feature/branch01  #そのローカルブランチにチェックアウトします(`git switch`でも可能)

ただ、こんな面倒なコマンドを打たないためのショートカットはいろいろあります。
下記のサイトが参考になりました。

参考: git checkout -t でちょっと幸せになれる

結論としては、リモートブランチを(origin)を指定せずにgit checkoutしてしまえば良いみたいです。

やってみた

$ git checkout master  #一回masterに戻り、
$ git branch -D feature/branch01  #前項目で作ったブランチを一度消します
$ git checkout feature/branch01  #attachされたローカルブランチを作って、さらにチェックアウトします
Updating files: 100% (123/123), done.
Branch 'feature/branch01' set up to track remote branch 'feature/branch01' from 'origin'.
Switched to a new branch 'feature/branch01'

できました。
ちなみにgit switchでやっても同じ結果でした。

$ git switch master
$ git branch -D feature/branch01
$ git switch feature/branch01
Updating files: 100% (123/123), done.
Branch 'feature/branch01' set up to track remote branch 'feature/branch01' from 'origin'.
Switched to a new branch 'feature/branch01'

(再度)結論

以下コマンドを打ちます。
originなどのリモートブランチを指定しないのがポイントです。

$ git fetch
$ git switch feature/branch01

感想

個人的には、確認したいだけなのにローカルブランチが作られるのは微妙じゃないか？と思ってます。
レビューが終わった後にいちいちローカルブランチ消すの面倒だし・・・
ご指摘お待ちしております。

参考

fatal: a branch is expected, got remote branch 'origin/feature/branch01'

このエラーで調べると下記質問が出てきました。やはり-cオプションでattachさせるやり方を推奨しています。
https://stackoverflow.com/questions/58124219/how-can-i-use-the-new-git-switch-syntax-to-create-a-new-branch

社内のGitHub Enterpriseは使ったことがあったのですが、
OSSにコミットするのは初めてだったので、手順をまとめてみました。

自分がコミットしたのはblikiの日本語訳(bliki-ja)で、記事をひとつ翻訳しました。

お目当てのリポジトリをフォークする

右上の「Fork」ボタンを押すだけです。

フォークしたリポジトリのページが表示されるはずなので、ここをクリックしてURLを取得します。

ローカルにGit Clone

ここからは基本的にはEnterpriseと同じです。

git clone https://github.com/ko-flavor/bliki-ja.github.io.git ./bliki-ja

変更してプッシュ

プルリクエスト作成

リモートにプッシュすると、自動的にPRを作成するボタンが表示されます。Enterpriseと同じですね。

ぽちと押すと、PRを作れます。

この図のようにフォークした自分のリポジトリからもとのリポジトリに向き先が向いていればOKです。
PRを作り、あとはレビューやマージを待ちましょう。

雑感

• 思ったより複雑じゃなくてよかった、、というかEnterpriseとほとんど同じですね。
• 今回は省略しちゃいましたが、リモートからfetchしたいときなどはupstreamとして元のリポジトリも登録する必要があるようです。
  • つまり、今回のやつは自分がforkする～コミット完了までコミットが無い前提だったりします。
• ちなみに、翻訳したぺージはこちらです(DDDにおける集約)。よかったら見てみてください。