PowerShell从GitHub保存Unity项目并整理Git与GitHub CLI的区别

在整理完过去的Unity项目后，我继续推进将其保存到GitHub私有仓库的工作。

最初，

GitHubへ上げる
=
git pushする

我对它的理解仅限于此。

然而，在实际操作过程中，我发现

Git
GitHub
GitHub CLI
PowerShell

各自扮演着不同的角色。

本次，我将基于实际使用的命令，

ローカルでGit管理する
↓
GitHubにリポジトリを作る
↓
GitHubへpushする

梳理一下流程。

首先，Git 和 GitHub 是不同的

这次最让我理清的就是这部分了。

Git 是用于在个人电脑内管理文件变更历史的机制。

而 GitHub 则是能够将 Git 仓库保存在网络上并共享的服务。

也就是说，

Git
→ ローカルPC上で履歴を管理する

GitHub
→ Gitリポジトリをネット上に保存する

存在这样的差异。

此外，本次使用的 gh 是 GitHub CLI 这一工具。

它允许通过 PowerShell 等命令行界面执行在 GitHub Web 界面上进行的操作。

PowerShell 是执行这些操作的环境

例如，

PS C:\Users\User>

在显示为的 PowerShell 上，

git init

呀、

gh repo create...

正在执行。

也就是说，

PowerShell
↓
Gitのコマンドを実行する

PowerShell
↓
GitHub CLIのコマンドを実行する

这样的关系。

它们全都显示在PowerShell上，所以起初看起来像是同一个东西，但实际上调用的是不同的程序。

git init 开始使用 Git 管理

首先使用的就是，

git init

此命令是，

現在のフォルダを
Gitで管理するリポジトリにする

也就是说。

执行后，在该文件夹内，

.git

会创建一个名为“という”的隐藏文件夹。

在这个 .git 中，会保存 Git 的历史记录和设置等。

此时GitHub上还没有创建任何内容。

仅仅是，

PCの中でGit管理を開始した

而已。

git add. 作为提交目标

接下来，

git add.

执行了。

这是，

現在のフォルダ以下にある変更を
次のコミット対象として登録する

这个意思。

最后的，

.

表示当前文件夹。

因此，

git add.

是，

現在のフォルダ以下をまとめて対象にする

这样的指定。

.gitignore 中排除不必要的文件

对于Unity项目，并非所有文件都需要保存到GitHub。

例如，

Library
Temp
Logs
obj

等都可以由Unity端重新生成。

因此，在 .gitignore 中，

[Ll]ibrary/
[Tt]emp/
[Oo]bj/
[Ll]ogs/
UserSettings/
MemoryCaptures/

[Bb]uild/
[Bb]uilds/

.vs/
.vscode/
.idea/

*.csproj
*.sln

等进行了编写。

由此，即使执行 git add.，这些文件也不会被纳入Git管理范围。

本次希望保存到GitHub的核心内容是，

Assets
Packages
ProjectSettings

。

git commit 作为历史记录进行保存

接下来，

git commit -m "Initial commit"

を実行した。

これは、

git addで選んだ変更を
Gitの履歴として保存する

という意味。

-m

はコミットメッセージを指定するオプション。

今回は最初の保存だったので、

Initial commit

とした。

到此为止，

git init
git add.
git commit -m "Initial commit"

即使执行了，也还没有向 GitHub 发送任何内容。

到目前为止，全部都是本地PC上的Git操作。

git branch -M main 统一分支名

接下来，

git branch -M main

使用了。

这是将当前分支名称更改为

main

的命令。

在某些环境下，初始分支名可能是 master。

本次为了与 GitHub 保持一致，我将其设为 main。

在 GitHub 上创建仓库

此时才会首次出现 GitHub 侧的操作。

使用的是 GitHub CLI，

gh repo create <repo-name> --private

该命令是，

GitHub上に
新しいPrivateリポジトリを作る

的意思。

在浏览器中，

New repository
↓
名前を入力
↓
Privateを選択
↓
Create repository

正在通过命令行执行原本的操作。

git remote add origin 用于注册与 GitHub 的连接

仅在 GitHub 侧创建仓库，还无法与本地 Git 建立连接。

因此，

git remote add origin https://github.com/<owner>/<repo-name>.git

使用。

这是，

このGitHubリポジトリを
ローカルGitの送信先として登録する

也就是说。

这里的，

origin

是远程仓库的名称。

通常将第一个远程仓库称为 origin。

如果已经存在 origin

在以前的项目中，可能已经注册了另一个 GitHub 仓库。

在这种情况下，

git remote add origin...

而不是

git remote set-url origin https://github.com/<owner>/<repo-name>.git

使用了。

这是，

既存のoriginのURLを
新しいGitHubリポジトリへ変更する

也就是说。

git push -u origin main 发送到GitHub

最后，

git push -u origin main

已执行。

これは、

ローカルのmainブランチを
originとして登録したGitHubへ送る

という意味。

分けると、

git push
→ GitHubへ送る

origin
→ 送信先

main
→ 送るブランチ

になる。

さらに、

-u

を付けることで、

ローカルのmain
↓
origin/main

