当前位置：首页 > news >正文

Git 操作与技巧

news 来源：原创 2025/5/12 23:43:47

一、开发日常常用 Git 操作与技巧

1.1 基础操作

1.1.1 查看 Git 状态

git status：查看当前工作区的状态，了解哪些文件已经修改、哪些文件已经暂存。
```
git status
```
这个命令是最常用的命令之一，可以帮助你理解当前的开发状态，哪些文件已经被修改、哪些已经添加到暂存区、哪些是新创建的文件。

1.1.2 查看提交历史

git log：查看提交历史。
```
git log --oneline
```
用 --oneline 可以让输出更简洁，只显示提交 ID 和提交信息。你还可以添加更多参数来过滤和美化日志：
- git log --graph：以图形化的方式显示分支结构。
- git log --stat：显示每个提交修改的文件和行数。

1.1.3 跳转到指定版本

git checkout <commit>：可以通过 commit ID 跳转到某个版本。
```
git checkout <commit>
```
或者切换到某个分支：
```
git checkout <branch-name>
```
如果你想恢复到某个历史版本进行修复或查看，可以使用这个命令。注意，如果你只是查看某个提交而不打算修改，可以创建一个“分离头指针”状态（detached HEAD），确保不会丢失后续的工作。

1.1.4 还原文件

git checkout -- <file>：恢复某个文件的修改，回到上次提交的版本。
```
git checkout -- <file>
```
这个命令会将文件从工作区还原到暂存区最后一次提交时的状态，常用来撤销工作区的修改。
git reset <file>：撤销暂存区的修改，使文件回到工作区，但不会删除文件的内容。
```
git reset <file>
```

1.2 分支与合并操作

1.2.1 创建和切换分支

git checkout -b <branch-name>：创建并切换到一个新分支。
```
git checkout -b feature/new-feature
```
用这个命令可以一次性创建一个新分支并切换过去。
git switch <branch-name>：切换到指定的分支。相比 git checkout，git switch 命令更加直观，专门用于分支切换。
```
git switch feature/new-feature
```

1.2.2 合并分支

git merge <branch>：将指定的分支合并到当前分支。
```
git merge feature/new-feature
```
合并时，Git 会尝试自动合并文件。如果有冲突，Git 会标记出冲突部分，开发者需要手动解决冲突。

1.2.3 解决合并冲突

冲突标记：合并冲突发生时，Git 会在冲突的文件中插入冲突标记：
```
<<<<<<< HEAD
当前分支的内容
=======
合并分支的内容
>>>>>>> feature/new-feature
```
你需要手动编辑文件，决定如何合并这些内容，删除标记后再提交。
git add <file>：解决冲突后，使用 git add 把文件添加到暂存区。
```
git add <file>
```

1.2.4 删除分支

git branch -d <branch-name>：删除本地分支。只有在该分支已经合并到当前分支时，才允许删除。
```
git branch -d feature/new-feature
```
git branch -D <branch-name>：强制删除本地分支，即使该分支尚未合并。
```
git branch -D feature/new-feature
```

1.2.5 合并分支时保持干净历史（Rebase）

git rebase <branch>：将当前分支的提交“移动”到目标分支的顶端，保持提交历史的线性。
```
git rebase master
```
rebase 操作会修改历史提交的基础（变基），因此在多人协作时要小心，尤其是在公共分支上进行 rebase 操作时。

1.3 高级命令与技巧

1.3.1 恢复丢失的提交（使用 reflog）

git reflog：查看 Git 的所有操作历史，包括分支切换、提交、合并等，即使这些操作没有保留在当前分支历史中。
```
git reflog
```
如果你丢失了某些提交或者误删除了分支，可以通过 reflog 找回历史状态。

1.3.2 变基多个提交（交互式 rebase）

