首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

Git - 从SHA1中查找文件名

Git 是一种分布式版本控制系统,用于管理代码和文档的更改。在 Git 中,每个提交都有一个唯一的 SHA1 哈希值,用于标识该提交。要从 SHA1 中查找文件名,可以使用以下命令:

代码语言:txt
复制
git log --name-only --pretty=format: --follow <file_path>

这个命令会显示指定文件的提交历史记录,包括每个提交中涉及的文件名。如果文件名在提交之间发生了更改,则该命令也会显示旧名称和新名称。

此外,还可以使用以下命令查找特定 SHA1 中的文件名:

代码语言:txt
复制
git show --name-only <SHA1>

这个命令会显示指定 SHA1 中涉及的所有文件名。

需要注意的是,Git 是一个分布式版本控制系统,因此可能存在多个不同的仓库副本,每个副本都可能具有不同的提交历史记录和文件名。因此,在使用上述命令时,需要确保在正确的仓库副本中进行操作。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

go已知列表查找字符串

01 May 2016 go已知列表查找字符串 最近在开发遇到一个需求,需要查找某个给定的字符串是否属于有效字符串。...例如以下字符串都是有效字符串: "key1" "key2" "key3" "key4" "key5" "key6" 若查找的字符串是key1,存在key1,所以key1是有效字符串,若查找的字符串是key0..."key2": true, "key3": true, "key4": true, "key5": true, "key6": true, } 使用map的特性查找某个键是的值...bug,唯一的方法就是不写代码; 方式三通过使用go标准库sort,将切片先排序后,使用二分法查找目标字符串,算法复杂读相对方式二和方式四较好,为O(logN),N为切片长度,可读性较好,比方式二更优,...若查找的字符串是key1,则时间复杂度O(1),但是若查找的字符串是最后一个字符串时,时间复杂度和方式二一样,都是O(N),N表示字符串个数,但是该方式没有没有使用任何数据结构,如果对内存开销要求高,可以推荐使用

2.8K70

git rm 暂存区删除内容

1. git rm 基本使用 ---- git rm 命令用于暂存区和工作区删除内容 一般情况下,我们删除文件都是手动将文件删除,但是这种删除方式使用 git status 查看状态就会看到文件在...Changes not staged for commit 的提示区域中 手动删除只是删除了工作区的文件,如果要将删除操作提交到版本库,则需要先将删除操作提交到暂存区 rm 4.txt git add...4.txt git commit -m '删除文件4.txt' 更加方便快捷的方式是使用 git rm 命令,它会将文件工作区和暂存区删除 git rm 4.txt git commit -m '删除文件...4.txt' 同理,删除目录只需要额外增加一个 -r 参数即可 rm -r git rm -r 2. git rm 命令参数 ---- 如果要删除 修改过并已提交到暂存区...的文件,则必须要用强制删除选项 -f, --force git rm -f 如果只想把文件暂存区移除,希望文件保留在工作目录,可以使用 --cached 选项 git rm --cached