这种对应关系也会被注册。

因此，从下次以后，

git push

即使只有这些也能发送了。

整体流程

把以上内容排列起来，

Unityプロジェクト
↓
git init
Git管理を開始

↓

git add.
コミット対象にする

↓

git commit
ローカルGitに履歴として保存

↓

gh repo create
GitHub側にPrivateリポジトリを作る

↓

git remote add origin
ローカルGitとGitHubを接続する

↓

git push
GitHubへ履歴を送る

会形成这样的流程。

最初，我打算将所有内容一并处理，

GitHubにアップロードする処理

但事实上，它们各自承担着不同的角色。

gh repo view 用于确认仓库是否存在

在自动上传多个项目时，

すでにGitHubにあるものは飛ばしたい

便产生了这样的需求。

因此，

gh repo view "<owner>/<repo-name>"

使用了。

这是显示指定GitHub仓库信息的命令。

如果仓库存在，则成功。

在自动处理中，

gh repo view "<owner>/<repo-name>" *> $null

进行了如下操作。

*> $null

是，

画面への出力を捨てる

という意味。

今回は中身を表示したいのではなく、

存在するかどうかだけ知りたい

ために使った。

$LASTEXITCODE で成功・失敗を確認する

git や gh はPowerShellの外部プログラム。

実行結果は、

$LASTEXITCODE

可以在此确认。

一般来说，

0
→ 成功

0以外
→ 失敗

可视为。

例如，

gh repo view "<owner>/<repo-name>" *> $null

if ($LASTEXITCODE -eq 0) {
    Write-Host "すでに存在します"
}

如果是，

GitHubリポジトリが存在したら
「すでに存在します」と表示する

则成为这样的处理。

gh repo list 获取仓库列表

为了集中查看现有仓库，

gh repo list <owner> --limit 500 --visibility private

也使用了。

这表示

指定したアカウントの
Privateリポジトリを一覧取得する

的意思。

如果只需要名称，

gh repo list <owner> `
    --limit 500 `
    --visibility private `
    --json name `
    --jq '.[].name'

とした。

これによって、

GitHubにすでにあるリポジトリ名

を取得して、PC側のUnityプロジェクトと比較できる。

大量作成するとGitHub側の制限に当たった

複数のUnityプロジェクトを順番にGitHubへ上げていると、

GraphQL:
You have created too many repositories, too quickly.
Please try again later.

というエラーが出た。

最初，

git pushで失敗している？

我想。

然而实际上失败的是，

gh repo create

的部分。

也就是说，

git init
git add
git commit

例如，本地端的Git处理已经完成。

此后，

GitHubに新しいリポジトリを作る

然而遇到了限制。

在这里，

Git
↓
GitHub

将两者分开思考起到了作用。

最初是等待10分钟后重试的

在最初的脚本中，如果仓库创建失败，

Start-Sleep -Seconds 600

としていた。

これは、

600秒
=
10分

待つ処理。

その後もう一度、

gh repo create

を実行していた。

しかし、10分待っても解除されないことがあり、3回試しても同じエラーになることがあった。

改为遇到限制时停止的形式

最终，

GitHub作成制限に当たる
↓
その場で処理を終了
↓
作成途中のGitリポジトリは残す
↓
次回また実行して再開する

改为了这种方式。

比起强行持续重试，

途中まで終わった作業を保存して
次回そこから再開する

采用这种形式更容易处理。

复用了临时Git仓库

即使 GitHub 侧的仓库创建失败，

Assets
Packages
ProjectSettings
.git

也可能已经创建到某个阶段。

在这种情况下，

Test-Path (Join-Path $exportPath ".git")

我确认了 .git 的存在。

如果存在 .git，

git init
git add
git commit

则判断已完成至该阶段，并将该临时 Git 仓库留待下次复用。

这样一来，即使遇到GitHub方面的限制，也无需从头重新开始本地工作。

本次梳理出的角色

将本次使用的内容进行整理的话，

PowerShell
→ 処理全体を組み立てる

Git
→ PC内で履歴を管理する

GitHub
→ Gitリポジトリをネット上に保存する

GitHub CLI
→ GitHubをコマンドから操作する

就是这样的角色。

特别是，

git commit

和、

gh repo create

是完全不同的处理。

git commit 用于在PC内创建Git历史记录。

gh repo create 用于在GitHub上创建存储位置。

然后，

git push

将两者连接起来。

总结

这次经常使用的Git命令是，

git init
Git管理を始める

git add.
変更をコミット対象にする

git commit
ローカルの履歴として保存する

git branch -M main
ブランチ名をmainにする

git remote add origin
GitHubの接続先を登録する

git push
ローカルの履歴をGitHubへ送る

在 GitHub CLI 中，

gh repo create
GitHubリポジトリを作る

gh repo view
特定のリポジトリを確認する

gh repo list
リポジトリ一覧を取得する

使用了。

最初是，

GitHubへアップロードする

看起来像是同一项作业。

实际上，

ローカルでGit管理する
↓
GitHub側に保存場所を作る
↓
接続先を設定する
↓
pushする

被分成了多个处理步骤。