git rebase -i <commit>：交互式变基，可以修改历史提交，包括重新排序、合并提交、修改提交信息等。
```
git rebase -i HEAD~3
```
这将允许你对最近的三个提交进行编辑。在交互式编辑模式下，你可以选择 pick、reword、edit、squash 等操作。

1.3.3 挑选特定提交（`cherry-pick`）

git cherry-pick <commit>：从其他分支选择特定的提交应用到当前分支。这对于将某个 bug 修复引入到多个分支非常有用。
```
git cherry-pick <commit>
```

1.3.4 更新远程仓库

git push：推送本地分支到远程仓库，更新远程分支。
```
git push origin feature/new-feature
```
git push -f：强制推送。git push -f 强制将本地分支推送到远程仓库，覆盖远程的内容。通常用于 rebase 后，需要强制更新远程分支的情况。但使用时要小心，因为它会覆盖远程分支的历史。
git pull：拉取远程仓库的更新并合并到当前分支。
```
git pull origin master
```

1.4 常见开发场景与解决方案

1.4.1 你已提交错误的文件

撤销最后一次提交（不删除文件）：
```
git reset --soft HEAD~1
```
这会将最后一次提交撤销，但不会删除文件，只是将文件从暂存区移回工作区。
删除最后一次提交及其修改：
```
git reset --hard HEAD~1
```
这会彻底删除最后一次提交及其修改，恢复到上一个提交状态。

1.4.2 合并后撤销更改

撤销合并并恢复到合并前的状态：
```
git merge --abort
```
如果合并时遇到问题并希望撤销合并，可以使用这个命令。

1.4.3 确保提交规范

使用 Git 钩子（如 pre-commit）来确保每次提交符合代码规范、格式或测试要求。可以集成 eslint、prettier、jest 等工具，自动执行代码格式化和测试，避免提交错误的代码。

二、常见 Git 工作流

2.1 GitHub Flow

从 main 分支创建一个新的功能分支。
在功能分支上进行开发并提交。
提交完成后，创建 Pull Request（PR）进行代码审查。
审查通过后将功能分支合并回 main。
直接部署到生产环境。

2.2 GitFlow

创建 develop 分支，作为主要的开发分支。
每个新特性在 feature 分支上开发。
功能完成后，合并回 develop。
当准备发布时

，从 develop 创建 release 分支，并进行最终修复。
5. 发布后，release 分支合并回 main 和 develop。
6. 紧急修复时创建 hotfix 分支。

继续深入一些开发中常用的 Git 操作技巧 和 常见问题的解决方法，帮助你应对更多的开发场景。

三、Git 进阶技巧与解决方案

3.1 `git stash`：临时保存工作进度

在你进行开发时，可能会遇到需要暂时切换分支或处理中断的情况，而不希望把当前工作状态提交到版本库。此时 git stash 非常有用，它可以将你的当前工作区（工作区和暂存区的内容）暂存起来，恢复到干净的状态，待你完成其他任务后再恢复。

3.1.1 使用 `git stash` 保存进度

git stash：保存当前工作进度并将工作区恢复到上次提交的状态。
```
git stash
```
git stash save "message"：保存当前进度，并为这次保存添加描述信息。
```
git stash save "WIP: Fix issue with login"
```
git stash list：查看所有的暂存记录。
```
git stash list
```

3.1.2 恢复暂存的进度

git stash apply：恢复最近的一次暂存记录，但不删除该记录。
```
git stash apply
```
git stash pop：恢复最近的一次暂存记录，并删除该记录。
```
git stash pop
```
git stash drop：删除指定的暂存记录。
```
git stash drop stash@{0}
```

3.1.3 删除所有暂存记录

git stash clear：删除所有的暂存记录。
```
git stash clear
```

3.2 `git cherry-pick`：挑选提交

git cherry-pick 是一个非常实用的命令，可以从其他分支挑选特定的提交并将其应用到当前分支。这在处理 bug 修复或将某些功能迁移到不同分支时非常有用。

