Lazy loaded image
工具与配置
Git 与 GitHub 入门与协作流程
字数 2622阅读时长≈ 7 分钟
2025-12-8
2026-3-9

生成ssh令牌方便操作私有仓库

仓库一般是私有的， 可以先在系统中生成一个ssh密钥， 然后将公钥配置到github中，方便对仓库进行操作
1. 生成 SSH 密钥
生成一对新的 ED25519 密钥，文件名使用 wsl_ed25519：
生成后会得到：
  • 私钥：~/.ssh/wsl_ed25519
  • 公钥：~/.ssh/wsl_ed25519.pub
2. 将公钥添加到 GitHub
查看公钥内容：
然后到 GitHub 页面添加：
  • 登录 GitHub
  • 进入 Settings
  • 左侧选择 SSH and GPG keys
  • 点击 New SSH key
  • Title 可填写：orangepi5plus 或 My WSL Key
  • 将上一步复制的公钥粘贴进去
  • 保存
3. 配置 GitHub SSH（直连场景）
如果网络可以直接访问 GitHub SSH，可写入 ~/.ssh/config：
4. 配置 GitHub SSH（代理场景，推荐开发板使用）
如果开发板通过电脑代理上网，需要让 SSH 走 HTTP 代理。
4.1 创建代理脚本
4.2 写入 SSH 配置
说明：
这里使用 ssh.github.com:443，适合被代理或受限网络环境。
5. 验证 SSH 是否配置成功
执行：
成功时会看到：
6. 使用 SSH 操作仓库
克隆私有仓库示例：
7. 可选：使用 ssh-agent 加载私钥
如果希望当前会话中由 ssh-agent 管理私钥，可执行：
然后可再次测试：
注：
当前这套配置里已经通过 IdentityFile 指定了私钥，通常不依赖 ssh-agent 也能使用。
ssh-agent 主要用于避免频繁输入口令，或统一管理多把密钥。
8. 可选：使用 keychain 持久管理私钥
安装：
将下面内容加入 ~/.bashrc：
重新加载：

创建PR的流程

首次
  1. 克隆仓库：使用 git clone [仓库URL] 将代码仓库下载到本地。
  1. 创建新分支：使用 git checkout -b [新分支名] 创建一个新分支进行开发。
后续
  • 编写代码：在新分支上进行代码修改和新增功能。
  • 提交更改：使用 git add . 添加变更并用 git commit -m "描述" 提交更改。
  • 推送到远程：使用 git push origin [分支名] 将分支推送到远程仓库。
  • 发起PR：在GitHub页面发起Pull Request，选择要合并的分支。
  • 等待审查：团队成员审查PR，根据反馈进行必要的修改。
  • 合并PR：审查通过后，由维护者将PR合并到主分支。

Git指令总结与作用

指令
作用
git status
查看当前仓库状态（分支、修改文件、提交状态等）
git branch -a
列出所有本地和远程分支
git checkout [分支名]
切换到指定分支
git branch -u origin[分支名]
将本地分支与远程分支建立跟踪关系
git fetch origin master
从远程获取master分支的最新代码
git merge origin/master
将master分支的代码合并到当前分支
git push origin feature/websocket-server
将本地分支的修改推送到远程仓库
git push origin --delete [分支名]
删除远程仓库的指定分支
git clone git@github.com:example-org/demo-repo.git my-project
克隆远程仓库到本地
git diff --cached
查看暂存区与上次提交的差异
  • 在Git命令中使用origin是为了明确指定 远程仓库的别名 ，它是Git默认的远程仓库标识符。

