我的远程实习(二) | 渐进式场景化学习git 🤡,follow me ~前言这篇文章用来记录一些要用的 git 方

前言

这篇文章用来记录一些要用的 git 方法，将会持续更新，不过，我可能可能及时更新，因为我要工作，还有其他比较重要的文章需要写🤡

算是先占个坑~

如何修改提交信息

修改git commit -m ""引号中的内容可以根据提交是否已经推送到远程仓库来采用不同的方法，以下为你详细介绍：

提交未推送到远程仓库

如果提交还没有推送到远程仓库，你可以使用git commit --amend命令来修改最近一次提交的提交信息。

操作步骤如下：

执行以下命令开始修改提交信息：

git commit --amend

执行该命令后，会打开一个文本编辑器（通常是 Vim），其中显示当前的提交信息。你可以直接修改这个信息。
修改完成后，保存并关闭编辑器。这样，最近一次提交的提交信息就被更新了。

如果你想直接在命令行中修改而不打开编辑器，可以使用以下命令：

git commit --amend -m "新的提交信息"

提交已推送到远程仓库

若提交已经推送到了远程仓库，你需要先按照上述未推送时的方法修改本地的提交信息，然后使用git push -f强制推送到远程仓库。不过，这种方法会重写远程仓库的提交历史，在多人协作的项目中使用时需要谨慎，因为这可能会给其他协作者带来麻烦。

操作步骤如下：

修改本地提交信息：

git commit --amend -m "新的提交信息"

强制推送到远程仓库：

git push -f origin 分支名

以下是总结操作过程的示例代码：

# 若提交未推送到远程仓库，直接修改
git commit --amend -m "新的提交信息"

# 若提交已推送到远程仓库
git commit --amend -m "新的提交信息"
git push -f origin 分支名

在多人协作的项目中，建议你在强制推送之前先与团队成员沟通，避免影响他人的工作。

撤回刚刚的 GitHub 提交

要撤回刚刚的GitHub提交，有以下几种方法：

使用命令行

使用git revert命令：该命令会创建一个新的提交来撤消之前的更改，不会改变历史记录，适用于多人协作场景。具体步骤如下：
- 首先使用git log命令找到要撤回的提交的哈希值。
- 然后执行git revert <commit_sha>命令，其中<commit_sha>为要撤回的提交的哈希值。执行该命令后，会生成一个新的提交，用于撤销指定提交的更改。
- 最后将新的提交推送到远程仓库：git push origin <branch_name>，其中<branch_name>为当前所在分支。
使用git reset命令：该命令可以直接删除提交，但会改变历史记录，使用时需谨慎。
- 撤回最近的commit但保留更改：使用git reset --soft HEAD~1命令，该命令会将HEAD指向前一个commit，但保留工作目录中的更改，即代码仍在工作区，且处于暂存状态，可以继续修改后重新提交。
- 撤回最近的commit并丢弃更改：如果希望完全丢弃最近的commit和更改，可使用git reset --hard HEAD~1命令。此命令会将HEAD指向前一个commit，并删除工作区和暂存区中与该提交相关的所有更改，将代码恢复到上一个提交时的状态。

使用GitHub图形界面

登录GitHub账户，打开相关的仓库，转到“Commits”标签，找到要撤回的刚刚的commit，点击commit旁边的“Revert”按钮，GitHub将自动为你创建一个新的撤回commit，然后将新的commit推送到远程仓库即可完成撤回操作。

远程与本地冲突

遇到了一个常见的 Git 错误，这是因为本地对 README.md 和 doc/Josn_prompt.md 文件进行了修改，而远程仓库中这些文件也有更新。Git 无法自动合并这些更改，因为可能会覆盖本地修改。

解决方案

有以下几种选择：

1. 提交本地更改

git add README.md doc/Josn_prompt.md
git commit -m "我的本地修改"
git pull --tags origin main

2. 暂存本地更改

git stash
git pull --tags origin main
git stash pop

如果 git stash pop 后出现冲突，你需要手动解决这些冲突。

3. 放弃本地更改

如果你的本地修改不重要：