3.2.1 使用 `git cherry-pick` 选择提交

git cherry-pick <commit-id>：将指定的提交应用到当前分支。
```
git cherry-pick a1b2c3d4
```
如果发生冲突，Git 会提示你解决冲突，解决后运行 git add 并使用 git cherry-pick --continue 完成合并。

3.2.2 合并多个提交

git cherry-pick <commit-id1> <commit-id2>：挑选多个提交。
```
git cherry-pick a1b2c3d4 e5f6g7h8
```

四、Git 远程仓库的高级操作

4.1 远程仓库操作

4.1.1 查看远程仓库

git remote -v：查看远程仓库的 URL。
```
git remote -v
```

4.1.2 添加远程仓库

git remote add <name> <url>：将一个远程仓库添加到本地。
```
git remote add origin https://github.com/username/repo.git
```

4.1.3 拉取远程更新

git pull：拉取并合并远程分支的最新更改到当前分支。
```
git pull origin master
```
git fetch：仅拉取远程仓库的更新，不合并。可以先检查更新的内容，再决定是否合并。
```
git fetch origin
```

4.1.4 推送本地更改

git push：将本地分支推送到远程仓库。
```
git push origin feature/awesome-feature
```

4.1.5 强制推送（慎用）

git push -f：强制推送，将本地分支的更改覆盖远程分支。这对于推送修改历史（如 rebase 后的提交）时很有用，但要小心，这可能会导致丢失其他人的提交。
```
git push -f origin feature/awesome-feature
```
git push --force-with-lease：推荐使用 --force-with-lease，它会在推送时确保本地分支没有被其他人更新过，避免强制推送覆盖其他人的更改。
```
git push --force-with-lease origin feature/awesome-feature
```

五、处理常见开发问题

5.1 工作区修改丢失

有时你可能会不小心丢失了工作区的修改，例如忘记执行 git add 或 git commit，此时你可以尝试以下方法：

5.1.1 查看本地文件修改

git diff：查看工作区和暂存区的差异，帮助你找回丢失的修改。
```
git diff
```

5.1.2 使用 `git reflog` 恢复丢失的提交

git reflog 记录了所有的操作历史，包括那些已经被 reset 或 rebase 的提交。如果你不小心丢失了某些提交，可以使用 reflog 恢复它们。

git reflog：查看所有 Git 操作的历史。
```
git reflog
```
找到你丢失的提交并使用 git checkout 恢复：
```
git checkout <commit-id>
```

5.1.3 恢复删除的文件

如果你在不小心删除了文件的情况下提交了更改，可以使用以下命令恢复文件：

git checkout -- <file>：恢复文件到上次提交时的状态。
```
git checkout -- path/to/file
```

5.2 在多人协作中解决冲突

冲突是多人协作时不可避免的，尤其是在并行开发的情况下。以下是处理冲突的一些技巧：

5.2.1 处理冲突

git status：检查哪些文件有冲突。
```
git status
```

编辑冲突文件：打开冲突文件，手动解决冲突，删除冲突标记。

<<<<<<< HEAD
当前分支的内容
=======
合并分支的内容
>>>>>>> feature/xyz

git add：解决冲突后，使用 git add 将解决后的文件添加到暂存区。
```
git add path/to/conflict-file
```
git commit：完成冲突解决后，进行提交。
```
git commit
```

5.2.2 避免不必要的冲突

拉取最新的代码：在开始新工作之前，始终确保你拉取了远程仓库的最新更改，并且解决了所有冲突。
```
git pull origin master
```
分支粒度：在开发过程中保持分支粒度较小，避免在同一个分支上长时间进行大量修改。这样可以减少冲突发生的概率。

六、Git 的最佳实践

6.1 提交信息规范

良好的提交信息可以帮助团队成员更好地理解变更的内容。以下是提交信息的一些最佳实践：

