• git patch制作相关简介


    很失败,工作三年多了,才会用git am相关指令,而且一直自诩从事linux驱动、内核开发的老手,哎!

    本文作为自己对自己这几年来混吃等死的批判。

    此处说明的是,在看完该文后,回头看这些内容:

    补丁可能是自己弄的或者是从社区获取的,不管是哪种,都需要添加上自己的信息,

    自己做的话,在git commit的时候可以:

    git commit -s #就可以将自己相关信息 signed off上去。

    从社区或者别处获取的,在打上去的时候,可以

    git am -s      #通过这种方式,同样就将自己信息signed off上去了。

    git format-patch制作patch常用的几种格式

    git format-patch常用的指令有如下几种:

    git format-patch HEAD^       #生成最近的1次commit的patch
    git format-patch HEAD^^      #生成最近的2次commit的patch
    git format-patch HEAD^^^      #生成最近的3次commit的patch
    git format-patch HEAD^^^^     #生成最近的4次commit的patch
    git format-patch <r1>..<r2>      #生成两个commit间的修改的patch(包含两个commit. <r1>和<r2>都是具体的commit号)
    git format-patch -1 <r1>         #生成单个commit的patch
    git format-patch <r1>            #生成某commit以来的修改patch(不包含该commit) 此处表示的是最新的commit到自己前面一个commit的所有patch
    git format-patch --root <r1>   #生成从根到r1提交的所有patch

    需要说明的是,git format-patch head^指令虽然正宗,但是输入指令个人还是觉得比较麻烦的,你可以直接采用如下指令生成patch:

    git format-patch -1              #生成当前commit的patch
    git format-patch -8         # 生成最新8个commit的patch,注意顺序,最新的commit的patch编号一定是0008-xxxx

     

    git format-patch cover-letter制作补丁说明

    补丁制作完成后,需要你的上级或者同事审查,这种情况下,你该怎么制作补丁呢???,你可以通过git format-patch  --cover-letter  -8指令,制作8个补丁,并包含一个0000开头的patch

    介绍该8个补丁的改动情况。

     打开该文件,你可以看到对这8个patch的总体介绍

    From fd6988496e79a6a4bdb514a4655d2920209eb85d Mon Sep 17 00:00:00 2001

    From: hanle <hanle@localhost.(none)>

    Date: Sat, 4 Jan 2020 23:40:27 +0800

    Subject: [PATCH 0/8] *** SUBJECT HERE ***    # 在此处总体介绍下你的补丁。

     

    *** BLURB HERE ***    # 在此处添加你个人对着系列补丁的一个介绍,不用介绍的太详细

     

    Amir Goldstein (1):

      locks: print unsigned ino in /proc/locks

     

    David Abdurachmanov (1):

      riscv: reject invalid syscalls below -1

     

    Florian Fainelli (3):

      ata: ahci_brcm: Fix AHCI resources management

      ata: ahci_brcm: BCM7425 AHCI requires AHCI_HFLAG_DELAY_ENGINE

      ata: ahci_brcm: Add missing clock management during recovery

     

    Linus Torvalds (1):

      Linux 5.5-rc4

     

    Luc Van Oostenryck (1):

      riscv: fix compile failure with EXPORT_SYMBOL() & !MMU

     

    Olof Johansson (1):

      riscv: export flush_icache_all to modules

     

    --

    2.24.1

     

    git am打补丁的技巧

    git打补丁的方式包括两种:

    git am 和 git apply,两者之间有什么区别呢?两者之间的区别在于commit信息,前者只要打补丁成功,必定包括自带的commit的信息,当然你可以-s 加上你本人的singed off信息。

    而后者相当于修改了文件,并且执行了git add -u *之类的指令,但是不会生成commit信息,这个信息需要你本人自己添加,也就是说,该补丁最后生成的commit信息是你自己需要

    构造的。

    下面具体介绍这两种指令

    git apply:

    git apply  xxx.patch                 # 打上patch
    git apply
    --stat xxx.patch        # 查看patch的情况 git apply --check xxx.patch        # 检查patch是否能够打上,如果没有任何输出,则说明无冲突,可以打上

    git am:

    git am xxx.patch                   # 将名字为0001-limit-log-function.patch的patch打上
    git am --signoff xxx.patch         # 添加-s或者--signoff,还可以把自己的名字添加为signed off by信息,作用是注明打patch的人是谁
    git am *.patch                  # 批量打上patch,并且安装000x的序号先后打上patch,此处需要说明的每一个patch之间最好没有依赖关系,如果有依赖关系,可以修改000x序号,
                          # 把需要被依赖的patch先打上。
    git am --abort  # git patch过程中如果遇到的冲突怎么办,可以通过加上--abort指令撤回打的patch。                                                       

    以上两种打patch的方式,可以根据需要操作,下面以git am为例,打补丁的过程中出现冲突该怎么处理。

     

    git am打补丁解决冲突的方法

    在打补丁的过程中,遇到冲突是不可避免的,尤其是patch来源于不一致的内核版本。

    如果出现冲突,相放弃打patch,直接git am --abort即可,当然一遇到冲突就放弃打patch,实在有点说不过去。

    如果在执行git am xxx.patch的时候,出现冲突,会自动在冲突文件所在的目录生成一个xxx.rej文件,里面介绍了冲突具体位置,需要按照xxx.rej的方式手动修改冲突内容。

    对于冲突较多的情况,这种手工的方式确实费时费力,但是有些情况下确实没更好的办法,若想打patch成功的话,只能这么做了。

    • 1、git am冲突后,可以先执行git apply --reject将不冲突的代码打入文件中。
    • 2、按照xxx.rej的指示,手动修改冲突文件内容,修改完成后,删除xxx.rej文件。
    • 3、执行git add .指令,将修改后的文件add进去。
    • 4、执行git am --resolved即可将有冲突的补丁打成功,若此过程还是失败,再次执行2~4步骤即可。
  • 相关阅读:
    springboot Serving Web Content with Spring MVC
    Java的String中的subString()方法
    required string parameter XXX is not present
    NMON监控linux性能
    Linux下Java性能监控
    Linux常用命令
    Loadrunner测试webservice协议总结
    AWR报告分析
    性能测试指标
    如何保证测试的覆盖率
  • 原文地址:https://www.cnblogs.com/haoxing990/p/12150603.html
Copyright © 2020-2023  润新知