Git命令详解：实用技巧与常见问题解决

本文链接：https://blog.csdn.net/lzhcoder/article/details/52174695

常用命令

git clone <版本库的网址> <本地目录名></本地目录名></版本库的网址>
git log 查看看commit历史记录
git add & git commit 提交当前工作空间的修改内容到索引库中
git revert  version 还原一个版本的修改，必须提供一个具体的Git版本号 version
git tag version 可以将某个具体的版本打上一个标签这样你就不需要记忆复杂的版本号哈希值了
git branch 查看当前分支
git brance -a 查看所有分支
git branch test 新建了一个名字叫 test 的分支
git checkout -b test 这个命令的意思就是新建一个test分支，并且自动切换到test分支
git checkout test 切换到test分支
git branch -d   test 尝试安全地删除名为 test 的分支。如果 test 分支有未合并的更改，则此命令不会执行删除操作。
git branch -D  test 强制删除名为 test 的分支，即使它有未合并的更改。
git branch -r -d origin/test 删除本远程est分支。
git push origin test   把分支推到远程分支
git push --force origin 如果远程主机的版本比本地版本更新，推送时Git会报错，要求先在本地做git pull合并差异，然后再推送到远程主机。这时，如果你一定要推送，可以使用–force选项。上面命令使用–force选项，结果导致远程主机上更新的版本被覆盖。除非你很确定要这样做，否则应该尽量避免使用–force选项。
git fetch 相当于是从远程获取最新版本到本地，不会自动merge（更新所有远程分支索引）
git pull 相当于是从远程获取最新版本到本地，会自动merge
git stash 备份当前的工作区的内容，从最近的一次提交中读取相关内容，让工作区保证和上次提交的内容一致。同时，将当前的工作区内容保存到Git栈中。
git stash pop 从Git栈中读取最近一次保存的内容，恢复工作区的相关内容。由于可能存在多个Stash的内容，所以用栈来管理，pop会从最近的一个stash中读取内容并恢复。

实战技巧

一、提交的滚动文件超过100M导致无法提交

如果您已经将大文件添加到仓库并提交了更改，您需要从 Git 历史记录中删除它。这可以通过使用 git filter-branch 来完成。以下是使用 git filter-branch 的示例：

brew install git-filter-repo

git filter-repo 提示您这不是一个新克隆的仓库，因此默认情况下，它不会在当前仓库上执行破坏性操作。为了解决这个问题，您有两个选择：

1.在新克隆的仓库上运行命令：这是首选的解决方案，因为它更安全。首先，克隆您的仓库到一个新的文件夹：

git clone <repository_url> <new_folder>

将 <repository_url> 替换为您的仓库的 URL，将 <new_folder> 替换为新克隆仓库的目标文件夹。然后，进入新文件夹并再次运行 git filter-repo 命令：

cd <new_folder>
git filter-repo --invert-paths --path <file_name>

2.使用 --force 选项：如果您确定要在当前仓库上进行操作并愿意承担风险，请使用 --force 选项强制执行命令：

git filter-repo --invert-paths --path <file_name> --force

二、保持提交历史的线性关系

1.`git pull --rebase`

导致变基的含义是：在拉取远程分支的更新时，将本地的提交暂时移除，先将远程的更新应用到本地分支，然后再将暂时移除的本地提交重新应用到更新后的本地分支。这个过程就是变基（rebase）。

为了更好地理解变基的过程，我们可以举一个例子。假设我们有一个远程分支 `origin/main` 和一个本地分支 `main`，它们的提交历史如下：

origin/main: A -- B -- C main : A -- B -- D

这时，我们想要将远程分支的更新（即提交 C）合并到本地分支。如果我们直接使用 `git pull`（相当于 `git fetch` + `git merge`），会产生一个合并提交，提交历史变为：

main: A -- B -- D -- M \ / ----- C

这样的提交历史不够清晰，因为它包含了一个不必要的合并提交（M）。

而使用 `git pull --rebase`，Git 会先将本地分支的 D 提交暂时移除，然后将 C 提交应用到本地分支，最后再将 D 提交重新应用到更新后的本地分支。提交历史变为：

main: A -- B -- C -- D'

可以看到，现在的提交历史是线性的，没有合并提交，更加清晰。

总之，`git pull --rebase` 导致变基的意义就是在拉取远程分支的更新时，先将本地提交暂时移除，然后应用远程更新，最后再将本地提交重新应用到更新后的本地分支。这样可以避免不必要的合并提交，保持提交历史的线性关系。

`2.git rebase -i HEAD~2`

在实际项目中，我们可能会有一些提交不够规范，例如提交信息不清晰，或者多个提交实际上可以合并为一个。这时，我们可以使用 git rebase -i（交互式变基）来整理提交历史。

3.rebase 和 merge的区别

merge 是一个合并操作，会将两个分支的修改合并在一起，默认操作的情况下会提交合并中修改的内容
merge 的提交历史记录了实际发生过什么，关注点在真实的提交历史上面
rebase 并没有进行合并操作，只是提取了当前分支的修改，将其复制在了目标分支的最新提交后面
merge 与 rebase 都是很好的分支合并命令，没有好坏之分，使用哪一个应由团队的实际开发需求及场景决定