git 远程仓库.github/workflow的 yml如何配置
关于远程仓库
GitHub 的协作开发方法取决于将本地存储库中的提交发布到 GitHub 以便其他人查看、获取和更新。
远程 URL 是 Git 表达“代码存储位置”的奇特方式。该 URL 可以是您在 GitHub 上的存储库，也可以是其他用户的分支，甚至是完全不同的服务器上的存储库。
- HTTPS URL，例如 https://github.com/user/repo.git
- SSH URL，例如 git@github.com:user/repo.git
Git 将远程 URL 与名称关联起来，默认远程通常称为 origin 。
创建远程仓库
您可以使用 git remote add 命令将远程 URL 与名称进行匹配。例如，您可以在命令行中键入以下内容：
git remote add origin <REMOTE_URL>
这会将名称 origin 与 REMOTE_URL 相关联。
您可以使用命令 git remote set-url 更改远程 URL。
选择远程仓库的url
举例
$ git remote add origin https://github.com/OWNER/REPOSITORY.git
# Set a new remote
$ git remote -v# Verify new remote> origin https://github.com/OWNER/REPOSITORY.git (fetch)> origin https://github.com/OWNER/REPOSITORY.git (push)
使用HTTPS URLs 克隆
https:// 克隆 URL 在所有存储库上都可用，无论可见性如何。 https:// 即使您位于防火墙或代理后面，克隆 URL 也能正常工作。
当您在命令行上使用 HTTPS URL git clone 、 git fetch 、 git pull 或 git push 到远程存储库时，Git 会要求您的 GitHub 用户名和密码。当 Git 提示您输入密码时，请输入您的个人访问令牌。或者，您可以使用凭证助手，例如 Git Credential Manager。 Git 的基于密码的身份验证已被删除，取而代之的是更安全的身份验证方法。有关详细信息，请参阅“管理您的个人访问令牌”。
如果您要访问使用 SAML SSO 的组织并且使用个人访问令牌（经典），则还必须在进行身份验证之前授权您的个人访问令牌才能访问该组织。有关详细信息，请参阅“关于使用 SAML 单点登录进行身份验证”和“授权个人访问令牌以用于 SAML 单点登录”。
- 您可以使用凭证助手，以便 Git 每次与 GitHub 对话时都会记住您的 GitHub 凭证。有关更多信息，请参阅“在 Git 中缓存 GitHub 凭证”。
Git Credential Manager (GCM) 是安全存储凭据并通过 HTTPS 连接到 GitHub 的另一种方法。使用 GCM，您无需手动创建和存储个人访问令牌，因为 GCM 代表您管理身份验证，包括 2FA（双因素身份验证）。
下次您克隆需要身份验证的 HTTPS URL 时，Git 将提示您使用浏览器窗口登录。可能首先会要求您授权 OAuth 应用程序。如果您的帐户或组织需要双因素身份验证，您还需要完成 2FA 挑战。
成功进行身份验证后，您的凭据将存储在 macOS 钥匙串中，并在您每次克隆 HTTPS URL 时使用。 Git 不会要求您再次在命令行中输入凭据，除非您更改凭据。
使用 Homebrew 安装 Git：
brew install git
使用 Homebrew 安装 GCM：
brew install --cask git-credential-manager
- 要克隆存储库而不在命令行上向 GitHub 进行身份验证，您可以使用 GitHub Desktop 进行克隆。有关更多信息，请参阅“将存储库从 GitHub 克隆到 GitHub Desktop”。
使用SSH URLs
SSH URL 提供通过 SSH（一种安全协议）对 Git 存储库的访问。要使用这些 URL，您必须在计算机上生成 SSH 密钥对，并将公钥添加到您在 GitHub.com 上的帐户。有关详细信息，请参阅“使用 SSH 连接到 GitHub”。
当您使用 SSH URL git clone 、 git fetch 、 git pull 或 git push 访问远程存储库时，系统会提示您输入密码并且必须提供您的 SSH 密钥密码。有关详细信息，请参阅“使用 SSH 密钥密码”。
如果您要访问使用 SAML 单点登录 (SSO) 的组织，则必须先授权 SSH 密钥才能访问该组织，然后再进行身份验证。有关更多信息，请参阅 GitHub Enterprise Cloud 文档中的“关于使用 SAML 单点登录进行身份验证”和“授权 SSH 密钥与 SAML 单点登录一起使用”。
提示：您可以使用 SSH URL 将存储库克隆到您的计算机，或者作为将代码部署到生产服务器的安全方法。您还可以将 SSH 代理转发与部署脚本结合使用，以避免管理服务器上的密钥。有关详细信息，请参阅“使用 SSH 代理转发”。
GitHub Actions 的工作流配置
在 GitHub Actions 的工作流配置中使用的
github_token
字段是用来提供访问 GitHub API 的认证信息。它代表了一个特定的权限令牌（Token），通常用于在 GitHub Actions 自动化过程中授权对 GitHub 仓库进行操作，比如推送代码、访问仓库数据等。
GitHub Token 的类型
GITHUB_TOKEN: 这是由 GitHub 自动创建并提供给运行中的 GitHub Actions 工作流的一个特殊令牌。这个令牌具有与触发工作流的 GitHub 用户或 GitHub App 关联的权限。它主要用于权限验证，让工作流可以安全地与 GitHub 仓库交互。GITHUB_TOKEN的权限默认受限于与它关联的仓库，并且在工作流结束时失效，确保安全性。- 个人访问令牌（PAT）: 这是用户手动在 GitHub 账户设置中生成的令牌，可以具有更广泛的权限，并可以跨多个仓库使用。与
GITHUB_TOKEN不同，PAT 的使用不限于单个工作流会话，而是直到它被用户撤销或过期。使用 PAT 可以在工作流中执行更多操作，如在不同的仓库之间推送代码等。
在 GitHub Actions 中使用 Token
在 GitHub Actions 的 YAML 配置文件中，你可以这样使用 Token：
steps:-uses: actions/checkout@v2
-name: Some step that uses the GitHub token
uses: some-action-that-needs-token@v1
with:token: ${{ secrets.GITHUB_TOKEN }}# 使用自动生成的 GITHUB_TOKEN
如果你需要使用 PAT 或自定义命名的密钥，你可以将其存储在 GitHub 仓库的 Secrets 中，并在工作流中引用它：
steps:-uses: actions/checkout@v2
-name: Some step that uses a custom PAT
uses: some-action-that-needs-token@v1
with:token: ${{ secrets.PAT }}# 使用存储在 Secrets 中的个人访问令牌
重要事项
- 使用
GITHUB_TOKEN时，要注意它的权限可能受限，可能不足以执行一些跨仓库的操作。 - 使用 PAT 时，要格外小心，因为它通常权限较高，泄露后可能导致安全风险。
- 确保在 GitHub 的 Secrets 设置中正确配置和保护你的 Token，避免将 Token 硬编码在工作流文件中。
通过正确使用这些 Token，你的 GitHub Actions 工作流可以安全地与 GitHub 交互，执行各种自动化任务。如果还有疑问或需要进一步的帮助，请随时联系。
在github操作步骤
在 GitHub 中，
GITHUB_TOKEN
和个人访问令牌（PAT）是两种用于身份验证和授权的令牌，它们的生成和使用方式有所不同。以下是详细的生成方法和相关注意事项：
1.
GITHUB_TOKEN
GITHUB_TOKEN
是自动由 GitHub 在每次 GitHub Actions 工作流运行时生成的。你不需要手动创建这个令牌。它会自动注入到工作流环境中，并且仅在当前工作流运行期间有效。
使用方法：
- 在你的 GitHub Actions 工作流文件中，你可以直接引用
GITHUB_TOKEN，如下所示：steps:-name: Example using GITHUB_TOKEN uses: some-action with:token: ${{ secrets.GITHUB_TOKEN }} - 这个令牌的权限通常受限于关联的仓库，并且具有足够的权限执行大多数与仓库相关的操作，如克隆、推送、拉取等。
2. 个人访问令牌（PAT）
个人访问令牌（PAT）需要你手动在 GitHub 账户设置中生成。它可以具有广泛的权限，并可以跨仓库使用。由于它的权限较广，因此需要更谨慎地处理。
生成步骤：
- 登录到 GitHub：打开你的浏览器，访问 GitHub 并登录。
- 访问设置：在页面右上角，点击你的头像，然后选择“Settings”（设置）。
- 开发者设置：在设置页面的侧边栏中，找到“Developer settings”（开发者设置）并点击。
- 访问令牌：在开发者设置页面中，选择“Personal access tokens”（个人访问令牌），然后点击“Generate new token”（生成新令牌）。
- 选择权限：给你的令牌命名，并选择适当的权限。对于大多数用于 CI/CD 的操作，你可能需要选择
repo权限。确保选择的权限符合你的需求，并尽量遵循最小权限原则。 - 生成令牌：完成后，点击页面底部的“Generate token”（生成令牌）按钮。
- 复制并保存令牌：生成后，你将看到一次性显示的令牌。确保复制并安全地保存这个令牌，因为它不会再次显示。
存储和使用：
- 将生成的 PAT 添加到 GitHub 仓库的 Secrets 中，方法与之前类似，然后在 GitHub Actions 中引用该 Secret，如下所示：
steps:-name: Example using PAT uses: some-action with:token: ${{ secrets.YOUR_PAT_SECRET_NAME }}
安全注意事项
- 保密性：永远不要将令牌硬编码在代码中或公开令牌。始终使用 GitHub Secrets 来管理敏感数据。
- 权限：为 PAT 选择尽可能低的权限级别，以减少安全风险。
通过以上步骤，你可以正确生成和使用
GITHUB_TOKEN
和 PAT，以安全地实现自动化操作和其他需要 GitHub API 授权的任务。如果有任何疑问或需要进一步的帮助，请随时联系。
下面展示一下我的yml 例子
name: SSH CI Github Pages
on:#监听push操作push:branches:- main # 这里只配置了main分支，所以只有推送main分支才会触发以下任务jobs:# 任务IDbuild-and-deploy:# 运行环境runs-on: ubuntu-latest
# 步骤steps:# 官方action，将代码拉取到虚拟机-name: Checkout ️
uses: actions/checkout@v2
with:persist-credentials:false# 这个设置很重要，尤其是在部署到 public repository 时-name: Setup SSH keys
uses: webfactory/[email protected]
with:ssh-private-key: ${{ secrets.DEPLOY_KEY }}-name: Setup Node.js
uses: actions/setup-node@v2
with:node-version:'18'# cache: 'pnpm'-name: Install pnpm
run:|
npm install -g [email protected]
echo "Verify pnpm version"
pnpm -v-name: Add pnpm to PATH
run: echo "$(npm prefix -g)/bin" >> $GITHUB_PATH
-name: Cache pnpm modules
uses: actions/cache@v2
with:path:|
~/.pnpm-storekey: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml')}}restore-keys:|
${{ runner.os }}-pnpm--name: Install dependencies
run: pnpm install
-name: Build
run: pnpm run docs:build
-name: Deploy # 部署uses: peaceiris/actions-gh-pages@v4
with:# branch: gh-pages # 部署后提交到那个分支# github_token: ${{ secrets.PAT }}deploy_key: ${{ secrets.DEPLOY_KEY }}#公钥publish_dir: ./site/docs/.vitepress/dist # 这里填打包好的目录名称publish_branch: gh-pages
- GitHub Actions 自动部署前端 Vue 项目
- 使用Github Actions自动部署vue项目
版权归原作者 杨晓白 所有， 如有侵权，请联系我们删除。