两处位置开发不同的内容，但推送同一个仓库的流程

  1. 初始克隆：
  • 两位开发者（A和B）首先各自克隆同一个远程仓库：
    • 本地开发：
    • A和B可以在各自的本地仓库中进行开发。为了降低冲突风险，建议：
      • 各自对不同的文件进行修改，或者在同一文件中尽量不修改相同的部分。
    • 拉取最新更新：
        • 本地创建 dev 分支并跟踪远程的 origin/dev 分支
      • 在开始新一轮工作前和准备推送更改前，A和B都应该进行git pull，以确保他们的本地仓库是最新的：
          • 这一步是为了获取其他开发者（如另一位开发者A或B）在远程仓库中做的更新。
      • 推送更改到远程仓库：
      • 当A和B完成开发且确保没有冲突时，可以使用以下命令将更改推送到远程仓库：
        • 处理可能的冲突：
        • 即使A和B开发内容不同，如果他们同时修改了同一文件的相同区域（例如同一行代码），会出现冲突。此时，Git会要求解决冲突。
        • 解决冲突的步骤包括：
            1. 手动编辑有冲突的文件，保留需要的更改，删除冲突标记。
            1. 使用命令git add <file>标记已解决的文件。
            1. 然后执行git commit提交合并结果。

        修改远程分支名

        1. 切换到要修改的分支名 并 拉取最新代码
          1. 本地重命名分支
            1. 删除远程旧分支
              1. 推送新分支到远程并关联跟踪

                单人长期使用 dev、仅 PR 权限的最佳流程

                规则（避免分支状态怪异）

                • 永远只开 dev -> master 的 PR
                • 不要用 "master -> dev 的 PR" 来同步（会让 dev ahead master）

                日常开发

                同步 master 到 dev（每天 / PR 前 / PR 提示 behind 时）

                PR 合入后：让 dev 与 master 完全一致（包括提交历史）

                推荐做法：直接把 dev 指到最新 master，保持"干净分支"。

                本地 master 只用来跟随远端（保持干净）

                常见的提交（commit）类型：

                1. feat (feature)：
                    • 描述： 引入新功能。
                    • 示例： feat: 添加用户登录功能
                1. fix (bug fix)：
                    • 描述： 修复了一个 bug。这是你已经知道的。
                    • 示例： fix: 修复用户注册时密码验证失败的问题
                1. docs (documentation)：
                    • 描述： 仅修改了文档，例如 README、API 文档、注释等。
                    • 示例： docs: 更新 README 文件，添加安装指南
                1. style (formatting, css, etc.)：
                    • 描述： 不影响代码逻辑的改动，比如格式化代码、调整 CSS 样式、删除多余的空格、修改分号等。
                    • 示例： style: 格式化文件以符合 ESLint 规范
                1. refactor (code refactoring)：
                    • 描述： 对现有代码进行重构，既不添加新功能也不修复 bug，只是代码内部结构或性能优化。
                    • 示例： refactor: 优化用户认证模块的代码结构
                1. perf (performance)：
                    • 描述： 改进性能的代码更改。
                    • 示例： perf: 优化数据库查询，提升响应速度
                1. test (tests)：
                    • 描述： 添加、修改或删除测试文件。
                    • 示例： test: 为用户注册功能添加单元测试
                1. build (build system or external dependencies)：
                    • 描述： 影响构建系统或外部依赖的更改，例如 gulp、webpack、npm scripts 的更改。
                    • 示例： build: 更新 webpack 配置以支持 tree-shaking
                    • 示例： build: 升级依赖 lodash 到最新版本
                1. ci (CI configuration)：
                    • 描述： 持续集成配置文件的更改，例如 Jenkins、Travis CI、GitHub Actions 等。
                    • 示例： ci: 添加 GitHub Actions 配置文件
                1. chore (other changes)：
                    • 描述： 不修改源文件或测试文件的其他提交。例如，修改 .gitignore、.editorconfig 文件，或其他维护任务。
                    • 示例： chore: 更新 .gitignore 忽略文件列表
                1. revert (revert previous commit)：
                    • 描述： 撤销之前的提交。
                    • 示例： revert: "feat: 添加用户登录功能" 此提交导致生产环境崩溃

                其他

                把本地 dev 和远程 origin/dev 绑定为「上游分支」（第一次推送时设置）：
                执行后，后续只需输入 git push 就能自动推送本地 dev 到远程 origin/dev

                1. 添加esp-idf子模块

                2. PR（Pull Request）

                PR全称为Pull Request，是Git协作开发中用来合并代码的方式。它的基本流程如下：
                1. 开发新功能：在独立分支上进行开发，专注于特定功能或修复。
                1. 发起PR：完成开发后，向主分支（如 master 或 main）发起Pull Request。
                1. 代码审查：团队成员对PR代码进行审核，并提出修改建议。
                1. 修改反馈：根据审查意见进行代码修改，更新PR。
                1. 合并代码：经过审查批准后，将PR合并到主分支。
                💡
                有关此文章其他内容，欢迎在下方留言（我会收到邮件通知），留言我会以邮件回复。或联系我的QQ。
                上一篇
                【WSL环境】在Windows11环境下配置WSL Ubuntu24.04子系统
                下一篇
                将配置 ESP32-C6 作为 Matter controller 【使用自带的控制台】 控制 设备（设备分esp模拟和Tuya灯泡）
                评论
                Loading...
                目录