2.4K20
  • Git 当更改一个文件名为首字母大写时

    一般开发在 Mac 上开发程序,并使用 Git 进行版本管理,在使用 React 编写 Component 时,组件名一般建议首字母大写。...test ~/Documents/ignorecase-test(master ✔) ls Test 解决方案 通过 git mv,在 Git 暂存区再更改一遍文件大小写解决问题 $ git mv...更改为不忽略大小写 [core] ignorecase = false 以下是产生的问题: 「修改文件名时,Git 工作区中一下子增加了两个文件,并且无法删除」 「git rm 删除文件时,工作区的两个文件都被删除.../ignorecase-test(master ✗) git add -A ~/Documents/ignorecase-test(master ✗) git ls-files Test test ~/...mv -f 和 mv 同时更改文件名,避免本地文件系统与仓库中代码不一致。

    1.6K20

    git原理和技巧

    再次使用git cat-file查看多出来的两个git object,如下 其中tree object中一次保存了文件权限,objects类型,sha1值(key),文件名 commit object...Tree: git中文件夹对应保存为tree对象,他用来解决文件名保存的问题,也允许我们将多个文件组织到一起。...分支和tag保存在哪 首先HEAD指针明文存储在.git/HEAD 分支则保存在.git/refs/heads tag保存在.git/refs/tags 然后这些分支文件的内容指向了具体某个...,先将变动暂存起来,再下次需要时再恢复,但是遇到冲突时需要手动解决冲突 https://www.cnblogs.com/zndxall/archive/2018/09/04/9586088.html git...提交历史删除一个文件 对所有的commit应用该操作,然后再放回原来的commit,但是这会更改所有git object的sha1哈希值,需要与其他还在使用这个项目的人沟通,不然commit的哈希值不一样会冲突

    30530

    git 补丁 - diff 和 patch 使用详解

    使用命令行 git diff 【commit sha1 id】 【commit sha1 id】 > 【diff文件名git format-patch 当前分支所有超前master的提交: git...根到指定提交的所有patch: git format-patch --root 4e16 某两次提交之间的所有patch: git format-patch 【commit sha1 id】.....–n 07fe –n 指 patc h数,07fe 对应提交的名称 故,单次提交即为: git format-patch -1 07fe git format-patch 生成的补丁文件默认1开始顺序编号...,并使用对应提交信息的第一行作为文件名。...第一步:首先,执行以下命令,自动合入 patch 不冲突的代码,同时保留冲突的部分 git apply --reject xxxx.patch 同时会生成后缀为 .rej 的文件,保存没有合并进去的部分的内容

    36.5K52

    源码解析:Git的第一个提交是什么样的?

    在 .dircache/objects 创建了 00 ~ ff 共256个目录。 .dircache/ 是Git的工作目录,最新版本的Git工作目录为 .git/ 。...遍历多个文件,读取并生成变更文件信息(文件名称、文件内容sha1值、日期、大小等),写入到索引文件。 遍历多个文件,读取并压缩变更文件,存储到objects文件,该文件为blob对象。...tree 对象由 + + 文件模式 + 文件名称 + 文件sha1值 拼装并压缩: ? 文件sha1值 使用binary格式存储,占用20字节。...同时要是一个目录下面子文件太多,那文件查找效率会降低很多。...索引文件读取到的变更文件信息使用数组存储,涉及到了比较多的申请释放操作,性能上是有损失的,可以优化成链表存储。 不过这些都不重要,重要的是 Git 的设计原理和思想。

    1.9K30

    Git实战

    ]" # 将tmp内容合并到当前分支 git merge tmp # 删除分支 git branch -d tmp 删除文件 保留副本操作 git rm --cache [文件名...检查文件每一行代码是谁提交的记录 git blame -L [起始行数],[文件名] 创建分支 #以当前节点作为分支的开始起点 git branch [分支名] #以SHA1作为分支开始起点 git...git stash #包含[SHA1]及之前的代码会被copy盗分支上 git branch [分支名] [SHA1] 重命名分支 在git重命名远程分支,其实就是先删除远程分支,然后重命名本地分支...*表示当前分支 在–之后的是记录分支的提交信息 像*+ [tmp] 远程2就表示该提交存在于两个分支 显示某分支某文件内容 git show [分支名]:[文件名] 显示某个节点某文件的内容...git show [SHA1] [文件名] 查看本地Git绑定的远程仓库信息 git remote -v 关于切换分支的逻辑 如果存在未被git追踪的文件,git是会将其忽略的 如果存在已追踪且被修改或删除

    86810

    这才是真正的Git——Git内部原理揭秘!

    然后将这些信息经过SHA1哈希算法得到对应的哈希值 58c9bdf9d017fcd178dc8c073cbfcbb7ff240d6c,作为这个object在Git仓库的唯一身份证。...它储存的内容来看可以发现它储存了一个目录结构(类似于文件夹),以及每一个文件(或者子文件夹)的权限、类型、对应的身份证(SHA1值)、以及文件名。 此时的Git仓库是这样的: ?...在一个merge提交还会出现多个父节点),提交的作者以及提交的具体时间,最后是该提交的信息。 此时我们去看Git仓库是这样的: ?...运行echo "333" > a.txt将a.txt的内容111修改成333,此时如上图可以看到,此时索引区域和git仓库没有任何变化。 ?...也就是说,就算你只是在文件添加一行,Git也会新建一个全新的blob object。那这样子是不是很浪费空间呢?

    1.4K30

    改变世界的一次代码提交

    Linus 在设计时,BLOB 仅记录文件的内容,而不包含文件名、文件属性等元数据信息,这些信息被记录在第二种对象 TREE 里。 TREE: 目录树对象。...在 Linus 的设计里 TREE 对象就是一个时间切片中的目录树信息抽象,包含了文件名、文件属性及BLOB对象的SHA1值信息,但没有历史信息。...sha1 值更新到 .dircache/index 缓存文件。...文件树列表按照 文件属性 + 文件名 + \0 + SHA1 值结构存储。写入对象成功后,返回该 TREE 对象的 SHA1 值。...回到文中开头提到的问题,如果我来设计 Git 的话,估计还是会已有工具经验(如SVN使用)上来延伸设计,甚至在我最早接触 Git 时候曾肤浅的认为 Git 就是 SVN + 分布式。

    82561

    Git 补丁 patch 使用方法

    [commit sha1 id] > [diff文件名] git format-patch 当前分支所有超前 master 的提交: 1 git format-patch -M master 某次提交以后的所有...根到指定提交的所有 patch: 1 git format-patch --root 4e16 某两次提交之间的所有 patch: 1 git format-patch [commit sha1 id...[commit sha1 id] 1git format-patch 365a..4e16 365a 和 4e16 分别对应两次提交的名称 某次提交(含)之前的几次提交: 1 git format-patch...[commit id] git format-patch 生成的补丁文件默认1开始顺序编号,并使用对应提交信息的第一行作为文件名。...因此除了 git apply 之外,还可以用更智能的 git am 命令使用此 patch,会在修改文件的同时将 commit 信息也一起应用到 git

    4.8K20

    文件系统上存储哈希对象:哈希算法以及目录结构对性能的影响

    根目录开始,每个目录文件的块数据,记录着该目录下直接包含(只包括直接相邻的一层,不包括子目录中间接包含的文件)的所有文件的索引信息(每一个称为一个 entry,内容包括文件名、inode号)。...根据背景知识2,假设我们使用 sha1 算法进行 key 哈希,并且 key 使用 hex 文本形式作为文件名,则每个文件的文件名长度为 40 字节,存到目录,一个 entry 就需要占用 4+2+2...方案1:所有 key 文件存储在同个目录下 由背景知识1可知:(忽略 htree)在某个目录下查找某个文件,相当于要遍历这个目录的所有 entry,直到找到匹配的文件名,即 O(n) 操作,n=目录内的直接文件数...以此类推… 本质上就是,在 n 层下,a = 85*(256^(n-1)) 个 key 以内是树查找,而超过 a = 85*(256^(n-1)) 个 key 则退化为顺序查找。...而每一次在目录查找文件,都需要遍历目录的(最坏情况下所有)目录块才能找到目标文件对应的 entry。

    1.1K30

    git mv 工作区和暂存区重命名内容

    前言 ---- git mv 命令用于移动或重命名一个文件、目录或软连接。 它会将内容工作区和暂存区重命名,手动重命名需要执行两步操作,git mv 一步即可 2....使用示例 ---- 创建一个 git 仓库并且做一个提交记录 git init echo 1.log >> 1.log echo 2.log >> 2.log git add . git commit...-m 'first commit' 将 1. log 重命名为 10.log(mv 命令) mv 1.log 10.log git add 1.log 10.log 将 2. log 重命名为 20....log(git mv 命令) git mv 2.log 20.log 总结: 手动重命名需要执行两步操作,使用 git mv 一个命令即可完成重命名 # 提交到版本库 git commit -m '重命名文件..., --verbose 重命名成功时默认不会提示,使用该参数可以看到提示 git mv -v

    46030

    解决 macOS Ventura 使用 sshgit 等无法正常使用的问题

    关键词:macOS Ventura、Ventura、SSH、git、Permission denied 若移动端访问不佳,请使用 –> GithubPage 版 问题描述 升级到 macOS Ventura...比如使用 git clone 、git pull 等去同步基于 SSH 地址的 git 仓库代码时,会提示 Permission denied (publickey) 。...定位问题 经过查证,macOS Ventura 内置使用了 OpenSSH_9.0p1,根据 OpenSSH 发行说明 可以得知, OpenSSH 8.8/8.8p1 版本开始,就默认关闭了 ssh-rsa...的后台等 本地重新启用 ssh 对 ssh-rsa 算法的支持 方案一:重新生成 ed25519 算法的密钥 ssh-keygen -t ed25519 执行上述命令后,按照提示输入信息,并记录好生成的密钥文件名信息...,可以考虑重新启用 RSA/SHA1 以允许连接或者进行用户认证。

    3.7K81
    领券