git checkout -- README.md doc/Josn_prompt.md
git pull --tags origin main

-----------------更新：2025/3/31---------------

git 提交规范

在使用 Git 进行版本控制时，遵循一定的提交信息规范是非常重要的。这不仅可以帮助团队成员更容易地理解每次提交的目的和影响，还能提高代码审查的效率。常见的 Git 提交信息规范之一是 Conventional Commits 规范，它定义了一套标准化的提交信息格式。遵循这样的规范可以使团队协作更加高效，代码历史也更易于理解和维护。

提交信息格式

每一条提交信息包含 Header （必填）、Body（可选）和 Footer（可选），格式如下：

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

（1）Header（必填）

<type>：提交类型，表示本次改动的性质
<scope>（可选）：影响范围，如模块名、组件名
<subject>：简短描述（50字以内，英文首字母小写，不加句号）

（2）Body（可选）

详细说明改动的动机和内容（每行不超过 72 字符）
如果是修复 Bug，需关联 Issue 编号

（3）Footer（可选）

BREAKING CHANGE：标明不兼容的改动（影响重大版本升级）
Closes #123：关联关闭的 Issue 或 PR

提交类型

1. `feat` (Feature)

含义：表示新增功能（feature）的提交。
示例：feat: add night mode to the application
描述：用于描述新功能的添加，比如增加了一个新的用户界面特性或后端服务功能。

2. `fix` (Fix)

含义：表示修复错误（bug fix）的提交。
示例：fix: resolve null pointer exception in user login
描述：用于修复代码中的错误或问题，确保程序的行为符合预期。

3. `style` (Style)

含义：表示代码样式修改的提交，不影响程序逻辑。
示例：style: update code formatting according to ESLint rules
描述：用于改进代码风格，例如调整缩进、空格、换行等，通常不会改变代码的功能。

4. `revert:` 回滚

含义：用于提交回滚之前的提交。
示例：revert: 回滚feat: 增加用户注册功能。
描述：用于直接明确回滚的代码，包含了那些历史功能模块。

5. `build:` 构建系统或外部依赖项的变更

含义：用于提交影响构建系统的更改。
示例：build: 升级webpack到版本5。
描述：用于打包构建项目的描述，或者更改了相关依赖等。

其他常见前缀

refactor (Refactor)：
- 含义：表示代码重构，即不改变代码功能的情况下优化代码结构。
- 示例：refactor: simplify complex function logic
docs (Documentation)：
- 含义：表示文档更新，如 README 文件、API 文档等。
- 示例：docs: update installation guide for v2.0
test (Test)：
- 含义：表示测试相关的更改，如添加或修改测试用例。
- 示例：test: add unit tests for new feature
chore (Chore)：
- 含义：表示维护任务，如更新依赖项、配置文件等。
- 示例：chore: update package.json dependencies
perf (Performance)：
- 含义：表示性能优化的提交。
- 示例：perf: optimize database query performance
ci (Continuous Integration)：
- 含义：表示持续集成相关的更改，如 CI/CD 配置文件的更新。
- 示例：ci: configure GitHub Actions for automated testing

提交示例

示例 1：新增功能

feat(user): add login with OAuth2.0

- Integrate Google OAuth2.0 authentication
- Add related API endpoints in backend

Closes #45

示例 2：修复 Bug

fix(api): handle null response in getUserProfile

When the user profile is empty, the API now returns 
a 404 status instead of 500.

Fixes #78

示例 3：文档更新

docs(README): update installation guide

Add detailed steps for Windows environment setup.

4. 工具推荐

（1）Commitizen（交互式提交工具）

# 安装
npm install -g commitizen

# 使用（替代 git commit）
git cz

运行后会引导填写规范的提交信息。

（2）Husky + Commitlint（提交校验）

# 安装依赖
npm install husky @commitlint/cli @commitlint/config-conventional --save-dev

# 配置 commitlint
echo "module.exports = { extends: ['@commitlint/config-conventional'] }" > .commitlintrc.js

# 启用 Husky 钩子
npx husky install
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

配置后，不符合规范的提交会被自动拦截。

团队协作建议

