作者：京东批发 田翻新、耿蕾
一、背景
1.祖传代码不敢随便改变，影响范畴无奈评估。并且组内时常有因为批改了某块代码，导致其余业务受到影响，产生bug，影响生产。
2.研发提测实现后，测试进入测试后常常会向研发询问本次需要改变影响范畴，以此来确定测试用例，以达到精准测试，晋升整个需要的品质，缩短交付周期。
那么，如何能力躲避这种隐患？有没有一种工具可能帮助代码研发及review人员更加准确的判断以后代码改变影响范畴，有没有一种办法可能提供除了业务逻辑条件验证，针对代码作用范畴，给测试人员提供准确验证链路？
二、计划调研
技术计划调研
通过各方材料查找及比对，最终咱们整顿了两个满足咱们需要的计划：
1.IDEA提供了显示调用指定Java办法向上的残缺调用链的性能，能够通过“Navigate -> Call Hierarchy”菜单(快捷键：control+option+H)应用，毛病是并没有向下的调用链生成。
2.开源框架调研：wala/soot动态代码剖析工具。
针对上述的调研，大抵确认了两种计划，集中剖析两种计划的优劣，来制订合乎咱们目前状况的计划：
| 工具名称 | 劣势 | 劣势 | 是否合乎 |
|---|---|---|---|
| Call Hierarchy | 反对办法向上调用链 | 性能比拟繁多，数据无操作性 | 否 |
| wala/soot动态代码剖析 | 可能欠缺的剖析Java中任何逻辑包含办法调用链，且满足咱们目前的需要 | 臃肿，简单繁琐，性能过于宏大 | 否 |
通过后期的比拟以及相干工具的材料调研、工具功能分析，并思考到前期一些个性化性能定制开发，以上工具不太满足咱们目前的需要，所以决定本人入手，饥寒交迫，尝试从新开发一个可能满足咱们需要的工具，来帮助研发以及测试人员。
三、计划制订
预期：工具尽量满足全自动化，研发只须要接入即可，缩小研发参加，晋升整个调用链展现和测试的效率。并且调用链路应该在研发打包的过程中触发，而后将数据上传至服务端，生成调用链路图。
上述计划制订实现后，须要进一步确认实现步骤。后期咱们确认了工具的大略的方向，并进行步骤合成，依据具体的性能将整个工具拆分成六个步骤
1.确认批改代码地位（行号）。与git代码治理关联，可能应用git命令，去提取研发最近一次提交代码的有变动的代码行数。
2.依据步骤1确认收集到影响的类+办法名+类变量。
3.依据2中确认的类+办法名称生成向上和向上的调用链。包含jar/aar包。
4.依据3中生成的调用链实现流程图的展现。
5.自定义正文标签Tag阐明以后业务，并提取Tag内容。
6.本地数据生成并上传服务端生成调用流程图。
整体流程图如下：
四、计划施行
1.定位源代码批改地位行号。
首先咱们应用 git diff --unified=0 --diff-filter=d HEAD~1 HEAD命令 输入最近一次提交批改的内容，且已只git diff 会依照固定格局输入。
通过提交增、删、改的批改，执行git diff命令，对输入内容进行察看。
举例：某次提交批改了两个文件，如下
RecommendVideoManager.java
ScrollDispatchHelper.java
git diff命令执行后，输入以下内容：
技术计划：
a.按行读取输入内容，读取到到diff 行，则辨认为一个新的文件，并用正则表达式提取文件名 ：
String[] lines = out.toString().split("\r?\n");Pattern pattern = Pattern.compile("^diff --git a/\S+ b/(\S+)");![]()
b.用正则表达式提取 @@ -149 +148,0 @@ ，用来解析代码批改行数:
Pattern pattern = Pattern.compile("^@@ -[0-9]+(,[0-9]+)? \+([0-9]+)(,[0-9]+)? @@");![]()
c.针对咱们的需要，咱们只关怀本次批改影响的是那个办法，不关怀具体影响了哪些行数，所以咱们只须要
int changeLineStart = Integer.parseInt(m.group(2));![]()
就拿到了本次批改，批改开始的代码行数, 在联合ASM就能够获取到本次改变影响的具体方法。
2.利用获取的行号定位具体的办法。
根据上述1步骤中定位出研发每次提交的批改的Java源文件和改变的行号地位，咱们须要定位批改代码行号所归属的办法名称，再由办法名称+类名+包名去定位本次批改的影响链路。
如何去定位？
首先确定的是，研发在工程中只能批改的是工程中的源文件，所以咱们能够在遍历收集整个工程的源文件的过程中依据已知的批改行号来确定批改的办法名称，进而晓得整个办法的调用链路。而对对于那些没有落到办法体范畴之内的行号，基本上能够确认为类变量或常量，思考到对于常量批改也可能影响到业务逻辑，所以咱们也会对批改的Field进行高低调用的范畴的查找，所以须要记录。所以整个过程分成两个局部：
a.遍历源码Class文件，获取整个类的Field；
b.遍历Class文件的过程中，通过visitMethod遍历整个办法体，记录办法的初始行号和完结行号，来定位办法；
首先是a局部，确认Field，ClassVisitor提供现成的办法：
@Override public FieldVisitor visitField(int access, String name, String desc, String signature, Object value) { Log.i("jingdong","Field name is :%s desc is %s: ",name,desc); return super.visitField(access, name, desc, signature, value); }所以咱们能够在文件中间接取得整个类的Field。而后去依据行数去判断是否有对Fields有批改。如果Fields有批改，那么咱们能够根据上述办法去比对，那么就能够取得哪个Field被批改。
接下来是b局部，在遍历Class文件的过程中，通过visitMethod办法，重写AdviceAdapter类来提供MethodVisitor，在遍历过程中，完确定研发批改影响的类及办法，具体实现可分为以下步骤：
2.1 获取源文件编译好的Class文件；
apk的编译过程中有很多的task须要执行，各个工作环环相扣有序的执行，咱们要获取编译好的Class文件，须要在特定的工作之间。咱们晓得在Java Compiler之后，不论是R.java抑或是aidl，再或者是Java interfaces都会编译成.class文件，在编译实现后会接着实现dex的编译，所以咱们尽可能的在dex编译之前实现class文件的解决，这种仅仅是思考到宿主或者独自的插件工程计划，然而对于主站业务来说，会有各种各样的组件aar，aar的编译编译不会走dex编译，所以针对这些组件工程，咱们也须要思考到，简略的形式就是咱们去监听aar编译的task，而后再做一些解决，所以在Plugin的apply办法中须要进行辨别解决，代码如下：
project.afterEvaluate { def android = project.extensions.android def config = project.method if (config.enable) { //利用级别 if (project.plugins.hasPlugin('com.android.application')) { android.applicationVariants.all { variant -> MethodTransform.inject(project, variant) } }else{ //aar编译解决-- //这里咱们是在compileReleaseJavaWithJavac之后运行自定义Task Task javaWithJavacTask = project.tasks.findByName("compileReleaseJavaWithJavac") if (javaWithJavacTask != null) { def customTask = project.tasks.create("JDcustomTask", JdParseClassTask.class) javaWithJavacTask.finalizedBy(customTask) }else { new GradleException("创立task失败~~") } } } }两者的解决逻辑统一，也就是在Task的监听有些区别，所以上面咱们不反复复述，以MethodTransform为主线进行解说。
那有的同学就问了，为啥咱们不间接对源文件.java文件进行解决呢？
因为，就目前京东主站我的项目而言，各个aar模块互相调用，如果咱们仅仅应用源文件进行扫描，各个aar或者jar包的调用链会断掉不全面，影响代码review人员及测试人员的测试用例残缺度。
接下来是代码实现，咱们监听工作执行，并针对须要监听的工作发展咱们的Class收集操作：
//Projectproject.getGradle().getTaskGraph().addTaskExecutionGraphListener(new TaskExecutionGraphListener() { @Override public void graphPopulated(TaskExecutionGraph taskGraph) { for (Task task : taskGraph.getAllTasks()) { //对满足咱们需要的Task执行前， if(task.name.equalsIgnoreCase("transformClassesWithDexForDebug")){ //执行咱们的TrasnsformTask //省略。。。。 }}}})2.2 排除非class文件的烦扰，对源文件门路进行递归遍历；
代码的编译长短对研发的影响很大，所以编译时长很贵重，须要咱们尽量的缩小编译的时长，所以咱们在执行咱们自定义的Transform过程中，须要过滤并排除非Class文件，缩小不必要的节约。通过整顿次要为：R文件以及R文件的外部类R$*文件，包含R$string、R$styleable等等，所以，在遍历处理过程中咱们须要对R文件及R$*文件过滤。
public static final String[] UN_VISITOR_CLASS = {"R.class", "R$"};2.3 提供ClassVisitor类和MethodClass去收集Class及对应Method，并定位
这个步骤是最次要的一部分，这一部分次要获取两局部数据，第一局部是研发批改间接影响到的类和办法；第二局部是遍历整个源文件的所取得的类信息，次要包含类+各个办法以及各个办法体，也就是办法中的指令；
在拿到transformInvocation后咱们进行源文件文件夹遍历和所有jar包的遍历，在外层咱们定义好存储被影响的类列表（changedClassesList），和蕴含类信息的列表（classesInfoList），将两个列表作为参数，传递进去在遍历过程中赋值。这里值得注意的是，在进行jar解析过程中不须要进行changedClassesList，因为对于本工程来说研发人员不会间接对jar文件中文件操作。
//批改类列表List<LinkedClassInfo> changedClassesList = new ArrayList<>()//类信息列表List<Map<String, List<Map<String, List<MethodInsInfo>>>>> classesInfoList = new ArrayList<Map<String, List<Map<String, List<MethodInsInfo>>>>>()transformInvocation.inputs.each { TransformInput input -> //所有源文件生成的class input.directoryInputs.each { DirectoryInput dirInput -> collectDir(dirInput, isIncremental, classesInfoList, changedClassesList) } //所有jar包汇合 input.jarInputs.each { JarInput jarInput -> if (jarInput.getStatus() != Status.REMOVED) { //能够取到jar包汇合 collectJar(jarInput, isIncremental, classesInfoList,jarOutputFile) } } }在对源文件遍历过程中，咱们进行定位搜查。
遍历源文件根节点并读取：
if (file != null) { //根布局目录进行循环遍历 File[] files = file.listFiles() files.each { File f -> if (f.isDirectory()) { collectJar(f, classList,changedClasss,changedLineInfoMap) } else { boolean isNeed = true //对文件类型进行校验，排除一些无意义的配置性文件 //省略。。。 if (isNeed) { try { //类汇合（蕴含：类名+办法名+办法指令） Map<String, List<Map<String, List<MethodInsInfo>>>> mClassMethodsList = new HashMap<String, List<Map<String, List<MethodInsInfo>>>>() ClassReader cr = new ClassReader(new FileInputStream(f)) ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_FRAMES) //重写ClassVisitorAdapter ClassVisitorAdapter ca = new ClassVisitorAdapter(cw, mClassMethodsList,changedClasss ,changedLineInfoMap ) cr.accept(ca, ClassReader.EXPAND_FRAMES) classList.add(mClassMethodsList) //将类的整个办法和指令加进去 } catch (RuntimeException re) { re.printStackTrace() } catch (IOException e) { e.printStackTrace() } } } } }重写ClassVisitor，ASM提供的visit办法能够很不便的去辨认这个类的各种信息，而咱们用到的信息为两种，一种是接口类型的断定，一种是以后类的类名。对于接口，咱们没有必要去进行Method的拜访，对取得的类名信息咱们进行断定以后类是否是git最初提交有做过批改的的类：
@Override public void visit(int version, int access, String name, String signature, String superName, String[] interfaces) { cv.visit(version, access, name, signature, superName, interfaces); owner = name;//类名 //断定不为接口类型 isInterface = (access & Opcodes.ACC_INTERFACE) != 0; //这里判断是否批改是否蕴含此类 if (this.mChangedLineInfoMap!=null&&mChangedLineInfoMap.size()>0){ for (Map.Entry<String,ChangedLineInfo> changedLineInfoEntry:this.mChangedLineInfoMap.entrySet()){ String filePath = changedLineInfoEntry.getKey(); if(filePath.contains(owner)){ //蕴含此类 linkedClassInfo= new LinkedClassInfo(); linkedClassInfo.className = owner; mChangedLineInfo= changedLineInfoEntry.getValue(); methodNameList = new ArrayList<>(); linkedClassInfo.methodNameList = methodNameList; } } } }`在上述的visit中咱们定位了以后类是否与上次git提交的是否无关，接下来咱们须要MethodVisitor中进行有抉择的拦挡对应的Method的拜访。
重写MethodVisitor在visitMethod中进行拦挡解决，如果git批改相干在以后类中，则咱们在拜访Method时，进行办法体行数定位。
mv = new MethodVisterAdapter(mv, owner, access, //省略。。。 mChangedLineInfo //更改行数地位 );在MethodVisitor中，咱们能够通过零碎办法定位拜访办法的每条办法指令及指令对应的行数，所以咱们只有重写visitLineNumber办法即可实时的在visitMethodInsn办法中拿到办法体拜访行数，这里有个小的留神点就是，咱们在调用visitLineNumber返回的line不是咱们了解意义上的办法名称局部开始，而是从办法体的第一行代码计算开始，所以咱们在做判断的时候，须要留神，绝对办法体的首行，咱们更关怀办法体的变更，所以咱们只须要断定落在visitMethodInsn中的更改即可。有须要更加精密的断定，小伙伴能够进行更加精密的调研。
以下是visitLineNumber办法：
@Override public void visitLineNumber(int line, Label start) { this.lineNumber = line;//置换lineNumber super.visitLineNumber(line, start); }晓得了办法体开始的中央，咱们也须要晓得完结的地位，获取到完结地位后，咱们就能轻松的定位到咱们须要的定位的办法体，从而取得办法名称，进一步取得类的名称。ASM在MethodVisitor中提供了visitEnd办法，示意办法体拜访完结，那么咱们就能够在visitEnd中进行定位：
@Overridepublic void visitEnd() { super.visitEnd(); int startLine = this.startLineNumber; int endLine = this.lineNumber; boolean isContained = false; if (this.mChangedLineInfo!=null&&mChangedLineInfo.lineNumbers!=null&&mChangedLineInfo.lineNumbers.size()>0){ for (String line : this.mChangedLineInfo.lineNumbers){ if (line!=null){ int lineNum = Integer.parseInt(line); //是否落在xx办法中 if (lineNum>=startLine&&lineNum<=endLine){ isContained = true; break; } } } } if (isContained&&this.methodNameList!=null){ //蕴含在此办法中 MethodName nameContained = new MethodName(); nameContained.methodName = name; this.methodNameList.add(nameContained); } //保留 methodInsMapList.put(name, mMethodInsInfoList); }至此，咱们通过自定义ClassVisitor和MethodVisitor实现了对源文件的收集和定位。
总结一下思路：首先咱们拉取了研发最初一次在Git上提交的代码，通过剖析并找出法则，配合正则表达式匹配的形式，拿到批改的后缀为java的文件，又进一步的寻找法则筛选出对应java文件批改的行号；其次遍历工程源文件，利用自定义ClassVisitor和MethodVisitor进行类信息的收集包含类名、办法以及办法体指令，并在拜访过程中提交后有批改痕迹的文件通过行号进行定位；最初实现收集汇合的填充。这整个过程中用到很多比拟重要办法，比方：CLassVisitor中的visit、visitMethod、visitEnd，以及MethodVisitor中的visitLineNumber、visitMethodInsn、visitEnd等。
3.遍历查找对应办法的上行链路和上行链路
在二步骤中实现了定位类与办法，并且实现了整个工程的源文件遍历收集，接下来就能逐渐的整理出来，批改办法在整个工程中所带来的影响，
3.1 办法上行链路数据生成；
这一步骤相对来说比较简单，对于在上一步骤中，咱们失去的上次的git提交定位数据，及整个工程的源文件类中办法信息的汇合，咱们只须要将扭转的list汇合在工程源文件信息汇合递归循环，便能失去对应办法的上行调用链。而遍历的思路则是，递归向上扫描调用了变更汇合中的类以及办法，以此递归循环遍历，只有调用到相关联的办法就被收集，对于Android利用来说，研发所写业务逻辑，基本上终止于Activity或者Applicantion中，所以向上的是有起点的。
如下是一个简图：
3.2办法上行链路数据生成；
办法的上行链路相比上行链路来说更为扩散，须要咱们去定位变更办法体中所有的指令，也就是扫描办法体，以及办法体各个指令的上行链路，并且在日常的开发过程中，咱们的办法中有很大一部分调用的零碎API，所以上行链路的扫描比照上行链路更为简单。而对于研发或者测试，零碎的API可能对咱们的影响较小，所以在扫描上行链路的过程中，咱们须要去辨认以后办法体指令是否为零碎API。
在辨认去除零碎API后，剩下的即是咱们的业务逻辑办法，那么又回到了办法体中各个指令的上行链路扫描，办法跟上行链路统一。
对于零碎的API以及一些三方库，咱们大抵总结了一下几种，供大家参考：
public static final String[] SYSTEM_PACKAGES = {"java/*", "javax/*", "android/*", "androidx/*","retrofit2/*","com/airbnb/*","org/apache/*"};示意图如下：
至此，咱们实现了办法上/上行链路的搜寻。
4.正文及自定义Tag
下面三个步骤，咱们们实现了对应办法上/上行链路性能开发，然而整条链路上只是蕴含了对应的类名+办法名，对于研发来讲，对应的类的作用以及办法的实现是什么逻辑比较清楚，然而仅仅局限于研发，对于测试人员可能没什么用，也只是一堆代码而已。针对这一问题，咱们想到了正文，各个研发组在很早之前就开始接入京东自研的EOS来标准代码的正文，通过这么长时间的打磨也趋于欠缺。咱们能够通过正文的形式来与对应的业务逻辑。咱们构想可能通过某些伎俩去实现正文的获取，然而，正文可能也不能齐全的去表白以后的业务逻辑，咱们还须要提供具体的业务逻辑标注。
怎么解决呢？其实，总结起来就是，咱们要阐明上/上行链路波及到的类和办法解释以及业务阐明，并且能够利用一些非凡的标记去实现对应的一些非凡逻辑阐明。
基于代码的正文，咱们能够很容易的想到JavaDoc，包含Android的开发环境Android studio中也自带了能够生成源文件的javadoc（门路：Tools-->Generate JavaDoc），执行命令后几秒钟后，生成了一份残缺的文档。
既然自带的工具能够实现Java文件正文的提取，那么咱们也能够在代码中获取到对应的正文，通过相干材料，理解到，JDK中自带的tools.jar包能够实现JavaDoc的提取。
在将tools包上传Maven后在gradle中进行依赖，根本就实现了环境的配置。通过多方材料的查找及demo试验，tools包反对命令的模式生JavaDoc。这里须要留神的是，咱们不须要html模式的javadoc文档模式，所以须要进行一些自定义的货色来达到咱们本人的要求。
官网文档是这样说的：
If you run javadoc without the -doclet command-line option, it will default to the standard doclet to produce HTML-format API documentation.
也就说，咱们须要在命令行中增加 -doclet来进行自定义文档。并且给出自定义的Doclet类：
public static class JDDoclet { public static boolean start(RootDoc root) { JDJavaDocReader.root = root; return true; } }接下来简略的封装tools中的execute办法：
public synchronized static RootDoc readDocs(String source, String classpath,String sourcepath) { if (!Strings.isNullOrEmpty(source)){ //java源文件或者为包名 List<String> args = Lists.newArrayList("-doclet", JDDoclet.class.getName(), "-quiet","-encoding","utf-8","-private"); if(!Strings.isNullOrEmpty(classpath)){ args.add("-classpath");//source的class地位，能够为null，如果不提供无奈获取残缺正文信息（比方无奈辨认androidx.annotation.NonNull） args.add(classpath); } if(!Strings.isNullOrEmpty(sourcepath)){ args.add("-sourcepath"); args.add(sourcepath); } args.add(source); int returnCode = com.sun.tools.javadoc.Main.execute(JDJavaDocReader.class.getClassLoader(),args.toArray(new String[args.size()])); if(0 != returnCode){ Log.i(TAG,"javadoc ERROR CODE = %d\n", returnCode); } } return root; }其中命令中参数，感兴趣的小伙伴能够查看官网文档，这里就不再赘述了。
根本封装实现后，就能够间接应用了，然而思考到在遍历应用的过程中会呈现屡次调用解析ClassDoc的问题，这里还是倡议将解析过的Java文件进行缓存解决，不便间接调用，也能缩小整个编译的工夫，并且在解析过程中咱们也须要排除零碎类的解析。
//....略if(classDoc!=null){ javaDocFile.append("\n\n") //获取类正文并写入文件 javaDocFile.append(classDoc.getClassComment()) javaDocFile.append(className+"\n") doc = classDoc.getClassDoc() }//....略if (doc!=null){ for (MethodDoc methodDoc : doc.methods()) { //增加自定义Tag methodDoc.tags(MethodBuildConstants.CUSTOM_TAG) if (method.methodName.trim() == methodDoc.name().trim()){ Tag[] tags = methodDoc.tags() if (tags!=null&&tags.length>0){ //取自定义Tag内容 for (int i = 0;i<tags.length;i++){ if (tags[i].name() == "@"+MethodBuildConstants.CUSTOM_TAG){ javaDocFile.append(tags[i].text()+"\n") javaDocFile.append(method.methodName+"\n") } } }else{//如果没有tag则输入对应的所有正文 javaDocFile.append(methodDoc.commentText()+"\n") javaDocFile.append(method.methodName+"\n") } } } }这里咱们也给出自定义Tag，当然，在我的项目中能够依据本人的业务名称进行命名。
/** * 自定义tag标签 */public static final String CUSTOM_TAG = "LogicIntroduce";实现了性能的开发，咱们须要在代码中中进行验证，测试如下：
/** * 打印办法（谁调用就会被打印），会打印两次 * @LogicIntroduce 这个是自定义Tag getPrintMethod办法 */public static void getPrintMethod(){ System.out.println("我被调用了"); getPrintMethod2();}当咱们的办法调用链波及到getPrintMethod()时，就会提取@LogicIntroduce标签前面的内容，达到了获取业务逻辑阐明正文的目标。这样对于那些不动代码的非研发人员，也可能十分清晰的看懂这部分代码波及到的业务逻辑，测试也可能着重的进行测试了。
本地输入：
影响类：com/jd/fragment/test/utils/TestUtils.java （测试类）影响办法： getPrintMethod（这个是自定义Tag getPrintMethod办法）5.举荐理论业务应用
办法的调用高低链路在上述步骤中曾经生成，咱们能够在MarkDown中简略的生成调用链，至于要遵循什么样的格局，大家能够本人查阅，绝对比较简单不再开展。上面是举荐位最近一次批改波及到的局部流程图：
代码批改地位输入为：
com/jingdong/xxx/RecommendItem.java //被批改的文件252 //批改的行向上调用链展现：
向下调用链，咱们只取本办法体：
相干Javadoc输入：
//上行调用链影响类：com/jingdong/xxx/RecommendItem（举荐位根底数据bean对象）影响办法： productExpoData（生成曝光数据给内部应用） generateExpoData（商卡结构曝光用数据） setData（服务端JSON数据解析）影响类：com/jingdong/xxx/RecommendProductPageView （举荐UI组件）影响办法： toRecomendList（网络接口返回数据）影响类：com/jingdong/xxx/RecommendProductPageView$3（服务端数据处理（外部类））影响办法： toList（接口数据处理）//上行调用链影响类：com/jingdong/xxx/RecommendItem（举荐位根底数据bean对象）影响办法： productExpoData（生成曝光数据给内部应用） -com/jd/xxx/JDJSONObject五、总结
通过下面的形容，咱们整体上实现了再Android端的代码影响范畴工具摸索，过程中实现了Git定位，生成办法调用的上、下链路，以及通过JDK工具jar包实现正文以及自定义Tag的内容获取，也通过MarkDown生成了对应的流程图。上面是整个工程的流程阐明图：
对于这个工具来说，咱们仅仅是对Android客户端的摸索开发，目前已在举荐组进行试用，应用过程中还有一些问题以及流程须要进一步改善和优化，比方，当一个办法被多处调用则生成的关系图就会过来宏大，不容易被浏览；无奈突出调用链节点的一些要害节点；JavaDoc强依赖于研发，如果正文不标准或者不写，那整个链路的阐明就会断掉等等，咱们会持续性的去优化打磨这个工具，也会在应用过程中增加一些更贴近业务的性能，或者调整局部流程，比如说会在本地编译触发或者手动触发，或者增加一些JavaDoc的模板等等。这些性能会在业务应用过程中进行调整。后续，也会在服务端铺开，逐渐的拓展业务面，为咱们的业务开发交付降本增效。
参考文档：
https://docs.oracle.com/javas...
https://git-scm.com/docs/git-...