简洁明了：提交标题应该简洁，通常不超过 50 个字符，说明这次提交的目的和变更。
动词开头：提交信息通常以动词开头，如 “Fix bug”， “Add feature”。
详尽描述：如果需要更多描述，可以在提交信息正文部分进行详细说明。
避免杂乱无章的提交：避免提交与当前任务无关的更改。

6.2 代码审查与合并请求（PR）

代码审查是一项重要的团队协作工作，帮助确保代码质量。合并请求（PR）应包含以下内容：

描述变更：PR 应详细描述其变更内容、目的以及如何测试。
审查清单：确保在提交 PR 前，已经检查了代码格式、功能性测试、性能等方面。
避免一次性提交大量更改：PR 应尽量保持小而清晰，避免一次性提交大量更改，这样更容易进行代码审查。

继续深入探讨更多的 Git 实用操作技巧和常见开发问题的解决方案，帮助你更好地应对实际开发中的各种挑战。

七、Git 高级操作

7.1 `git bisect`：二分查找 bug

git bisect 是一个非常强大的工具，可以帮助你通过二分查找的方式，快速定位引入 bug 的提交。它通过反复“切分”提交历史，帮助你在大量提交中找到具体导致问题的那个提交。

7.1.1 使用 `git bisect` 查找 bug

开始 bisect：

启动 git bisect，告诉 Git 你已经确定某个提交是坏的（有 bug）和某个提交是好的（没有 bug）。

git bisect start
git bisect bad  # 表示当前提交是坏的
git bisect good <commit-id>  # 表示某个已知良好的提交

执行 bisect 查找：
- Git 会根据你提供的好坏提交，在提交历史中切分，检查一个中间的提交。
- 在每次测试之后，告诉 Git 该提交是好是坏：
```
git bisect good  # 如果当前提交没有 bug
git bisect bad  # 如果当前提交有 bug
```
结束 bisect：
- 当 Git 找到引入 bug 的提交时，会停止 bisect。你可以查看结果，并使用 git bisect reset 恢复到之前的状态。
```
git bisect reset
```

7.1.2 `git bisect` 的工作原理

git bisect 基于二分查找的算法，每次会缩小搜索范围，快速找到引入 bug 的具体提交。这个过程对于调试历史代码中的 bug 极其高效，特别是在提交量较大的项目中。

7.2 `git rebase` vs `git merge`：如何选择

git rebase 和 git merge 都可以用来将一个分支的更改集成到另一个分支，但它们有不同的行为和适用场景。

7.2.1 `git merge` 的特点

保留提交历史：git merge 会生成一个合并提交，保留原有的提交历史。
适合多人协作：当多个开发者在不同分支上并行工作时，使用 git merge 更加安全，可以保留每个人的独立提交历史。

7.2.2 `git rebase` 的特点

历史更加简洁：git rebase 会将当前分支的提交“重新应用”到目标分支的最新提交上，产生更简洁、线性的提交历史。
适用于个人开发：git rebase 适合在个人分支上使用，它有助于保持一个清晰、干净的提交历史。但如果在多人协作的项目中，特别是公共分支，使用 git rebase 可能会导致历史冲突或丢失提交，因此需要小心使用。

7.2.3 选择哪种操作

当你想要保持历史分支清晰、干净时，可以选择 git rebase。例如，更新自己的功能分支，使其与 main 分支同步。
当你想保留历史的所有分支信息，确保每个人的开发过程都能被追溯时，可以使用 git merge。

7.3 `git tag`：为特定提交打标签

在开发过程中，标记一个重要的提交，如发布版本、发布里程碑等，是一个常见需求。git tag 命令允许你为特定提交打上标签，便于版本控制和回溯。

7.3.1 创建标签

轻量标签：简单的标签，不包含额外信息。
```
git tag v1.0
```
附注标签：包含作者信息、时间和标签说明等详细信息。
```
git tag -a v1.0 -m "Release version 1.0"
```

7.3.2 查看标签