分支命名：
- 功能分支：feat/xxx
- Bug 修复分支：fix/xxx
- 发布分支：release/v1.0.0
合并请求（PR）：
- 关联提交信息中的 Issue 编号
- 在 PR 描述中说明改动背景和测试结果
Code Review：
- 检查提交信息是否清晰
- 确保每个提交只做一件事（单一职责原则）

为什么需要规范？

提高可读性：通过类型快速识别提交目的
自动化生成 CHANGELOG：工具可基于提交信息自动生成版本日志
便于回溯问题：关联 Issue 和提交历史，定位问题更高效

附录：

-----------------更新：2025/4/12---------------

本地 dev 分支 ↔ 远程 dev 分支

1. 初始化环境（首次操作）

# 克隆仓库（默认拉取远程 main/master 分支）
git clone https://github.com/username/repo.git
cd repo

# 创建并切换到本地 dev 分支（基于当前分支）
git checkout -b dev

# 推送本地 dev 分支到远程（首次创建远程 dev 分支）
git push -u origin dev  # -u 参数关联远程分支，后续可直接用 git push

2. 日常开发操作流程

# 切换到 dev 分支（如果未在 dev 分支）
git checkout dev

# 拉取远程 dev 分支最新代码（避免后续冲突）
git pull origin dev

# --------------------------
# 进行代码修改（编辑/新增/删除文件等）
# --------------------------

# 查看变更状态
git status

# 添加所有修改到暂存区（或指定文件）
git add .  # 全部添加
# 或 git add file1.txt dir/file2.js

# 提交到本地仓库
git commit -m "feat: 添加用户登录功能"

# 推送提交到远程 dev 分支
git push  # 已关联上游分支，可直接推送
# 若未关联，使用 git push origin dev

3. 处理冲突场景

如果多人协作时远程 dev 分支已更新，需先合并远程修改：

# 尝试推送时发现冲突
git push  # 提示错误：! [rejected] dev -> dev (non-fast-forward)

# 拉取远程最新代码并自动合并
git pull origin dev

# 手动解决冲突（IDE 或编辑器标记冲突位置）
# 修改后保存文件，删除冲突标记（如 <<<<<<< HEAD 等）

# 标记冲突已解决
git add resolved-file.txt

# 提交合并后的代码
git commit -m "fix: 合并远程 dev 分支冲突"

# 重新推送
git push

4. 分支同步与维护

# 查看本地分支与远程关联状态
git branch -vv  
# 显示示例：dev 7d3f2c1 [origin/dev] feat: 添加新功能

# 强制覆盖远程分支（慎用！会丢失远程修改）
git push -f origin dev

# 删除远程 dev 分支（如需清理）
git push origin --delete dev

5. 配置优化（提升效率）

# 设置默认推送分支关联（首次推送后自动记忆）
git config --global push.default current

# 配置快捷命令别名
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status

常见问题处理

问题1：推送权限不足

# 错误提示：remote: Permission to user/repo.git denied to otheruser
# 解决：
# 1. 检查 Git 账号配置
git config user.name  # 应为仓库拥有者账号
git config user.email # 应与 GitHub 注册邮箱一致

# 2. 更新远程仓库 URL 为 SSH 格式（避免 HTTPS 权限问题）
git remote set-url origin git@github.com:user/repo.git

问题2：本地分支与远程失联

# 错误提示：fatal: 当前分支 dev 没有对应的上游分支
# 解决：手动关联远程分支
git branch --set-upstream-to=origin/dev dev

流程图解

graph TD
    A[克隆仓库] --> B[创建本地 dev 分支]
    B --> C[推送 dev 到远程]
    C --> D{日常开发}
    D --> E[修改代码]
    E --> F[git add/commit]
    F --> G[git pull 更新]
    G --> H[解决冲突?]
    H -- 是 --> I[处理冲突后提交]
    H -- 否 --> J[git push 推送]
    I --> J

遵循此流程，可确保本地 dev 分支与远程完全同步，适合团队协作或个人项目管理。

我的远程实习(二) | 渐进式场景化学习git 🤡,follow me ~

前言