git拉取gitlab代码（gitlabApi如何获取项目文件夹的commitId）

  在我们做配置管理系统和gitlab系统集成的时候
    
    
    
，有一个常见的场景     


     


     


，就是要获取某个文件的commitId 




 




 




 ，来记录本次配置文件提交的版本
    
    
    
。这个通过gitlabApi很容易实现：

GET /projects/:id/repository/files/:file_path?ref=:ref

其中：

id:是项目id file_path:文件路径

   

   

   
，注意     

     

     

，这里的file_path需要指定到文件  




  




  




 ，否则会报错


  


  


  
，例如：abc/file.txt ref:分支名称     
     
     
，例如：develop

通过此api就能很容易获取到某个项目中的文件commitId和其他一些相关信息     


     


     


。文档地址

curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/13083/repository/files/app%2Fmodels%2Fkey%2Erb?ref=master"

响应结果：

{ "file_name": "key.rb", "file_path": "app/models/key.rb", "size": 1476, "encoding": "base64", "content": "IyA9PSBTY2hlbWEgSW5mb3...", "content_sha256": "4c294617b60715c1d218e61164a3abd4808a4284cbc30e6728a01ad9aada4481", "ref": "master", "blob_id": "79f7bbd25901e8334750839545a9bd021f0e4c83", "commit_id": "d5a3ff139356ce33e37e73add446f16869741b50", "last_commit_id": "570e7b2abdd848b95f2f578043fc23bd6f6fd24d", "execute_filemode": false }

  但是如果现在需要获取一个文件夹的commitId   




   




   




 ，如果还是用以上方法



 



 



 
，file_path如果传一个文件夹路径               ，则该方法会报错    




    




    




 ，显然不适用 




 




 




 。那么我们如果要获取一个文件夹的commitId















，从而记录本次文件夹（包括其中所有文件）的提交版本               ，该如何实现呢？为此本人找遍了网上所有的资料     



     



     



 ，没有一个明确的解决方案














，甚至询问了时下最流行的人工智能chatGpt
    
    
    
，得到的回答如下：

  这里多说一句题外话     


     


     


，不得不说 




 




 




 ，chatGpt还是非常强大的

   

   

   
，他的回答可以说秒杀了我在网上找的90%的资料     

     

     

，写得是有理有据  




  




  




 ，看上去很有道理的样子


  


  


  
，而且回答的逻辑也很严谨     
     
     
，如果我没验证一番   




   




   




 ，看这个回答



 



 



 
，几乎挑不出任何毛病

   

   

   
。

  但是遗憾的是               ，chatGpt答对了开头    




    




    




 ，却没答对结尾     

     

     

。为啥这么说呢？因为第一个获取文件夹的api确实没给错















，但是获取到的文件夹返回对象返回的id               ，却不是我期待已久的commitId     



     



     



 ，而是一个treeId














，我们chatGpt给出来的信息
    
    
    
，似乎告诉我们必须要通过这个treeId来找到commitId     


     


     


，这才算是找到了这个文件夹的commitId  




  




  




 。

  按照chatGpt提供的第二个api 




 




 




 ，我们看到可以直接通过treeId获取到commitId

   

   

   
，于是我验证了一番     

     

     

，发现这个api并不是这么用的  




  




  




 ，为此我查阅了官方文档的api之后


  


  


  
，发现这个api根本没有这个treeId的传参     
     
     
，而且官方文档也根本没有通过treeId来找到commitId的相应api（我猜测可能是chatGpt的最新数据库只更新到了2021年   




   




   




 ，所以他了解到的gitlabApi版本落后的缘故



 



 



 
，但是他的回答确实已经给了我很大的参考价值               ，确实是个很棒的人工智能）


  


  


  
。

  就此    




    




    




 ，开发陷入卡壳状态















，苦思冥想不得其姐               ，按道理来说不应该呀     



     



     



 ，gitlab页面上明明能显示出文件夹的commitId














，gitlab却没有提供相应api能拿到这个commitId？这不科学
    
    
    
，莫非是方向走错了     


     


     


，其实并没一个通过treeId获取commitId的概念 




 




 




 ，是我被chatGpt误导了？

  这逼得我不得不研究了一下gitlab项目仓库中文件的commitId    
    
    
、文件夹commitId以及整个项目commitId的更新规律

   

   

   
，看看他们到底是怎么变化的     

     

     

，文件夹的commitId和文件的commitId到底是不是同一回事  




  




  




 ，为此


  


  


  
，我用一个gitlab的文档仓库的develop分支做了如下实验：

先记录下几个值：

project的commitId：d1a982d706df99ac4e1c5c0c331b9f65c6d16e6d

project根目录下文件夹abc的commitId:44ef733bb2fdd0b8d0661473351efd662b2e33b4

project根目录下文件hello.txt的commitId:621fe03c295f36c8e1941e43afcd82021daecb00