查看所有标签：
```
git tag
```
查看特定标签的提交信息：
```
git show v1.0
```

7.3.3 推送标签到远程仓库

推送单个标签：
```
git push origin v1.0
```
推送所有标签：
```
git push --tags
```

7.3.4 删除标签

删除本地标签：
```
git tag -d v1.0
```
删除远程标签：
```
git push --delete origin v1.0
```

八、Git 与 CI/CD 集成

在现代开发中，Git 是持续集成（CI）和持续交付（CD）流程的重要组成部分。理解如何将 Git 与 CI/CD 工具集成，可以提升团队开发效率和代码质量。

8.1 自动化部署：与 CI/CD 集成

GitHub Actions：使用 GitHub 提供的自动化工作流服务，可以在每次推送到 Git 仓库时触发构建、测试、部署等操作。
Jenkins、GitLab CI/CD、CircleCI 等工具：这些工具可以与 Git 仓库集成，在每次提交时自动构建、测试和部署应用程序。它们通常会拉取最新的 Git 提交，执行构建和测试，然后自动部署到预生产或生产环境。

8.2 配置 Git 钩子实现自动化任务

Git 提供了一些钩子（hooks），你可以在提交、推送等操作时自动触发某些任务（例如代码格式化、运行单元测试等）。

常用的 Git 钩子文件在 .git/hooks/ 目录下，包括：

pre-commit：在每次提交之前运行，可以用来进行代码格式化、静态检查等。
post-commit：在提交完成后运行，可以用来发送通知、更新问题追踪系统等。
pre-push：在推送前执行，可以用于检查是否通过了所有的单元测试。

例如，使用 pre-commit 钩子在每次提交时自动运行 eslint：

安装 pre-commit 工具：
```
pip install pre-commit
```

创建一个 .pre-commit-config.yaml 文件：

-   repo: https://github.com/prettier/prettierrev: v2.3.2hooks:-   id: prettierfiles: \.js$

安装钩子：
```
pre-commit install
```
每次提交时，pre-commit 会自动运行指定的工具来检查代码。

九、常见 Git 问题及解决方法

9.1 恢复丢失的文件

如果不小心丢失了工作区的文件，可以使用以下方法恢复：

恢复已删除的文件：使用 git checkout 恢复已删除的文件。
```
git checkout -- <file>
```
从历史版本恢复文件：如果文件已经被提交，可以从历史中恢复。
```
git checkout <commit-id> -- <file>
```

9.2 解决文件冲突

冲突是多人开发时经常遇到的问题，Git 会在文件冲突时标记出冲突部分。解决冲突时，按照以下步骤操作：

查看冲突文件：使用 git status 查看哪些文件有冲突。
```
git status
```

编辑冲突文件：手动解决冲突，删除 Git 插入的标记。

<<<<<<< HEAD
当前分支的内容
=======
合并分支的内容
>>>>>>> feature/xyz

添加解决后的文件：解决冲突后，使用 git add 将文件添加到暂存区。
```
git add <file>
```
完成提交：
```
git commit
```

9.3 解决推送失败

有时你可能会遇到推送失败的情况，特别是在团队协作时。如果推送失败，通常是因为远程分支比本地分支更新，导致了冲突。

拉取远程分支的更新：
```
git pull origin master
```
解决冲突并提交：如果拉取时发生冲突，解决冲

突后再进行提交。

重新推送：
```
git push origin master
```

十、总结

掌握 Git 的各种操作技巧，可以大大提高你的开发效率，避免许多常见的开发问题。在日常开发中，合理使用分支管理、提交规范、以及与 CI/CD 集成，能够确保代码质量和团队协作的顺畅。同时，了解和熟练使用一些 Git 的高级操作，如 git bisect、git rebase 和标签管理，也能帮助你更好地管理项目和调试 bug。

通过不断实践和积累经验，你将能在 Git 的世界中游刃有余，更高效地完成开发任务。