git整理commit的基本方法(拆分、合并、修改commit)

觉得整理commit还是非常重要的一种技能,看到有人已经很好地整理过了,也搬运到自己的博客中,以备不时之需。本文转载自:Git整理Patch的一些经验

U-Boot升级到了最后,需要将之前比较杂乱的commit重新整理,有的需要整合,有的需要拆分。在这个过程中深刻的体会到了git的强大和灵活性。这里总结一下大的步骤和中间用到的各种小技巧。

步骤

commandsusage
git checkout –b 新建一个branch来做整理的工作,保持原来的branch作为工作记录
git rebase –i 在新建的branch上,用rebase -i接squash的方法,将所有零碎的commit合成一个
git reset –soft HEAD~1这一步只将object store还原到working_base上。所有需要整理的改动都留在index上,以备下一步做stash
git stash save “stash message”将所有的改动放进stash中

至此,我们有了一个工作的基础,所有杂乱的commit被合成一个,并被放进stash中,以备后面一点点的commit进去。

接下来,最好过一遍所有的改动。记录下每个文件的改动包含了那些内容。以备后一步的按照不同的改动内容来合并commit。

git diff stash

举个简单的例子,假如总共有5个改动的文件a~e,分析它们的改动内容包含了四个不同的目的I~IV,如下所示:

文件a --- 目的I
文件b --- 目的II
文件c --- 目的II, 目的III
文件d --- 目的II, 目的IV
文件e --- 目的III

现在考虑按照不同的目的来组织不同的commit:

commit 1 - 目的I   - 文件a
commit 2 - 目的II  - 文件b,文件c和文件d的一部分
commit 3 - 目的III - 文件c的一部分,文件e
commit 4 - 目的IV  - 文件d的一部分

commit 1

commandsusage
git checkout stash 将stash中的文件a checkout出来,此时改动已放入index,我们可以直接commit
git commit –s完成commit 1

commit 2

commandsusage
git checkout stash .将stash中的所有文件checkout出来。这里不能用git stash pop,因为一旦pop了,stash也就消失了,也就无法进行后续的工作。也不能用git stash apply,因为apply是尝试merge,有时候反而会引起conflict,这不是我们想要的结果
git reset HEAD将所有改动移出index,但保留在working目录中
git add b将b的所有改动放入index
git add -p cinteractive的方式,将c的部分改动放进index
git add -p d同前
git commit -s完成commit 2
git clean -dfx由于工作目录是dirty的,所以这一步用以清空空座目录,与object store保持严格一致,用来进行测试。很容易想到git reset –hard HEAD,但是这个命令不会将add的文件清空,比如这个例子中的文件e,所以用clean -dfx是最彻底的,但运行前请确保目录中没有需要保存而未保存的文件。
git add -p的用法
    * add -p 会逐个显示文件中的每组改动,并询问是否要加入index
        – y : 放入index
        – n : 不要放入index
        – e : 手动编辑需要加入index的部分,常用来拆分一个改动块
            – “+”行,增加
            – “-”行,删除
            – “ “行,保持原样

第三个commit和第二个类似。不赘述。到第四个commit时,只剩下文件d,并且虽说d只有一部分与commit 4的目的相关,但由于d的其他部分在之前的commit已经放入object store了,所以又退化成和第一个commit类似的情况。

错误及补救措施

1. Commit到某个点以后,需要增减。

  • git rebase -i <targetCommit>~1: 对出错的commit,用e来表示需要更改

  • 修改:

这里常用的git命令有
    git checkout stash <file> 增加一个文件
    git diff stash <file> 某个文件需要改动
    git reset HEAD~1 <file> 将某个文件移出这次commit

无论如何,保证最后index中是修改过的正确改动。

  • git rebase –continue: 结束修改。

2. Commit到某个点后,发现前面某个commit需要拆分。

  • git rebase -i <targetCommit>~1: 回到拆分点,用e来表示需要更改
  • git reset –mixed HEAD~1: 将这个targetCommit的改动放回working directory,object store和index都还原成这个commit尚未放入的状态。
  • 拆分进行commit: 将这些改动拆分的进行commit。
  • git rebase –continue : 结束修改。

3. rebase -i遇到conflict。

  • 手动修改: 通常是先改成A,后改成B,此时改成B。也有先加上A,后加上B,这时需要取并集。有时A和B有相同的代码段时,这个代码段会被吃掉,修改的时候需要重新加上。
  • git add <file>: 将修改完的文件放入index。
  • git rebase –continue : 继续rebase。

4. 在git command中的运用。

  • git log <path>: 只显示修改了某个文件commits。
  • git log -p <path> : 同上,并且显示这个文件被修改的内容。commit中其他文件的修改则不被显示。
  • git diff … <path>: 只比较某个文件的改动。
