【Linux】Git启示录

本文详细介绍Git的基本使用指令,包括仓库初始化、配置用户信息、状态查询、文件添加与删除、提交更改、日志查看、分支操作及远程仓库管理等。通过这些指令的学习,可以帮助读者更好地掌握Git版本控制系统的使用。

基础指令

git init 仓库初始化,在目录中生成.git目录

git config user.name 项目级别签名
git config user.email 信息存放于.git/config

git config --global user.name 用户级别签名
git config --global user.email 信息存放于~/.gitconfig

git status 分支信息、工作区、暂存区状态

git add file 添加文件
git rm --cached file 删除追踪
git rm file 删除追踪和文件

git commit 提交commit commit所有改动文件
git commit -m “commit message” file 直接输入commit信息并提交某一个文件

git log 查看完整历史记录
git log --pretty=oneline 简洁显示 完整哈希
git log --oneline 简洁显示 简洁哈希
git reflog 简洁显示 HEAD@{移动到当前版本需要的步数} 后退之后还能显示之前的版本

git reset --hard hash 基于hash前进后退
git reset --hard HEAD^ 只能后退 一个^后退一步
git reset --hard HEAD~n 只能后退 后退n步

git reset – soft mixed hard
–soft 仅在工作目录移动HEAD指针
–mixed 在工作目录移动HEAD指针 重置暂存区
–hard 在工作目录移动HEAD指针 重置暂存区和工作区
git reset --hard 之后如果有commit,那么可以找回原文件;如果直接push到了一个unprotected的远程分支,那么就直接将之前的commit全部覆盖掉

git diff file 将工作目录和暂存区文件进行比较
git diff HEAD/hash 将工作目录和工作区进行比较
git diff --stat 统计diff的状态

git branch -v 查看分支信息
git branch branch_name 创建分支
git checkout branch_name 切换分支
git merge branch_name 合并分支 在此之前需要先切换到目标分支 然后进行合并,有冲突的话需要手动merge

git remote -v 查看远程仓库
git remote add origin https://xxx.com 添加远程仓库 origin是别名 地址是https格式
git remote add origin_ssh git@ssh 添加远程仓库 地址是ssh格式

git fetch origin master 抓取远程内容 但是不merge(参数是远程地址别名和远程分支名)
git checkout origin/master 切换到拉取的远程库

git pull = git fetch + git merge 拉取远程库并合并


踩坑总结

1. fatal: unable to access ‘https://XXXX’: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

	git config --global http.sslVerify false

