经过年复一年的开发积累，企业的代码仓逐渐变得臃肿，甚至变成屎山代码。这些屎山代码，往往经过N个程序员之手，他们水平参差不起，风格不一。如何对这些屎山代码进行统一的管理，让它们可以被监控、评价和批量改造？建立“代码管理系统”的第一个难点在于，如何在庞大的代码仓中，快速的查找出具有某些特征的代码段。由于我们需要查找的是代码段，而不是代码行，用传统的正则表达式难以实现，需要通过语法解析器进行自定义语法配置，然后进行代码查找。 以小实例说明 ： ### 实例1： 找出JAVA代码中，入参数量超过4个的函数：# 配置查找规则(Code_manage.syn)如下所示：__DEF_CASE_SENSITIVE__ Y __DEF_FUZZY__ Y __DEF_DEBUG__ N __DEF_LINE_COMMENT__ // __DEF_LINES_COMMENT__ /* */ __DEF_STR__ __NAME__ <1,200> [1,1]ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_$?? [0,199]ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_?? [NO] import if else for while break continue class return try except finally final static public private __DEF_PATH__ __FUNCTION_DEF__ 0101 : x1 @ | public : x2 @ + private 0 0 : x3 @ CAN_SKIP | static 1 1 : x4 @ | __NAME__ : x5 @ | __NAME__ : x6 @ | ( 1111 : p1 @ CAN_SKIP | final : p11 @ | __NAME__ : p111 @ | __NAME__ : p2 @ | , : p22 @ CAN_SKIP | final : p222 @ | __NAME__ : p2222 @ | __NAME__ : p3 @ | , : p33 @ CAN_SKIP | final : p333 @ | __NAME__ : p3333 @ | __NAME__ NNNN : p4 @ | , : p44 @ CAN_SKIP | final : x444 @ | __NAME__ : x4444 @ | __NAME__ 1111 : xx @ | )# 假设java代码(MyCode.java) 如下所示：private int alreadyBufferedSize = 0; // The index in the byte[] found at buffers.getLast() to be written next private int index = 0; // Is the stream closed? private boolean closed = false; public FastByteArrayOutputStream(int initialBlockSize) { Assert.isTrue(initialBlockSize > 0, "Initial block size must be greater than 0"); this.initialBlockSize = initialBlockSize; this.nextBlockSize = initialBlockSize; } @Override public void applyBeanPropertyValues(Object existingBean, String beanName, int autowireMode, boolean dependencyCheck, int initSize) throws BeansException { markBeanAsCreated(beanName); BeanDefinition bd = getMergedBeanDefinition(beanName); BeanWrapper bw = new BeanWrapperImpl(existingBean); initBeanWrapper(bw); applyPropertyValues(beanName, bd, bw, bd.getPropertyValues()); } @Override public Object initializeBean(Object existingBean, String beanName) { return initializeBean(beanName, existingBean, null); }根据配置规则，执行查找命令： ZGLanguage -e Code_manage.syn -f MyCode.java可以得到结果：C:\>ZGLanguage -e Code_manage.syn -f MyCode.java Run type : Find Syntax file : Code_manage.syn code file : MyCode.java Output file : out.zgl -------------------------------------------------------------------- ### Found code by : __FUNCTION_DEF__ | Lines : 17 ~ 17 : -------------------------------------------------------------------- public void applyBeanPropertyValues(Object existingBean, String beanName, int autowireMode, boolean dependencyCheck, int initSize)可以看出，查找结果只输出了函数 applyBeanPropertyValues，它的入参数量为5个，其他2个函数的入参均不超过4个，因此被忽略。 ### 实例2： 提取SQL代码中的关联(on)和筛选(where)代码段：# 配置查找规则(Code_manage.syn)如下所示：__DEF_DEBUG__ N __DEF_FUZZY__ Y __DEF_CASE_SENSITIVE__ N __DEF_LINE_COMMENT__ -- __DEF_LINES_COMMENT__ /* */ __DEF_PATH__ __WHERE__ 1 : x1 | where : x2 | __PATH_4_EXPR__ __DEF_PATH__ __ON__ 1 : x1 | __\b__ : x2 + __\t__ : x3 + __\n__ : x4 | on : x5 | __PATH_4_EXPR__ __DEF_SUB_PATH__ __PATH_4_EXPR__ 1 : x1 | __SUB_PATH_EXPR__ : x2 + __ONE_PATH_EXPR__ __DEF_SUB_PATH__ __SUB_PATH_EXPR__ 1 : x1 | ( : x2 | __ONE_PATH_EXPR__ : x3 | ) __DEF_SUB_PATH__ __ONE_PATH_EXPR__ NN : @ | __NAME__ : @ + __INT__ : @ + __FLOAT__ : @ + __CASE_WHEN__ : @ + __STRING__ : @ + __CAST_AS__ : @ + __FUNCTION__ : @ + __SUB_PATH_EXPR__ : @ + = : @ + <> : @ + != : @ + > : @ + >= : @ + < : @ + <= : @ + . : @ + , : @ + + : @ + - : @ + * : @ + / : @ + || : @ + null : @ + between : @ + and : @ + or : @ + like : @ + in : @ STRING + not in : @ STRING + is null : @ STRING + is not null __DEF_STR__ __NAME__ <1,100> [1,1]ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_?? [0,100]ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_?? [NO] select inner left join on from where group order by having union all with as table date time __DEF_STR__ __FLOAT__ <1,100> [1,50]0123456789 [1,1]. [1,50]0123456789 __DEF_STR__ __INT__ <1,100> [1,100]0123456789 __DEF_SUB_PATH__ __STRING__ 1 : x1 | ' : x2 | __ANY__ : x3 | ' __DEF_SUB_PATH__ __DECIMAL__ 111 : x1 | decimal 0 : x2 | ( 01 : x3 | __INT__ 00 : x4 | , 00 : x5 | __INT__ 01 : x6 | ) __DEF_SUB_PATH__ __VAR_NAME__ 1 : x1 | $ : x2 | { : x3 | __NAME__ : x4 | } __DEF_SUB_PATH__ __CASE_WHEN__ 1 : x1 @ | case N : x2 @ | when : x3 @ | __PATH_4_EXPR__ : x4 @ | then : x5 @ | __PATH_4_EXPR__ 1 : x6 @ CAN_SKIP | else : x7 @ CAN_SKIP | __PATH_4_EXPR__ : x8 @ | end __DEF_SUB_PATH__ __CAST_AS__ 1 : x1 | cast : x2 | ( 1 : x3 | __PATH_4_EXPR__ : x4 | as : x5 | date : x6 + int : n1 + double : n2 + float : n3 + bigint : x8 + __DECIMAL__ 1 : xx | ) __DEF_SUB_PATH__ __FUNCTION__ 1 : x1 @ | __NAME__ : x2 @ | ( N : x3 @ CAN_SKIP | __PATH_4_EXPR__ e : x4 @ CAN_SKIP | , 1 : x5 @ | )# 假设SQL代码(myproc.sql) 如下所示：CREATE OR REPLACE PROCEDURE PROC_F_CWWS_LOAN ( P_AS_OF_DATE IN DATE, RET_FLG OUT VARCHAR2, RET_MSG OUT VARCHAR2 ) IS -- 声明变量并初始化 V_COUNT NUMBER := 0; V_PROC_NAME VARCHAR2(200) := 'PROC_F_CWWS_LOAN'; V_PROC_DESC VARCHAR2(100) := 'xxxx业务数据ETL处理'; V_P_FREQ VARCHAR2(4) := ''; BEGIN --写入初始日志 INSERT INTO M_RUNLOG VALUES (SYSDATE, V_PROC_NAME, 'it is 1'); COMMIT; --设置会话日期格式 EXECUTE IMMEDIATE ' ALTER SESSION SET NLS_DATE_FORMAT = ''YYYY-MM-DD'''; --查询参数表中，该程序对应的频率值 SELECT P_FREQ INTO V_P_FREQ FROM ETL_PROC_STATUS_DEF WHERE PROC_NAME = V_PROC_NAME; --判断是调度频率 ETL.ETL_ADD_PARTITION('MA_F_LOAN', P_AS_OF_DATE, 'ETL'); --从还款计划表中取每笔账户最近一次小于等于数据日期还款日，作为上次还款日 INSERT INTO ETL.TMP_XD_LAST_PAYDATE (OBJECTNO, LAST_PAYDATE) SELECT OBJECTNO, LAST_PAYDATE FROM (SELECT T.OBJECTNO, MAX(TO_DATE(PAYDATE, 'YYYY-MM-DD')) LAST_PAYDATE FROM NYBDP.O_CWWS_ACCT_PAYMENT_SCHEDULE T WHERE T.AS_OF_DATE = P_AS_OF_DATE AND T.SEQID <> '999' AND TO_DATE(T.PAYDATE, 'YYYY-MM-DD') < P_AS_OF_DATE GROUP BY T.OBJECTNO); INSERT INTO M_RUNLOG VALUES (SYSDATE, V_PROC_NAME, 'it is 3'); COMMIT; MERGE INTO ETL.MA_F_LOAN A USING (SELECT /*+PARALLEL(8)*/ T.ACCOUNT_NUMBER, T.GL_ACCOUNT_ID, T.INT_GL_ACCOUNT_ID FROM ETL.MA_F_LOAN T INNER JOIN ETL.MA_D_GL_SUBJECT T1 ON T.INT_GL_ACCOUNT_ID = T1.SUBJECT_NO3 AND T1.SUBJECT_NAME3 LIKE '%已减值%' AND T1.AS_OF_DATE = P_AS_OF_DATE WHERE T.AS_OF_DATE = P_AS_OF_DATE AND T.ACCOUNT_NUMBER IN (SELECT ACCOUNT_NUMBER FROM (SELECT /*+PARALLEL(8)*/ T2.ACCOUNT_NUMBER, COUNT(1) FROM ETL.MA_F_LOAN T2 WHERE T2.AS_OF_DATE = P_AS_OF_DATE GROUP BY T2.ACCOUNT_NUMBER HAVING COUNT(1) > 1))) B ON (A.ACCOUNT_NUMBER = B.ACCOUNT_NUMBER AND A.AS_OF_DATE = P_AS_OF_DATE AND A.GL_ACCOUNT_ID = B.GL_ACCOUNT_ID AND A.INT_GL_ACCOUNT_ID = B.INT_GL_ACCOUNT_ID) WHEN MATCHED THEN UPDATE SET A.CUR_BOOK_BAL = 0, A.OVERDUE_BAL = 0; COMMIT; RET_FLG := '0'; RET_MSG := '执行成功'; EXCEPTION WHEN OTHERS THEN --写入异常日志 ETL.PROC_ETL_LOG(P_AS_OF_DATE,V_PROC_NAME,V_PROC_DESC,V_COUNT,-1,SQLCODE,SQLERRM); RET_MSG := SQLCODE || ':' || SQLERRM; END; /根据配置规则，执行查找命令： ZGLanguage -e Code_manage.syn -f myproc.sql可以得到结果：C:\>ZGLanguage -e Code_manage.syn -f myproc.sql Run type : Find Syntax file : Code_manage.syn code file : myproc.sql Output file : out.zgl -------------------------------------------------------------------- ### Found code by : __WHERE__ | Lines : 27 ~ 27 : -------------------------------------------------------------------- WHERE PROC_NAME = V_PROC_NAME -------------------------------------------------------------------- ### Found code by : __WHERE__ | Lines : 39 ~ 41 : -------------------------------------------------------------------- WHERE T.AS_OF_DATE = P_AS_OF_DATE AND T.SEQID <> '999' AND TO_DATE(T.PAYDATE, 'YYYY-MM-DD') < P_AS_OF_DATE -------------------------------------------------------------------- ### Found code by : __ON__ | Lines : 52 ~ 54 : -------------------------------------------------------------------- ON T.INT_GL_ACCOUNT_ID = T1.SUBJECT_NO3 AND T1.SUBJECT_NAME3 LIKE '%宸插噺鍊?' AND T1.AS_OF_DATE = P_AS_OF_DATE -------------------------------------------------------------------- ### Found code by : __WHERE__ | Lines : 55 ~ 56 : -------------------------------------------------------------------- WHERE T.AS_OF_DATE = P_AS_OF_DATE AND T.ACCOUNT_NUMBER IN -------------------------------------------------------------------- ### Found code by : __WHERE__ | Lines : 61 ~ 61 : -------------------------------------------------------------------- WHERE T2.AS_OF_DATE = P_AS_OF_DATE -------------------------------------------------------------------- ### Found code by : __ON__ | Lines : 64 ~ 66 : -------------------------------------------------------------------- ON (A.ACCOUNT_NUMBER = B.ACCOUNT_NUMBER AND A.AS_OF_DATE = P_AS_OF_DATE AND A.GL_ACCOUNT_ID = B.GL_ACCOUNT_ID AND A.INT_GL_ACCOUNT_ID = B.INT_GL_ACCOUNT_ID) WHEN MATCHED THEN UPDATE SET A.CUR_BOOK_BAL = 0, A.OVERDUE_BAL = 0可以看出，查找结果将 myproc.sql 代码中的 where 和 on 代码块及其所在行号提取出来。  