<think>好的,我现在需要帮助用户了解如何通过Git提交修复相关的错误的最佳实践。首先,我得回顾用户提供的引用内容,特别是引用[3]提到的Bug Fixing过程,以及引用[1]和[2]中关于提交规范的资料。 首先,用户想知道的是在修复bug时如何正确使用git commit。根据引用[1],AngularJS的git-commit规范是一个常用的指南,它建议提交信息要有清晰的类型、作用域和主题。例如,fix(core): resolve memory leak in component。这样的格式有助于生成变更日志,并且让团队更容易理解提交的目的。 接下来,引用[2]提到可以使用git commit -a -m来快速提交所有跟踪的文件,但最佳实践可能不建议这样做,因为应该明确添加需要提交的文件,避免意外提交未跟踪的更改。不过,如果是小修复,可能可以接受,但最好还是分步操作。 然后,引用[3]强调了Bug Fixing的步骤,包括识别问题根源、编写修复代码、测试和记录。这提示在提交信息中需要详细说明问题原因和修复方法,方便后续审查和追踪。 我需要将这些信息整合成一个结构清晰的回答。可能的结构是分步骤说明最佳实践,每个步骤结合引用内容。例如,第一步是明确提交类型,使用fix:前缀;第二步是详细描述问题及修复方法;第三步是关联问题追踪系统;第四步是验证和测试;第五步是避免自动提交所有更改。 同时,用户可能希望了解具体的命令示例,比如git commit -m "fix(module): 描述修复内容 [#issue]"这样的格式。还要注意是否需要分阶段提交,使用git add选择相关文件,而不是用-a参数全部提交,以避免包含不必要的更改。 另外,需要提醒用户编写清晰的信息主体,而不仅仅是简短的说明。例如,在提交信息的主体部分解释问题的根本原因和解决的方法,这样其他开发者在查看历史时可以更容易理解。 最后,根据用户的要求生成相关问题,比如如何编写规范的提交信息、如何关联issue、自动化测试工具推荐等。这些问题需要与主题相关,帮助用户进一步探索。 总结一下,回答的结构应该包括提交格式规范、详细描述、关联问题、测试验证、避免自动提交,每个部分结合引用内容,并给出具体示例。同时确保使用中文,行内公式正确,没有使用markdown格式,保持自然的口语化表达。</think>### 如何通过Git提交修复Bug的最佳实践 #### 1. **明确提交类型(遵循AngularJS规范)** - 在提交信息开头使用`fix:`标识修复类型,例如: `fix(auth): 修复用户登录时令牌过期导致的崩溃` 此格式符合语义化提交规范,便于生成自动化变更日志[^1]。 #### 2. **详细描述问题与修复方法** - **问题根源**:在提交信息正文中说明Bug的触发条件和根本原因,例如: `当用户会话超过24小时未刷新时,后端返回401但前端未正确处理响应` - **修复逻辑**:简述代码修改的核心逻辑,例如: `添加全局拦截器,自动捕获401错误并跳转至登录页` 引用Bug Fixing原则需包含问题定位和代码修正过程[^3]。 #### 3. **关联问题追踪系统** - 如果使用Jira、GitHub Issues等工具,在提交信息末尾添加关联标识: `git commit -m "fix(api): 修复分页查询偏移量计算错误 [#ISSUE-123]"` 此操作可通过`Closes #123`等语法自动关闭关联任务(视平台支持)。 #### 4. **验证与测试记录** - 提交前需通过单元测试/回归测试,并在信息中标注验证方式: ```bash git commit -m "fix(ui): 修复移动端菜单栏重叠问题 - 添加媒体查询动态调整布局 - 通过Chrome DevTools设备模拟器验证" ``` #### 5. **避免使用`-a`自动提交(引用[2]的注意事项)** - 推荐显式添加文件: ```bash git add src/utils/errorHandler.js # 仅添加与修复相关的文件 git commit -m "fix(core): 修复未处理的Promise拒绝问题" ``` - 使用`git status`确认无多余文件混入提交。 #### 6. **多修复分离提交** - 若同时修复多个独立Bug,应拆分提交: ```bash # 修复内存泄漏 git add src/components/Chart.js git commit -m "fix(performance): 移除未注销的事件监听器" # 修复样式错误 git add src/styles/dashboard.css git commit -m "fix(ui): 调整表格行高兼容Safari" ``` *** ### 附:标准修复提交示例 ```bash fix(database): 修复并发写入导致的事务死锁问题 - 修改事务隔离级别为READ COMMITTED - 添加重试机制处理DeadlockException - 新增单元测试test_concurrent_write.py验证 Closes #456 ``` ***
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值