然后做如下操作： 修改abc文件夹下的文件hello.txt     
     
     
，此时   




   




   




 ，此文件的commitId更新为：a61557d137efb0ba2f578461bad10ec101270d88 此时



 



 



 
，观察abc文件夹的commitId               ，我们发现    




    




    




 ，他的commitId也变为了：a61557d137efb0ba2f578461bad10ec101270d88 此时















，再观察此project项目的commitId               ，我们发现     



     



     



 ，他的commitId也变为了：a61557d137efb0ba2f578461bad10ec101270d88 此时














，在观察abc文件夹中其他文件以及和abc文件夹同级的其他文件
    
    
    
，他们的commitId还是保持原样未变     
     
     
。

  此时     


     


     


，我们似乎隐隐约约得出了这样一个结论 




 




 




 ，某文件夹内的任一文件做了最新的一次修改

   

   

   
，其所在文件夹也会更新为这最新的一次修改     

     

     

，但是与这个文件同级的此文件夹下的其他文件  




  




  




 ，commitId不会变化   




   




   




 。

我们继续实验：

先记录下几个值：

project的commitId:a61557d137efb0ba2f578461bad10ec101270d88

project根目录下文件夹abc的commitId:a61557d137efb0ba2f578461bad10ec101270d88

project根目录下文件README.md

（和abc文件夹同级）的commitId:f6815e7bb31f7cf34a9f774a4c4b1966f6ae33e2 修改project根目录下文件README.md


  


  


  
，其commitId变为：7eb3a4f553196ea21867b97ab60c3e94163b8b25 观察project的commitId     
     
     
，竟然也变成了：7eb3a4f553196ea21867b97ab60c3e94163b8b25 再次观察abc文件夹的commitId   




   




   




 ，还是之前的：a61557d137efb0ba2f578461bad10ec101270d88



 



 



 
，并没有变化



 



 



 
。

  到此               ，我们似乎真的可以得出一个肯定的结论:项目下任一文件做了最新的一次修改（或是添加 


     


     


     、删除）    




    




    




 ，生成了一个新的commitId值















，这个值除了会更新文件本身的commitId               ，还会更新其所在文件夹的commitId值     



     



     



 ，这个规律一直向上一级文件夹延伸














，一直延伸到根目录更新project的commitId
    
    
    
，但其他文件或非此文件的父文件夹的commitId不会随之变化               。

  换句话说     


     


     


，project的commitId会一直随着他下面任一文件或文件夹的最新的一次更新而变化（可以把project根目录当做是这个项目所有文件的父文件夹）    




    




    




 。project下任意的子文件夹 




 




 




 ，也会随着其文件夹下任一文件或文件夹的最新一次更新而变化

   

   

   
，并且也会引起最高层父文件夹     

     

     

，也就是project根目录commitId的变化















。

  根据以上在gitlab仓库的亲身体验  




  




  




 ，我们形成了一个概念


  


  


  
，那就是文件夹本身的commitId其实就是这个文件夹下最新的一次文件提交的commitId     
     
     
，那我们似乎有了一个新的思路：前面chatGpt提供的获取文件夹commitId的解决方案   




   




   




 ，我们是不是可以这么变通一下



 



 



 
，第一个api获取某路径下的文件树               ，获取到的文件树的集合    




    




    




 ，我们来过滤判断此文件夹存不存在















，如果存在               ，那么第二个获取commits的api的真是用法     



     



     



 ，可以传路径参数














，查出此文件夹路径下所有的commitId的提交集合
    
    
    
，然后从这个集合中根据提交时间排序     


     


     


，找出最新的一次提交的commitId 




 




 




 ，即为这个文件夹的commitId               。

代码实现如下（这里为了调用gitlabApi的方便

   

   

   
，我们在项目中引入了gitlab4j-api的jar包     

     

     

，实际就是对http请求gitlabApi的封装）：

override fun getFileInfoTest( token: String, domain: String, projectId: String, filePath: String, dirName: String, ref: String ) { val host = if (domain.startsWith("http")) { domain } else { "https://$domain" } val gitlab = GitLabApi(host, token) //获取指定文件目录下的文件树 val fileTree = gitlab.repositoryApi.getTree(projectId, filePath, ref) //过滤目标文件夹  




  




  




 ，判断文件夹在指定目录存不存在 val dirExsit = fileTree?.filter { it.path == "$filePath/$dirName" && it.name == dirName } if (CollectionUtil.isEmpty(dirExsit)) { println("文件夹不存在") } //如果名称不为空


  


  


  
，说明此文件夹存在     
     
     
，则找出此文件夹下所有的commit提交记录 val commits = gitlab.commitsApi.getCommits(projectId, ref, "$filePath/$dirName") if (CollectionUtil.isEmpty(commits)) { println("commits不存在") } //返回的提交记录结果集已经按照提交时间从大到小排序   




   




   




 ，只需要拿出第一条记录



 



 



 
， //即为此文件夹下所有文件的最新一次提交               ，即为此文件夹的提交commitId val commit = commits[0].toString() println(commit) }