1、PyCharm安装Python时的常见pip报错原因与解决方案全解析【转载】cid:link_02、Python中修复中文乱码的7种场景方法介绍【转载】cid:link_13、深入解析Python命名空间与作用域的核心机制【转载】cid:link_24、Git忽略大小写(重命名文件)的解决办法【转载】cid:link_35、git push常见问题及解决方案【转载】cid:link_46、一文详解Git的暂存与stash功能【转载】cid:link_57、Git合并后回退操作的完整指南【转载】cid:link_68、在鸿蒙上使用webview_flutter包的详细示例【转载】cid:link_79、一些常见的Git分支命名策略和实践指南【转载】cid:link_810、Java中函数式接口实现分布式锁【转载】cid:link_911、SpringBoot对接第三方系统的实现【转载】cid:link_1012、SpringBoot注解实现网络限速【转载】cid:link_1113、浅谈Java 线程池线程数怎么定【转载】cid:link_1214、MySQL中GTID 模式的使用【转载】https://bbs.huaweicloud.com/forum/thread-0212720697012681216-1-1.html

一、基于 Git Flow 的标准模型（经典）12345master         -- 生产环境（稳定版本）├── hotfix/*   -- 生产紧急修复分支release/*      -- 测试环境分支（预发布）develop        -- 研发环境（集成开发分支）├── feature/*  -- 功能开发分支具体对应关系：环境分支说明生产环境master / main生产环境的代码，必须是稳定可发布的测试环境release/* (如 release/v1.2.0)专门用于测试的分支，从 develop 拉出研发环境develop日常开发集成环境功能开发feature/* (如 feature/user-auth)从 develop 拉出，开发完成后合并回 develop紧急修复hotfix/* (如 hotfix/login-bug)从 master 拉出，修复后合并回 master 和 develop工作流程：新功能：feature/* → develop (研发环境)测试：develop → release/* (测试环境)上线：release/* → master (生产环境)紧急修复：hotfix/* → master (生产环境) + develop (研发环境)二、基于 GitHub/GitLab Flow 的简化模型（现代推荐）1234main/master    -- 生产环境├── staging    -- 测试环境分支（可选）├── develop    -- 研发环境分支（可选）└── feature/*  -- 功能分支环境与分支对应：环境分支说明生产环境main / master直接对应生产，每次合并都应该是可发布的测试环境staging / test专门用于测试的分支，从 main 拉出或定期同步研发环境develop (可选)集成环境，功能分支合并到此进行初步验证功能分支feature/xxx, fix/xxx所有开发都在独立分支进行特点：更简单直观功能分支通过 Pull Request 直接合并到 main可使用环境分支或通过 CI/CD 自动部署不同环境三、实际项目中的常见实践方案 A：三环境独立分支1234# 分支结构main/master     # 生产环境staging         # 测试环境（预发布）develop         # 研发环境（日常集成）方案 B：基于标签/提交的部署1234567# 分支结构main/master     # 主线分支feature/*       # 功能分支 # 通过Git标签区分环境git tag -a v1.0.0-prod -m "生产环境发布"git tag -a v1.0.0-staging -m "测试环境"方案 C：环境特定分支前缀1234# 分支命名约定env/production/xxx   # 生产环境相关配置env/staging/xxx      # 测试环境相关配置env/development/xxx  # 研发环境相关配置四、推荐的分支命名规范1.功能分支（研发阶段）123feature/user-authentication    # 用户认证功能feature/add-payment-method     # 添加支付方式feat/search-optimization       # 搜索优化2.修复分支123fix/login-page-crash           # 登录页面崩溃修复bugfix/memory-leak             # 内存泄漏修复hotfix/critical-security       # 紧急安全修复3.发布分支（测试阶段）12release/v1.2.0                 # 版本1.2.0发布分支release/2024-03-update         # 2024年3月更新4.环境配置分支123config/production              # 生产环境配置config/staging                 # 测试环境配置config/development             # 研发环境配置五、最佳实践建议1.团队约定优先12345678# 在项目README或CONTRIBUTING.md中明确约定# .git分支策略文档示例：├── main                      # 生产环境，保护分支├── staging                   # 测试环境，自动部署├── develop                   # 研发环境，持续集成├── feature/[ticket-id]-[description]  # 功能分支├── fix/[ticket-id]-[description]      # 修复分支└── release/v[version]        # 发布分支2.CI/CD集成示例1234567891011121314151617181920212223242526# .gitlab-ci.yml 或 GitHub Actions 配置示例stages:  - build  - test  - deploy # 自动部署到不同环境deploy_to_development:  stage: deploy  script: ./deploy.sh development  only:    - develop               # 合并到develop时部署到研发环境 deploy_to_staging:  stage: deploy  script: ./deploy.sh staging  only:    - staging               # 合并到staging时部署到测试环境    - /^release/.*$/        # 或发布分支 deploy_to_production:  stage: deploy  script: ./deploy.sh production  only:    - main                  # 合并到main时部署到生产环境    - tags                  # 或打标签时部署3.分支保护规则main/master: 强制代码审查、要求CI通过、禁止直接pushstaging: 强制代码审查、要求自动化测试通过develop: 要求基本检查通过六、总结推荐方案对于大多数中小型项目，推荐以下简单有效的方案：123456789# 核心分支main/master     # 生产环境（保护分支）staging         # 测试环境（预发布）develop         # 研发环境（可选，如不用则功能分支直接到staging） # 临时分支feature/*       # 功能开发fix/*           # 问题修复hotfix/*        # 生产紧急修复使用流程：从 main 创建 feature/xxx 分支开发开发完成后，创建 PR 合并到 staging（测试环境）测试通过后，创建 PR 合并到 main（生产环境）生产发现问题，从 main 创建 hotfix/xxx，修复后合并回 main 和 staging这样的结构清晰、简单，适合 CI/CD 自动化流程。最重要的是团队统一约定并严格执行。

在团队协作开发中，Git 是最常用的版本控制工具。然而，当我们在分支上提交了更改后执行 git pull 拉取远程代码时，常常会遇到冲突或对合并结果不满意的情况。面对这种情况，不要慌张，Git 提供了多种“后悔药”让你安全回退到理想状态。1. 场景回顾：典型的合并困境假设你在 knowledge 分支上进行开发，执行了以下操作：12345# 本地提交更改git commit -m “完成某个功能模块” # 拉取远程更改（可能产生冲突）git pull origin knowledge操作后，终端显示如下状态：1234On branch knowledgeYour branch and 'origin/knowledge' have diverged,and have 1 and 1 different commits each, respectively.All conflicts fixed but you are still merging.这表明你的本地分支和远程分支各自有一个不同的提交，并且 Git 已经自动解决了部分冲突，但合并过程尚未完成。2. 诊断当前状态在采取任何行动前，先要准确了解当前的 Git 状态：12345678# 查看当前状态git status # 查看提交历史git log --oneline # 查看操作记录git refloggit reflog 命令特别有用，它会显示 HEAD 指针的所有变动历史，让你能看到 git pull 之前的状态位置。3. 三种解决方案对比根据不同的需求和场景，你有以下三种主要选择：方案适用场景核心命令风险等级完成合并接受远程更改，继续协作开发git commit → git push低放弃合并发现合并方向错误，想重新开始git merge --abort → git reset --hard中完全重置想彻底丢弃本地更改，使用远程代码git merge --abort → git reset --hard origin/branch高4. 方案一：完成合并（推荐用于团队协作）如果你解决了冲突且认可合并结果，这是最直接的选择：12345# 提交合并结果git commit -m “Merge branch 'knowledge' of origin” # 推送到远程git push origin knowledge适用场景：你已经解决了所有冲突合并结果符合预期团队协作环境中需要保持提交历史完整5. 方案二：放弃合并，回退到合并前当合并方向错误或你想重新评估合并策略时：1234567891011# 1. 放弃当前的合并操作git merge --abort # 2. 查看操作历史，找到合并前的状态git reflog # 3. 回退到合并前的提交（假设合并前是 HEAD@{1}）git reset --hard HEAD@{1} # 4. 重新拉取并手动合并（如果需要）git pull origin knowledge --no-commit关键提示：git merge --abort 只有在合并未完成时才有效使用 git reflog 可以找到确切的回退点--no-commit 参数让 git pull 只合并不提交，给你审查的机会6. 方案三：完全重置到远程状态如果你想彻底丢弃本地所有更改，完全采用远程代码：123456789101112# 1. 放弃当前合并（如果处于合并中）git merge --abort # 2. 备份本地更改（安全措施）git stash # 3. 强制重置到远程分支状态git fetch origingit reset --hard origin/knowledge # 4. 清理未跟踪文件（谨慎使用）git clean -fd警告与建议：git reset --hard 会永久删除所有未提交的更改git clean -fd 会删除所有未跟踪的文件和目录在执行前，建议先用 git stash 备份当前状态7. 当代码已推送至远程的特殊处理如果你已经将不满意的合并推送到远程仓库，需要额外步骤：12345# 1. 本地回退到目标版本git reset --hard <目标commit-hash> # 2. 强制推送到远程（覆盖历史）git push --force origin knowledge重要警告：--force 推送会覆盖远程历史，可能影响其他协作者仅限个人分支或已与团队沟通后使用考虑使用 --force-with-lease（更安全，检查是否有他人推送）8. 最佳实践与预防措施为了避免频繁陷入合并回退的困境，建议遵循以下实践：养成良好习惯：在 git pull 前先 git fetch 查看远程变化使用 git pull --no-commit 给自己留出审查空间频繁提交，小步快跑，减少大范围合并冲突配置合适的工作流：12345# 设置 pull 策略为 rebase 而非 mergegit config pull.rebase true # 或者每次手动使用git pull --rebase origin knowledge使用可视化工具：GitKraken、Sourcetree 等工具提供直观的合并界面VS Code、IntelliJ IDEA 等编辑器的 Git 集成也很强大建立团队协议：明确分支合并规范约定何时可以强制推送建立代码审查流程9. 总结Git 合并后的回退操作是版本控制中的高级技能，理解不同方案的适用场景至关重要：轻量级调整：使用 git merge --abort 和 git reset --soft完全重新开始：使用 git reset --hard 回到特定节点团队协作时：优先完成合并，必要时沟通后强制推送记住，Git 的核心理念是“一切皆可恢复”。即使是 reset --hard 删除的内容，只要曾经提交过，通常都能从 reflog 中找回。大胆尝试，谨慎操作，版本控制的灵活性正是 Git 强大的体现。

基础暂存操作添加修改到暂存区通过git add命令将工作目录的修改标记为“准备提交”：12345678# 添加单个文件git add file.txt # 添加所有修改的文件（不包括未跟踪的文件）git add . # 添加特定类型的文件（如所有.js文件）git add *.js功能：将修改存入暂存区，但不会立即创建提交记录。 注意：未跟踪的文件需先用git add添加才能暂存。取消暂存误将文件添加到暂存区时，可通过以下命令撤销：12345# 取消单个文件的暂存git restore --staged file.txt # 取消所有文件的暂存git restore --staged .功能：将文件从暂存区移回工作目录，保留修改内容。一、Git Stash 是什么？核心作用git stash (中文常翻译为储藏 / 暂存 / 暂存搁置) 是 Git 中极其常用的命令，核心核心作用：临时「储藏 / 保存」工作区 + 暂存区 中所有未提交的修改内容，让你的工作区和暂存区立刻恢复到「干净状态」(和最近一次 commit 完全一致) ，且不会丢弃任何修改。什么时候必须用 Git Stash？（核心使用场景）这是使用 git stash 的黄金场景，遇到以下情况无脑用即可，也是工作中 99% 的使用场景：正在当前分支开发新功能 / 改 Bug，突然需要切换到其他分支（比如 test/release）处理紧急问题；当前分支的代码改了一半、还没写完、无法提交（提交不完整的代码会污染分支提交记录）；切换分支前，Git 强制要求「工作区干净」，否则会提示冲突或无法切换。简单说：想切分支、代码没写完、不想提交 → 用 git stash 就对了！二、Git Stash 基础核心命令（必会，高频使用）所有命令按「使用频率从高到低」排序，优先掌握前 5 个即可满足 90% 的开发需求，推荐死记硬背 + 熟练使用。1. 核心存储：git stash / git stash push12345678# 方式1：最简写法（推荐，工作中99%用这个）git stash # 方式2：保存修改并添加描述信息git stash save "描述信息" # 方式3：完整写法（和上面等价，push 可以省略） git stash push功能：把「工作区 + 暂存区」的所有未提交修改，临时保存到 Git 的「储藏栈」，工作区立刻变干净，所有修改被隐藏。2. 带备注存储：git stash push -m "备注信息" 【强烈推荐】123git stash push -m "首页轮播图样式修改-未完成" git stash push -m "订单模块bug修复-待测试"功能：和 git stash 功能一致，唯一区别是给本次储藏添加「自定义备注」。为什么强烈推荐？当你多次 git stash 后，会有多个储藏记录，带备注能一眼区分每个储藏对应的修改内容，不会混淆，避免后续恢复错代码！3. 查看所有储藏记录：git stash list1git stash list功能：查看 Git 储藏栈中所有的临时存储记录，输出格式如下：12stash@{0}: On dev: 搜索框样式优化-未完成 stash@{1}: On dev: 筛选条单选失效问题修复-待测试 储藏栈是「后进先出」的结构（栈结构）：最新的储藏记录排在最上面，编号 stash@{0}；每个记录包含：编号、所属分支、自定义备注。4. 恢复储藏的修改：git stash pop 【最常用恢复方式】12345# 恢复「最新的储藏记录」(stash@{0})，恢复后自动删除这条储藏记录 git stash pop  # 恢复「指定编号」的储藏记录，恢复后自动删除该记录 git stash pop stash@{1}核心功能：将储藏的修改恢复到当前工作区，恢复后代码和你 stash 之前完全一致（工作区 + 暂存区的修改都回来）。关键特性：pop = 「恢复 + 删除」，恢复后这条储藏记录就从栈中消失了，适合确认只恢复一次的场景。5. 恢复储藏的修改：git stash apply 【备选恢复方式】12345# 恢复最新的储藏记录(stash@{0})，恢复后「不删除」这条储藏记录git stash apply # 恢复指定编号的储藏记录，恢复后「不删除」该记录git stash apply stash@{1}核心功能：和 git stash pop 几乎一样，都是把储藏的修改恢复到工作区。关键区别：apply = 「只恢复，不删除」，恢复后这条储藏记录依然保存在栈中，适合需要多次恢复同一份修改的场景。✅ 重点区分：git stash pop vs git stash apply（必考必用）这两个命令是最容易混淆的，记住核心差异只有一个：是否删除储藏记录✅ git stash pop：恢复 + 删除记录 → 「一次性恢复」，用完即删，推荐日常使用；✅ git stash apply：只恢复，不删记录 → 「可重复恢复」，恢复后还能再次恢复这份修改，适合特殊场景。三、Git Stash 进阶命令（必会，解决 80% 的问题）1. 删除指定储藏记录：git stash pop储藏编号12345# 删除最新的储藏记录git stash drop stash@{0} # 删除指定编号的储藏记录git stash drop stash@{2}功能：只删除，不恢复。当你有一些无用的储藏记录，不想恢复只想清理时，用这个命令。2. 删除所有储藏记录：git stash clear1git stash clear功能：清空 Git 储藏栈中的所有储藏记录，慎用执行后无法恢复被删除的记录，适合确认所有储藏都无用时的批量清理。3. 查看储藏的「具体修改内容」：git stash show12345678# 查看最新储藏的「文件变更列表」（只显示文件名+增删行数） git stash show # 查看最新储藏的「完整diff详情」（显示具体修改的代码行，推荐） git stash show -p # 查看指定编号储藏的完整diff详情git stash show -p stash@{1}功能：在恢复储藏前，想先看看这份储藏里具体改了哪些代码，避免恢复错内容时，用这个命令，-p 参数是核心（patch 补丁模式），能看到完整的代码修改。1. 储藏「未追踪的新文件」：git stash -u / git stash --include-untracked123git stash -u# 等价写法git stash --include-untracked重要特性补充：默认的 git stash 只会储藏「已追踪的文件」（已经被 Git 管理的文件，比如之前 commit 过的文件），对于工作区中新建的、从未被 git add 过的新文件（未追踪文件） ，默认不会被储藏。加 -u 参数后：会把「已追踪文件的修改 + 未追踪的新文件」一起储藏，工作区彻底干净，连新文件都被隐藏了。5. 储藏「忽略的文件」：git stash -a / git stash --all123git stash -a# 等价写法git stash --all功能：最强的储藏命令，会储藏「已追踪文件修改 + 未追踪新文件 + .gitignore 中忽略的文件」（比如 node_modules、dist 等），适合需要完全清空工作区的场景，日常开发很少用，特殊场景（比如切换分支前彻底清理）可用。四、Git Stash 避坑指南 & 核心注意事项（重中之重，必看！）这部分是最容易踩坑的地方，很多人用 stash 出问题，都是因为没注意这些规则，全部记住，能避开 99% 的坑！✅ 注意 1：git stash 不会储藏的内容（默认行为）默认执行 git stash 时，以下内容绝对不会被储藏，会原封不动留在工作区：从未被 Git 追踪过的文件（新建的、没执行过 git add 的文件）；被 .gitignore 忽略的文件（比如依赖包、打包产物、日志文件）；已经提交到版本库的文件（只会处理「未提交」的修改）。✅ 解决办法：需要储藏未追踪文件用 git stash -u，需要储藏忽略文件用 git stash -a。✅ 注意 2：stash 的恢复与「分支无关」，但有最佳实践很多人误以为「在哪个分支 stash，就只能在哪个分支恢复」，这个认知是错误的！真相：Git 的 stash 是「全局的」，储藏的是「文件的修改内容」，不是和分支绑定的，你可以在 dev 分支 stash，然后切换到 test 分支恢复。最佳实践：尽量在哪个分支储藏，就在哪个分支恢复！原因：不同分支的代码差异可能很大，跨分支恢复 stash 大概率会触发「代码冲突」，处理冲突会增加不必要的麻烦，除非你明确知道两份代码无冲突。✅ 注意 3：储藏记录的「生命周期」储藏记录不是永久保存的，它是「临时缓存」，以下操作会删除储藏记录：执行 git stash pop 编号：恢复后自动删除该记录；执行 git stash drop 编号：手动删除该记录；执行 git stash clear：删除所有记录；仓库被删除 / 迁移：储藏记录会跟着仓库消失（不会同步到远程仓库）。✅ 注意 4：stash 无法储藏「空文件 / 空目录」如果你的修改只是新建了一个空文件 / 空目录，执行 git stash 不会生效，Git 会提示「No local changes to save」，这是 Git 的默认规则，无需处理。✅ 五、Git Stash 完整工作流程演示（工作中最常用，直接套用）给你一套完整的「标准流程」，遇到「代码没写完要切分支」的场景，直接按步骤执行即可，零错误、零踩坑，这是工作中最经典的用法：场景：在 dev 分支开发新功能，写到一半，需要切换到 test 分支修紧急 Bug12345678910111213141516171819# 步骤1：当前在 dev 分支，代码没写完，带备注储藏所有修改（推荐带-m）git stash push -m "dev-个人中心模块开发-未完成" # 步骤2：查看储藏记录，确认储藏成功（可选，养成好习惯）git stash list # 步骤3：切换到目标分支（此时工作区干净，切换无任何问题）git checkout test # 步骤4：在 test 分支修复 Bug，完成后正常提交git add . git commit -m "test-修复订单支付失败bug" # 步骤5：切回原分支dev git checkout dev # 步骤6：恢复之前储藏的未完成代码（推荐用pop，恢复后删除记录）git stash pop # 步骤7：继续开发未完成的功能即可，代码和之前完全一致 ✔️核心知识点速记核心概念git stash：临时保存未提交修改，让工作区变干净，核心场景「代码没写完要切分支」；stash 是「栈结构」，后进先出，最新的记录是 stash@{0}。必会核心命令（按优先级排序）储藏：git stash push -m "备注" （带备注，推荐首选）查看：git stash list恢复：git stash pop （恢复 + 删除，日常首选） / git stash apply（恢复不删除，备选）删除：git stash drop 编号（删指定） / git stash clear（删全部）查看修改：git stash show -p两大避坑重点默认不储藏「未追踪文件」和「忽略文件」，需要则加 -u / -a；尽量「同分支储藏、同分支恢复」，避免跨分支冲突。核心区别速记git stash pop → 恢复 + 删记录；git stash apply → 恢复不删记录。小剧场分享几个好看的MD主题qklhk-chocolatescrolls-lightChinese-rednicodevui-bluez-blueyu

1. 认证相关问题问题：用户名密码认证失败123# 错误信息remote: Invalid username or password.fatal: Authentication failed for 'https://github.com/user/repo.git'解决方法：12345678910111213141516# 方法1：重新配置用户信息git config --global user.name "Your Name"git config --global user.email "your.email@example.com" # 方法2：使用个人访问令牌（GitHub推荐）# 在GitHub生成Personal Access Token后git remote set-url origin https://username:token@github.com/user/repo.git # 方法3：使用凭据管理器git config --global credential.helper store# 下次push时输入用户名和token，会自动保存 # 方法4：清除已保存的凭据git config --global --unset credential.helper# Windows系统git config --global credential.helper manager-core问题：SSH密钥认证失败123# 错误信息Permission denied (publickey).fatal: Could not read from remote repository.解决方法：123456789101112131415161718192021# 1. 检查SSH密钥是否存在ls -la ~/.ssh/ # 2. 生成新的SSH密钥ssh-keygen -t ed25519 -C "your.email@example.com"# 或使用RSA格式ssh-keygen -t rsa -b 4096 -C "your.email@example.com" # 3. 启动SSH代理并添加密钥eval "$(ssh-agent -s)"ssh-add ~/.ssh/id_ed25519 # 4. 将公钥添加到GitHub/GitLabcat ~/.ssh/id_ed25519.pub# 复制输出内容到Git平台的SSH Keys设置 # 5. 测试SSH连接ssh -T git@github.com # 6. 修改远程仓库URL为SSH格式git remote set-url origin git@github.com:username/repository.git2. 分支和合并问题问题：推送被拒绝（非快进更新）12345# 错误信息To https://github.com/user/repo.git ! [rejected]        main -> main (non-fast-forward)error: failed to push some refs to 'https://github.com/user/repo.git'hint: Updates were rejected because the tip of your current branch is behind解决方法：123456789101112131415161718# 方法1：先拉取再推送（推荐）git pull origin main# 如果有冲突，解决冲突后git add .git commit -m "Resolve merge conflicts"git push origin main # 方法2：使用rebase保持线性历史git pull --rebase origin main# 解决可能的冲突git add .git rebase --continuegit push origin main # 方法3：强制推送（危险，慎用）git push --force origin main# 或更安全的强制推送git push --force-with-lease origin main问题：分支不存在123# 错误信息error: src refspec main does not match anyerror: failed to push some refs to 'origin'解决方法：12345678910111213141516# 1. 检查当前分支git branch # 2. 如果没有提交，先创建初始提交git add .git commit -m "Initial commit" # 3. 检查远程分支git branch -r # 4. 创建并推送新分支git checkout -b maingit push -u origin main # 5. 或者推送到现有的远程分支git push -u origin HEAD:main问题：上游分支未设置1234# 错误信息fatal: The current branch main has no upstream branch.To push the current branch and set the remote as upstream, use    git push --set-upstream origin main解决方法：1234567# 设置上游分支并推送git push -u origin main# 或git push --set-upstream origin main # 之后的推送就只需要git push3. 文件和内容问题问题：文件过大12# 错误信息remote: error: File large-file.zip is 123.45 MB; this exceeds GitHub's file size limit of 100.00 MB解决方法：123456789101112131415161718# 方法1：使用Git LFSgit lfs installgit lfs track "*.zip"git lfs track "*.pdf"git add .gitattributesgit add large-file.zipgit commit -m "Add large file with LFS"git push origin main # 方法2：从历史中删除大文件git filter-branch --force --index-filter \  'git rm --cached --ignore-unmatch large-file.zip' \  --prune-empty --tag-name-filter cat -- --all # 方法3：使用BFG Repo-Cleanerjava -jar bfg.jar --strip-blobs-bigger-than 100M my-repo.gitcd my-repo.gitgit reflog expire --expire=now --all && git gc --prune=now --aggressive问题：.gitignore 未生效1# 文件已被跟踪，.gitignore无法忽略解决方法：123456789101112131415# 1. 从跟踪中移除文件但保留本地文件git rm --cached filenamegit rm --cached -r directory/ # 2. 添加到.gitignoreecho "filename" >> .gitignoreecho "directory/" >> .gitignore # 3. 提交更改git add .gitignoregit commit -m "Remove tracked files and update .gitignore"git push origin main # 4. 清理所有未跟踪的被忽略文件git clean -fX4. 网络和连接问题问题：网络超时123# 错误信息fatal: unable to access 'https://github.com/user/repo.git/': Failed to connect to github.com port 443: Connection timed out解决方法：123456789101112131415161718# 1. 检查网络连接ping github.com # 2. 配置代理（如果使用代理）git config --global http.proxy http://proxy.server:portgit config --global https.proxy https://proxy.server:port # 3. 取消代理配置git config --global --unset http.proxygit config --global --unset https.proxy # 4. 增加超时时间git config --global http.postBuffer 524288000git config --global http.lowSpeedLimit 0git config --global http.lowSpeedTime 999999 # 5. 使用SSH而非HTTPSgit remote set-url origin git@github.com:username/repository.git问题：SSL证书验证失败123# 错误信息fatal: unable to access 'https://github.com/user/repo.git/': SSL certificate problem: certificate verify failed解决方法：123456789101112131415# 临时解决（不推荐用于生产）git config --global http.sslVerify false # 更好的解决方案：更新证书# Ubuntu/Debiansudo apt-get update && sudo apt-get install ca-certificates # CentOS/RHELsudo yum update ca-certificates # macOSbrew install ca-certificates # 重新启用SSL验证git config --global http.sslVerify true5. 仓库状态问题问题：工作目录不干净12345# 错误信息error: Your local changes to the following files would be overwritten by merge:    file1.txt    file2.txtPlease commit your changes or stash them before you merge.解决方法：12345678910111213141516# 方法1：提交更改git add .git commit -m "Save current changes"git push origin main # 方法2：暂存更改git stashgit pull origin maingit push origin main# 恢复暂存的更改git stash pop # 方法3：丢弃本地更改（谨慎使用）git checkout -- .git pull origin maingit push origin main问题：合并冲突1234# 错误信息Auto-merging file.txtCONFLICT (content): Merge conflict in file.txtAutomatic merge failed; fix conflicts and then commit the result.解决方法：12345678910111213141516171819# 1. 查看冲突文件git status # 2. 手动编辑冲突文件，解决冲突标记# <<<<<<< HEAD# 你的更改# =======# 远程更改# >>>>>>> branch-name # 3. 标记冲突已解决git add conflicted-file.txt # 4. 完成合并git commit -m "Resolve merge conflict"git push origin main # 5. 使用合并工具git mergetool6. 权限问题问题：没有推送权限1234# 错误信息remote: Permission to user/repo.git denied to username.fatal: unable to access 'https://github.com/user/repo.git/': The requested URL returned error: 403解决方法：123456789101112# 1. 检查仓库权限# 确认你是仓库的协作者或有推送权限 # 2. 检查远程仓库URLgit remote -v # 3. 更新远程仓库URLgit remote set-url origin https://github.com/yourusername/yourrepo.git # 4. 使用正确的认证信息git config user.name "Your Correct Username"git config user.email "your.correct.email@example.com"7. 分支保护规则问题问题：分支受保护12# 错误信息remote: error: GH006: Protected branch update failed for refs/heads/main.解决方法：123456789# 1. 创建功能分支git checkout -b feature/your-featuregit push -u origin feature/your-feature # 2. 创建Pull Request# 在GitHub/GitLab等平台创建PR # 3. 如果需要直接推送到保护分支（需要管理员权限）# 临时禁用分支保护规则，推送后重新启用8. 实用的故障排除脚本Git推送健康检查脚本1234567891011121314151617181920212223242526272829303132333435363738#!/bin/bash# git-push-check.sh echo "=== Git Push 健康检查 ===" # 检查Git版本echo "1. Git版本:"git --version # 检查当前分支echo -e "\n2. 当前分支:"git branch # 检查工作目录状态echo -e "\n3. 工作目录状态:"git status --porcelain # 检查远程仓库echo -e "\n4. 远程仓库:"git remote -v # 检查上游分支echo -e "\n5. 上游分支:"git branch -vv # 检查最近的提交echo -e "\n6. 最近的提交:"git log --oneline -5 # 检查网络连接echo -e "\n7. 网络连接测试:"if git ls-remote origin &> /dev/null; then    echo "✅ 可以连接到远程仓库"else    echo "❌ 无法连接到远程仓库"fi echo -e "\n=== 检查完成 ==="自动推送脚本（带错误处理）123456789101112131415161718192021222324252627282930313233343536373839#!/bin/bash# auto-push.sh set -e  # 遇到错误时退出 BRANCH=${1:-$(git branch --show-current)}MESSAGE=${2:-"Auto commit: $(date)"} echo "准备推送到分支: $BRANCH" # 检查工作目录是否干净if [[ -n $(git status --porcelain) ]]; then    echo "发现未提交的更改，正在添加..."    git add .    git commit -m "$MESSAGE"fi # 尝试推送echo "正在推送..."if git push origin "$BRANCH"; then    echo "✅ 推送成功!"else    echo "❌ 推送失败，尝试解决..."         # 尝试拉取并合并    if git pull --rebase origin "$BRANCH"; then        echo "✅ 成功拉取远程更改"        if git push origin "$BRANCH"; then            echo "✅ 重新推送成功!"        else            echo "❌ 推送仍然失败，需要手动处理"            exit 1        fi    else        echo "❌ 拉取失败，可能存在冲突"        echo "请手动解决冲突后重试"        exit 1    fifi9. 预防措施和最佳实践Git配置优化123456789101112131415# 设置全局配置git config --global push.default currentgit config --global pull.rebase truegit config --global rebase.autoStash truegit config --global merge.conflictstyle diff3 # 设置别名简化操作git config --global alias.pushf 'push --force-with-lease'git config --global alias.pushu 'push -u origin HEAD'git config --global alias.sync '!git pull --rebase && git push' # 配置编辑器git config --global core.editor "code --wait"  # VS Code# 或git config --global core.editor "vim"  # Vim推送前检查清单12345678910111213141516171819202122232425# 创建推送前检查脚本# pre-push-check.sh #!/bin/bashecho "推送前检查清单:" # 1. 检查代码质量echo "1. 运行代码检查..."# npm run lint 或其他代码检查工具 # 2. 运行测试echo "2. 运行测试..."# npm test 或其他测试命令 # 3. 检查敏感信息echo "3. 检查敏感信息..."if grep -r "password\|secret\|key" . --exclude-dir=.git --exclude-dir=node_modules; then    echo "⚠️  发现可能的敏感信息"    read -p "是否继续推送? (y/N): " confirm    if [[ $confirm != [yY] ]]; then        exit 1    fifi echo "✅ 检查通过，可以推送"10. 常用Git推送命令总结1234567891011121314151617181920212223# 基本推送git push                          # 推送当前分支到上游git push origin main             # 推送到指定远程分支git push -u origin feature      # 推送并设置上游分支 # 强制推送git push --force                 # 强制推送（危险）git push --force-with-lease      # 安全的强制推送 # 推送标签git push --tags                  # 推送所有标签git push origin v1.0             # 推送指定标签 # 删除远程分支/标签git push origin --delete branch-name  # 删除远程分支git push origin --delete tag-name     # 删除远程标签 # 推送所有分支git push --all origin            # 推送所有分支 # 推送但跳过CIgit push -o ci.skip origin main  # GitLabgit push origin main --no-verify # 跳过Git hooks通过理解这些常见问题和解决方案，应该能够处理大部分 git push 过程中遇到的问题。在执行任何破坏性操作（如强制推送）之前，务必备份代码并确保了解操作的后果。

1. 场景描述作为一个使用 git 作为版本控制的程序员，相信各位都遇到过这种问题，文件名或目录名的大小写整错了场景描述比如：想要创建一个文件 User.php，但是文件名打成了 user.php，并且已将 user.php 提交到了版本库然后，你应该会将错误的 user.php 修改为正确 User.php，但是发现 git 没有监听到文件发生变化问题原因这是因为 git 默认不区分文件名的大小写，也就是对大小写不敏感，所以此时 git 并不认为文件发生变化了我的解决办法先尝试使用 git mv 命令从工作区和暂存区重命名文件，发现是不行的，继续尝试其他方法12$ git mv user.php User.phpfatal: destination exists, source=liang.php, destination=Liang.php之前我遇到这种问题，会先修改其名称（不仅仅修改大小写），提交到版本库，然后再修改为正确的名称，再次提交比如：将 user.php 修改为 user1.php 后提交到版本库，然后再修改为 User.php，再提交到版本库但是，这种办法肯定不好的，为了解决这个问题不仅仅是多了两个提交记录，而且还要自己去找到大小写错误的文件其实，git 提供了严格区分大小写的配置项，接下来我们学习一下这个配置，当修改了名称的大小写，让 git 自己去发现2. 配置命令查看当前是否忽略大小写配置，输出结果：true（忽略大小写，默认配置）、false（已经严格区分大小写）1git config --get core.ignorecase全局设置，将忽略大小写关闭，也就是开启大小写敏感，从而能够正确识别文件名大小写的更改1git config --global core.ignorecase false不过，有时从远程仓库拉取到本地时，当前项目的 git 配置可能默认就是忽略大小写（经测试 gitee 是这样的）通过查看本地仓库配置文件内容，或者查看本地仓库配置都可以证实1234# 查看本地仓库配置文件内容cat .git/config# 查看本地仓库配置中的忽略大小写配置git config --local --list | grep ignorecase因为项目配置优先级高于全局配置，所以此时全局配置开启大小写敏感已经失效，需要手动设置当前项目开启大小写敏感1git config core.ignorecase false3. 流程分析开启大小写敏感后，修改文件名，git 能监听到文件变化了，直接提交是不是就可以将文件重命名成功了呢 ？将 user.php 重命名为 User.php，查看状态可以发现user.php 没有提示被删除，所以它还在被 git 管理追踪User.php 是一个没有追踪的文件，需要将它提交到暂存区12345678On branch masterYour branch is up to date with 'origin/master'. Untracked files:  (use "git add <file>..." to include in what will be committed)    User.php nothing added to commit but untracked files present (use "git add" to track)如果直接将 User.php 提交到版本库，会怎么样 ？你会发现远程库既有 user.php，又有 User.php（此时你是不是很无语）123git add User.phpgit commit -m '将 user.php 修改为 User.php'git push因为远程库有两个相同名称的文件（只是大小写不同），别人 clone 仓库时，能拉取成功，但是会有以下提示123456warning: the following paths have collided (e.g. case-sensitive pathson a case-insensitive filesystem) and only one from the samecolliding group is in the working tree:   'User.php'  'user.php'所以，我们需要将远程库的无用的 user.php 删除掉。然后，别人重新 clone 就可以得到正确的 User.php 了123git rm --cached user.phpgit commit -m '删除暂存区中的 user.php'git push4. 最佳实践首先，关闭忽略大小写，也就是开启大小写敏感，修改文件名称时让 git 可以追踪的到1git config core.ignorecase false手动修改文件名称，然后从暂存区删除旧文件，将新文件提交到暂存区12git rm --cached user.phpgit add User.php此时查看状态，也可以发现当前确实是一个重命名的操作123456On branch masterYour branch is up to date with 'origin/master'. Changes to be committed:  (use "git restore --staged <file>..." to unstage)    renamed:    user.php -> User.php然后正常提交并推送到远程库即可12git commit -m 'renamed: user.php -> User.php'git push

Git撤销命令revert与reset区别？

Git Revert特定文件/路径的实现方法

使用Git怎么实现revert？

在使用 Git 进行协作开发时，“拒绝推送（push rejected）” 怎么解决

遇到 Git 推送失败的问题,尤其是在初次配置远程仓库或网络环境受限的情况下,

git如何回退已提交的代码中的指定文件，有几种方法

Git Push失败：HTTP 413 Request Entity Too Large

1、 使用Git实现revert的完整操作步骤【转载】cid:link_02、C++中new关键字用法示例详解【转载】cid:link_13、在C# WinForm项目中跨.cs文件传值的六种常用方案【转载】cid:link_24、 一文带你搞懂Java中Error和Exception的区别【转载】cid:link_35、 Java中实现Word和TXT之间互相转换的实用教程【转载】cid:link_46、MyBatis-Plus 默认不更新null的4种方法【转载】cid:link_57、SpringBoot接口防抖的5种高效方案【转载】cid:link_68、 Java中锁分类及在什么场景下使用【转载】cid:link_79、 Java中锁的全面解析之类型、使用场景、优缺点及实现方式(示例代码【转载】cid:link_810、 Caffeine结合Redis空值缓存实现多级缓存【转载】cid:link_911、在PostgreSQL中优雅高效地进行全文检索的完整过程【转载】cid:link_1012、MySQL CDC原理解析及实现方案【转载】cid:link_1113、 PostgreSQL优雅的进行递归查询的实战指南【转载】cid:link_1214、Redis 常用命令之基础、进阶与场景化实战案例【转载】https://bbs.huaweicloud.com/forum/thread-0212720487861500817-1-1.html15、Git中忽略文件机制的.gitignore与.git/info/exclude两种方式详解【转载】https://bbs.huaweicloud.com/forum/thread-0212720487688092711-1-1.html