<think> 我们正在解决一个Git问题:当仅修改文件名字的大小写时,Git无法识别文件改名(即diff无法正确显示重命名)。这是因为Git默认对文件名大小写不敏感(尤其是在不区分大小写的文件系统上,如Windows和macOS的默认配置)。 根据用户提供的引用内容,虽然直接相关的引用可能没有,但我们可以结合Git知识和引用中的部分思路来解决。 引用[1]提到,当文件Git视为二进制时,可以通过设置.gitattributes来指定文件为文本文件。这给我们的启示是:我们可以通过配置Git来解决某些文件识别问题。 引用[3]提到文件权限修改导致Git误判,这提醒我们Git的配置可能会影响其行为。 引用[4]展示了git diff的用法,说明我们可以通过指定commit和文件路径来比较。 但我们的问题更具体:仅修改文件名的大小写,Git无法识别重命名。 解决方案通常有以下几种: 1. 配置Git使其对文件名大小写敏感: 在Git中,默认情况下,重命名仅当文件内容改变时才被检测到(即使大小写改变,内容相同也会被视为重命名)。但是,如果仅仅是大小写改变,在不区分大小写的文件系统上,Git可能不会记录为改名(因为文件系统认为大小写不敏感,所以Git可能看不到变化)。我们可以通过配置来让Git更关注大小写: - 设置 `git config core.ignorecase false`:这会让Git在内部记录文件名时区分大小写。但是,如果你的文件系统不区分大小写,这个设置可能导致一些问题(例如,文件系统无法同时存在仅大小写不同的文件)。所以通常不推荐直接设置这个。 2. 使用`git mv`命令进行重命名: 在重命名文件时,使用`git mv`命令而不是操作系统的重命名,这样Git可以更好地跟踪。 例如,将`file.txt`重命名为`File.txt`: ``` git mv file.txt File.txt ``` 然后提交。 3. 如果已经发生了仅大小写修改的重命名,而Git没有识别,我们可以分两步解决: - 先重命名为一个临时文件名(与原文件名大小写都不同) - 再重命名为目标文件名(仅大小写不同) 例如: ``` git mv file.txt temp.txt git mv temp.txt File.txt git commit -m "Rename file.txt to File.txt" ``` 4. 使用`git diff`的选项来强制检测重命名: 当我们查看diff时,可以使用`--diff-filter=R`来查看重命名,或者使用`-M`(或`--find-renames`)选项来设置重命名检测的阈值。 例如: ``` git diff --summary -M100% HEAD~1 HEAD ``` 这里`-M100%`表示只有文件内容100%相同时才被视为重命名(因为仅大小写改变,内容相同)。 5. 如果项目在Windows或macOS(不区分大小写)上,而远程仓库(Linux)区分大小写,则需要在本地执行重命名后,确保推送到远程仓库。 注意:在跨平台协作时,大小写问题可能导致混乱,因此建议团队统一命名规范(如全小写)以避免问题。 参考步骤: 假设我们有一个文件`oldname.txt`,我们想将其重命名为`NewName.txt`(仅大小写变化),但Git没有检测到: 方法一(推荐): - 使用`git mv`命令: ``` git mv oldname.txt NewName.txt git commit -m "Rename oldname.txt to NewName.txt" ``` 方法二(如果已经用操作系统重命名了,Git没有检测到): - 先用Git删除旧文件名,再添加新文件名: ``` git rm oldname.txt git add NewName.txt git commit -m "Rename oldname.txt to NewName.txt" ``` 注意:这种方法会丢失文件的重命名历史(因为Git会认为删除了一个文件并添加了一个新文件)。为了避免丢失历史,我们可以使用`git log --follow NewName.txt`来查看包括重命名前的历史。 方法三(使用两步重命名): - 如果直接重命名大小写无法被Git识别,可以分两步: ``` git mv oldname.txt tempname git mv tempname NewName.txt git commit -m "Rename oldname.txt to NewName.txt" ``` 另外,如果项目中有多个文件需要重命名大小写,可以考虑使用脚本辅助。 总结:最可靠的方式是使用`git mv`命令来重命名,并且确保在提交后推送到远程仓库。如果已经出现问题,可以用两步重命名法。 引用[1]中提到的.gitattributes方法主要解决文件被误判为二进制的问题,与大小写重命名无关。引用[3]和[4]也没有直接解决这个问题,但我们可以根据Git的操作技巧来解决。 注意:在某些操作系统上,即使使用`git mv`也可能不会立即在文件系统上反映出来(因为文件系统不区分大小写),但Git仓库内部会记录这个重命名。 如果团队中有不同的操作系统,可能需要每个人配置Git为大小写敏感(但不推荐,因为文件系统不区分大小写可能会导致错误)。所以,最好的做法是使用`git mv`并确保提交重命名。 如果问题已经存在(即已经提交了一次大小写重命名,但Git没有记录为重命名),那么可以尝试使用`git mv`再重命名一次(通过临时名称过渡),然后提交。 为了验证重命名是否被正确记录,可以使用: ``` git log --name-status --follow -- NewName.txt ``` 查看文件的历史和重命名记录。 如果上述方法都不能解决,可能需要考虑文件系统的限制,并建议在区分大小写的文件系统(如Linux)上进行重命名操作。 最后,建议在团队中统一文件名的大小写规则,避免频繁重命名带来的麻烦。 </think> ### Git 文件仅修改大小写时 diff 无法识别的解决方案 当 Git 无法识别仅修改文件名大小写的重命名时(例如 `file.txt` → `File.txt`),这是因为 **Git 默认不区分文件名大小写**,尤其在不区分大小写的文件系统(如 Windows/macOS APFS)中。以下是系统性的解决方案: --- #### ✅ 解决方案 1:强制 Git 识别大小写重命名(推荐) ```bash # 步骤 1:删除旧文件名(保留工作区文件git rm --cached oldname.txt # 步骤 2:添加新文件名(仅大小写变化) git add NewName.txt # 步骤 3:提交更改 git commit -m "Rename oldname.txt to NewName.txt (case change)" ``` **原理**:通过先删除旧缓存再添加新文件,强制 Git 将其识别为重命名操作而非新增文件[^1]。 --- #### ✅ 解决方案 2:配置 Git 大小写敏感模式 ```bash # 启用大小写敏感检测 git config core.ignorecase false # 再执行重命名操作 git mv oldname.txt NewName.txt ``` **注意**:此配置需团队统一,否则可能引发跨平台协作问题[^2]。 --- #### ✅ 解决方案 3:分步重命名(绕过文件系统限制) ```bash # 先将文件改为临时名 git mv oldname.txt tempname # 再改为目标大小写名称 git mv tempname NewName.txt # 提交更改 git commit -m "Case-sensitive rename via temp file" ``` **适用场景**:当直接重命名失败时,通过临时文件绕过文件系统限制[^3]。 --- #### ⚠️ 根本原因分析 1. **文件系统限制**:Windows/macOS 默认不区分文件名大小写。 2. **Git 缓存机制**:Git 依赖文件哈希而非文件名跟踪变更,相同内容的文件仅大小写变化被视为无修改。 3. **重命名检测逻辑**:Git 的 `diff` 需内容变化或显式重命名命令才能识别[^1][^4]。 --- #### 📌 最佳实践建议 1. **统一团队规范**:在 `.gitattributes` 中声明需区分大小写的文件类型: ```bash # .gitattributes *.txt diff *.js diff ``` 2. **验证操作**:执行后检查历史记录: ```bash git log --name-status --follow -- NewName.txt ``` 3. **跨平台协作**:建议在 Linux 环境执行大小写重命名操作。 > **关键提示**:若已错误提交,可用 `git mv --force oldname.txt NewName.txt` 强制覆盖,但可能需清理历史缓存[^1][^3]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值