git的冷知识

git branch

css 复制代码

# 初始化的时候默认没有名字的分支
# gitte提交(默认分支为master)只有你执行了git push origin master之后才会与本地产生联系，本地分支被命名为master分支
# github提交(默认分支为main)
git branch -M main # 将未命名的分支重命名为main分支，与远程默认的origin/main匹配

# 单纯的想改分支名
git branch -M main-back # 当前分支为main-front，执行此git指令，分支改名为main-back

git push

less 复制代码

# main默认的远程分支是main
# git push 远程仓库别名 本地分支名:远程分支名
git push origin main # 效果相当与git push origin main:main

git log

bash 复制代码

# git log 打印的默认是打印当前本地分支对应的远程分支的提交历史
git log # 假设当前是main分支,等价于查看origin/main分支的提交信息,即git log origin/main

# git log 查看指定分支的提交历史
git log upstream/main
# 如果想要查看所有分支的提交历史
git config --global alias.tree 'log --all --graph --decorate --oneline'
git tree # 可以展示所有本地分支和远程跟踪分支的提交历史

git fetch

bash 复制代码

# git fetch 会把默认的origin仓库的最新代码拉到本地，但是不会与本地代码合并
# 同时git fetch也可以指定仓库,指定拉取的分支
git fetch upstream main # 将upstream远程仓库中的main分支拉取到本地，并且不会产生合并

git diff

bash 复制代码

# git的diff算法，将本地的记录和远程分支的代码作比较
# 按 Space 键向下翻页，按 b 键回退一页，按 q 键退出分页器
git diff main origin/main # 输出为空则没有差异

git merge

css 复制代码

# 快合并,不会产生新的合并历史
git merge origin/main # 假设当前为main分支，把远程的main分支合并到当前分支(--ff) 
# 慢合并,会产生新的提交历史
git merge origin/main --no-ff # 执行后会进入vim模式,书写commmit信息,需要重新提交到origin/main

git pull

css 复制代码

git pull origin main 
==> git fetch origin main && git merge origin/main --ff # 快合并

# 一般合并的较好解决方式
git fetch origin main
# 查看本地main和远程main的差异
git diff main origin/main
# 选择合并的方式 --ff,--no-ff
git merge origin/main [options...]
# 再手动解决冲突
vim filename
# 重新提交
git add . && git commit -m "合并冲突" && git push

--no-ff和--ff的区别

明显--no-ff更加适合commit的回退，使用--ff需要手动回退多次，因为--no-ff生成一个合并的commit提交，

git revert -m $position$ 可以选择保留哪边

git rebase

css 复制代码

# 类似git merge只是使提交历史更加线性
git fetch origin main
git diff main origin/main
git rebase origin/main

git rebase 前

git rebase 后

可以发现通过rebase本质改变的使origin/main的位置，origin/main在本地分支下游，就算修改了origin/main的位置也能保证提交历史的线性

git merge和git rebase的取舍

git merge 适合于希望保持历史完整性和追踪合并事件的场景。

git rebase 更倾向于维护简洁、线性的提交历史，尤其是在个人工作流或准备提交前的整理阶段。

git merge中--ff和--no-ff的取舍

--ff（fast-forward）追求简洁，直接移动指针，适用于内部开发或无合并冲突的简单情况。

--no-ff强制创建合并提交，明晰历史分界，更适合团队协作和需要明确追踪合并历史的场景。

git revert

python 复制代码

# 撤销到某一次commit之前，并生成一次新的commit提交(记录回退操作)
git revert <commit-id> # 不是合并提交
# 合并提交
git show <commit-id> # 查看合并的两个分支的位置,第一个对应position为1,第二个对应position为2
git revert -m <position> <commit-id> # positions

# 最后需要重新提交回退信息
git push

普通提交的撤销

回退到"windows新增4.txt之前",此时当前分支文件只有1.txt,2.txt,3.txt

合并分支的撤销

此时1.txt内容回退到commit(操作系统windows.上的1.txt提交)后的内容
git revert <commit> 允许你创建一个新的提交来撤销那个引入问题的提交中的所有更改，而不会影响其他提交。这样既修复了问题，又保持了提交历史的清晰和完整，展现了问题是如何被解决的，这对于团队协作和后期的代码审查、问题追踪非常有帮助。

git reset

scss 复制代码

# 回退到指定版本
git reset [--soft | --mixed | --hard] [HEAD]

# --mixed(默认)
git reset --mixed [HEAD] # 不会暂存到本地,需要手动add和commit

# --soft
git reset --soft [HEAD] # 会暂存到本地,不需要手动add和commit

# --hard(危险操作)
git reset --soft [HEAD] # 会暂存到本地,清空HEAD之后的所有commit记录

--mixed

--soft

--hard

与--soft区别就是暂存区的文件也会回退,4.txt已经访问不到了

git reflog(备份神器)

perl 复制代码

# 假如你执行了以下命令
git reset <commit-id> --hard && git push -f

# git reflog可以查看本地的head变化的历史
# 只要 HEAD 发生变化，就可以通过 reflog 查看到
git reset <commit-id> --soft && git push -f # 就能回退到之前强制推送前远程仓库的状态
# 一般这个commit-id使第二个(HEAD{1}),因为在上面指令reset时HEAD指向改变了，所以是第二个
# HEAD{n},n代表偏移量