最基本的git操作无非包括git add、git commit、git checkout、git pull、git push，但是除此之外工作中还会应用到很多其他的git操作，我这里列举了一些最近工作中使用到的一些git功能，分享给大家！

1 git remote update

当你使用Git进行版本控制时，你可能会和其他人一起协作开发一个项目。在这种情况下，你需要与远程仓库保持同步，确保你能获取到其他团队成员所做的更改。每次开始创建分支或者计划提交之前，最好使用git remote update来更新一下远端的分支信息到本地，以防止未更新而基于旧的版本进行开发，避免完成工作之后merge冲突等问题。

2 git stash

git stash 是一个非常有用的命令，它帮助你在处理一些临时的工作或者当你需要切换到另一个任务时，能够暂时“隐藏”你当前的工作进度。想象一下，你正在写一篇文章，突然接到一个紧急电话，需要立刻去处理别的事情。这时候，你不想丢失已经写下的内容，但又不得不马上离开。Git stash 就像是快速保存你的工作草稿，等你回来后可以继续从你停下的地方开始。

创建一个stash：

当你有一些未提交的改动，并且想暂时把这些改动放到一边，你可以使用 git stash save <message> 命令。这里的 <message> 是可选的，用来描述这次stash的内容。如果不加任何消息，默认也会创建一个stash。

 git stash save "暂时保存未完成的功能"

查看stash列表：

你可以使用 git stash list 查看所有已有的stash列表，每个stash都有一个编号和描述信息。

 git stash list

应用stash：

如果你想把某个stash应用回你的工作目录，可以使用 git stash apply <stash>。如果你只写了 git stash apply，默认会应用最近的一次stash。

 git stash apply

或者如果你想在应用的同时删除stash（类似于“一次性使用”），可以使用 git stash pop。

 git stash pop

清理stash：

如果你不再需要某些stash了，可以使用 git stash drop <stash> 来删除特定的stash。如果你想清除所有的stash，可以使用 git stash clear。

 git stash clear

3 .gitignore和.gitkeep

    当你在使用Git管理项目的时候，经常会遇到一些文件或目录，你不希望它们被纳入版本控制系统中。比如编译生成的二进制文件、日志文件、临时文件或者是包含敏感信息的配置文件等等。这些文件通常不需要被版本控制，因为它们要么是自动生成的，要么包含私密数据，不适合公开共享。

.gitignore 文件

.gitignore 文件就像是一个清单，告诉Git哪些文件和目录不需要被跟踪。它可以帮你过滤掉那些不需要提交到仓库的文件，让仓库保持整洁，并保护隐私。

创建 .gitignore 文件

假设你在项目根目录下创建一个名为 .gitignore 的文件，这个文件的名字前缀必须是一个点（.），表示这是一个隐藏文件。在这个文件里，每行写一个模式，Git会根据这些模式来决定忽略哪些文件或目录。

示例

假设你有一个Python项目，你可能不想将虚拟环境目录和一些日志文件加入版本控制。你可以在项目的根目录下创建一个 .gitignore 文件，并添加以下内容：

 # 忽略Python虚拟环境

 venv/

 # 忽略日志文件

 *.log

 # 忽略Thumbs.db文件（Windows系统）

 Thumbs.db

上面的.gitignore文件告诉Git忽略所有位于venv/目录下的文件和子目录，忽略所有扩展名为.log的文件，以及忽略名为Thumbs.db的文件。

使用 .gitignore 文件

当你创建了一个新的.gitignore文件或修改了现有的文件后，Git会自动应用新的规则。但是，如果某个已经被跟踪的文件现在被加入了.gitignore文件，Git不会自动删除该文件的历史记录。你可以选择使用git rm --cached <file>命令来取消对文件的跟踪，但保留文件在本地磁盘上。

.gitkeep 文件

有时候，你会有一些空的目录需要被Git跟踪，以便于保持项目结构清晰。但是Git默认不会跟踪空目录。为了告诉Git跟踪这些空目录，你可以在空目录内创建一个名为.gitkeep的文件。

创建 .gitkeep 文件

创建一个空文件，命名为.gitkeep，然后把它放在你希望Git跟踪的空目录内。这个文件的作用就是让Git知道这个目录不是真的空，而是有意留空的。

示例

假设你有一个名为data的目录，它目前是空的，但是你希望Git能够跟踪这个目录的存在。你可以在data目录内创建一个.gitkeep文件：

 mkdir data

 touch data/.gitkeep

这样，Git就会把这个空的data目录也纳入版本控制，保证项目结构的完整性。

4 git patch

git patch 不是一个直接的Git命令，这里指的是使用Git来生成补丁文件（patch files），这些文件包含了对代码库的更改。补丁文件是一种文本文件，它们包含了文件差异（diffs），可以用来在另一个副本中重现这些更改。

什么是补丁文件？

补丁文件是一个文本文件，它记录了两个文件或两个目录之间的一系列差异。这些差异包括添加、删除或修改的行。补丁文件可以应用于另一个相同或相似的文件或目录，从而将这些差异应用上去，达到“修补”的效果。

Git生成补丁文件的方法

在Git中，你可以使用几种不同的命令来生成补丁文件。最常用的是git diff 和 git format-patch 命令。

使用 git diff

git diff 命令可以显示两个版本之间的差异，这些差异可以被重定向到一个文件中，成为补丁文件。例如，如果你想要生成当前工作目录与最后一次提交之间的差异作为补丁文件，你可以这样做：

 git diff > mypatch.patch

这会生成一个名为 mypatch.patch 的文件，里面包含了当前工作目录与最后一次提交之间的差异。

使用 git format-patch

git format-patch 命令则更加高级，它不仅可以生成补丁文件，还可以将补丁文件格式化为邮件格式，方便通过电子邮件发送给项目维护者或其他贡献者。

生成单个补丁文件

如果你想要为当前分支上的最后一次提交生成一个补丁文件，可以使用如下命令：

 git format-patch HEAD~1

这将会在当前目录下生成一个补丁文件，文件名通常是 0001-<commit_message>.patch 格式。

生成一系列补丁文件

如果你想要为一系列提交生成多个补丁文件，可以使用下面的命令：

 git format-patch <start-commit>..<end-commit>

例如，如果你想要为HEAD~5到HEAD之间的所有提交生成补丁文件，可以这样写：

 git format-patch HEAD~5..HEAD

这将在当前目录下生成一系列按顺序编号的补丁文件。

应用补丁文件

一旦你有了补丁文件，你可以使用 git apply 命令来应用这些补丁。例如，如果你有一个名为 mypatch.patch 的补丁文件，你可以这样应用它：

 git apply mypatch.patch

5 git squash

git squash 是一种在Git中合并多个提交成一个单一提交的技术。想象一下，你在做一项复杂的任务时，可能会产生很多中间的提交，比如修复一个小bug、添加一些测试代码、调整样式等。这些提交虽然一步一步地推动了项目的进展，但它们单独看起来可能显得杂乱无章。使用git squash，你可以把这些相关的提交合并成一个干净、简洁的提交记录，使得你的提交历史更加清晰易读。

为什么使用 git squash？

1. 整理提交历史：有时候，你可能做了很多小的修改，这些修改最终构成了一个大的功能。通过git squash，你可以把这些修改合并成一个逻辑上完整的提交，使得其他人查看你的提交历史时更加容易理解。

2. 保持历史简洁：当你在进行开发时，可能会有一些实验性的提交或者一些临时的调试代码。这些提交并不需要保留在最终的提交历史中，git squash 可以帮助你清理这些杂乱的部分。

3. 便于代码审查：在团队协作中，提交历史的整洁程度直接影响到代码审查的效率。通过git squash，你可以减少审查者的负担，让他们更容易集中注意力在重要的变更上。

如何使用 git squash

git本身没有一个直接叫做git squash的命令，而是通过git rebase来实现git squash的效果。下面是一个简单的步骤来演示如何使用git rebase来进行git squash：

1. 确保你在正确的分支上：首先，确保你处于你想要合并提交的那个分支上。

2.  git checkout my-feature-branch

3. 列出你想要合并的提交：使用git log或者git reflog查看你想要合并的提交。

4. 开始交互式重新基线（rebase）：使用git rebase -i命令进入交互式重新基线模式，这里HEAD~n表示你想要合并的提交之前的提交，n是你想要保留的第一个提交。

5.  git rebase -i HEAD~5

6. 这会打开一个文本编辑器（通常是vim），显示一个列表，列出了你最近五次提交的SHA哈希值和提交信息。

7. 选择要合并的提交：在编辑器中，你会看到每一行都以pick开头，后面跟着一个提交的SHA哈希值和提交信息。对于你想要合并的提交，把pick改成squash或squash!，简称s。

8. 比如：

9.  pick 7a61e01 添加功能A

10.  pick 1b40f0d 修复功能A中的bug

11.  pick 3a9c5f2 调整功能A的样式

12.  pick 4d65220 添加功能B

13. 改成：

14.  pick 7a61e01 添加功能A

15.  squash 1b40f0d 修复功能A中的bug

16.  squash 3a9c5f2 调整功能A的样式

17.  pick 4d65220 添加功能B

18. 编辑合并后的提交信息：当Git看到你选择了squash选项时，它会提示你编辑一个新的提交信息。这个信息将代表你合并后的所有提交。你可以在这里输入一个新的提交信息，或者编辑合并的提交信息。

19.  # 编辑合并后的提交信息

20. 完成重新基线：保存并关闭编辑器后，Git会执行合并，并将你带回到命令行。此时，你已经成功地将多个提交合并成了一个。

21. 推送更改：由于你改变了提交历史，所以需要推送分支到远程仓库时需要加上--force参数。但是这通常是不建议的行为，git squash最好只用来处理本地分支，squash完毕之后再push到远端。

22.  git push --force

    通过这样的步骤，你可以将一系列的小提交合并成一个逻辑上连贯的大提交，使得你的Git提交历史更加整洁有序。这对于保持良好的项目文档和提高团队协作效率是非常有帮助的。

6 git submodule status

git submodule status 是一个用于检查Git子模块状态的命令。子模块允许你在Git仓库中嵌入另一个Git仓库，就像在一个大项目中包含一个独立的库或组件一样。子模块可以有自己的提交历史和版本控制，但它们被整合到主项目的版本控制流程中。使用git submodule status可以帮助你了解这些子模块的当前状态，确保它们与你期望的状态一致。

什么是Git子模块？

在开发过程中，你可能会用到一些外部库或工具，这些库或工具本身就是独立的Git项目。例如，你可能在构建一个Web应用时，需要用到一个第三方的JavaScript库。在这种情况下，你可以将这个库作为一个子模块添加到你的主项目中，这样你的项目就包含了这个库的所有源码和历史记录。

为什么要使用 git submodule status？

当你在一个项目中有多个子模块时，了解这些子模块的状态是非常重要的。这包括知道它们是否已经初始化，是否有未提交的更改，是否与远程仓库同步等。git submodule status 命令提供了这些信息，帮助你更好地管理子模块。git仓库中保存了主仓库和子仓库的对应关系，这些关系往往是非常重要的，不同仓库的版本必须严格对应，使用git submodule status 命令可以快速得知当前主仓库的提交对应哪些子仓库的提交。

如何使用 git submodule status

使用git submodule status命令，你可以查看所有子模块的状态。命令非常简单：

 git submodule status

执行这个命令后，你将看到一个列表，每个子模块对应一行，每一行包含以下信息：

1. SHA-1 哈希值：这是子模块当前指向的提交的哈希值。

2. 子模块路径：这是子模块在你的项目中的位置。

3. 状态标志

4. ：这一列会显示子模块的状态。如果一切正常，通常会看到一个空格。如果有变化，则会显示相应的状态标志，例如：

• +：表示子模块的本地版本比其记录的版本超前。

• -：表示子模块的本地版本落后于其记录的版本。

• D：表示子模块的本地版本与记录的版本有分歧。

• A：表示子模块已被添加但尚未初始化。

• I：表示子模块已初始化。

• R：表示子模块的URL已被更改。

示例

假设你有一个项目，其中包含了一个名为third-party-library的子模块。你可以这样查看它的状态：

 $ git submodule status

 166d2f8b3e83893f9d150c19d6f02b279e490639 third-party-library (HEAD detached at v1.2.3) +

这表明子模块third-party-library当前指向的提交是166d2f8b3e83893f9d150c19d6f02b279e490639，并且本地版本比记录的版本超前（因为有+标志）。

7 git blame

git blame 是一个非常有用的命令，它帮助你追踪某一行代码是谁在什么时候修改的。想象一下，你正在阅读一个复杂的代码文件，突然发现了一个问题，可能是某个功能不再工作了，或者某个变量的值看起来不对劲。这时候，你可能会想知道：“这一行代码是谁写的？是什么时候改的？为什么这么改？” git blame 就是用来回答这些问题的。

什么是 git blame？

git blame 命令显示了每一个文件行的最后修改者及其修改的时间戳和提交信息。这就像给每一行代码打上了标签，告诉你这行代码是由谁在哪个提交中引入或修改的。

为什么使用 git blame？

1. 查找修改者：当你发现一个问题时，可以通过git blame找到最后修改那行代码的人，从而更容易地定位问题的原因。

2. 了解历史：通过查看某一行代码的修改历史，你可以了解为什么代码被这样编写，这对理解代码逻辑和意图非常有帮助。

3. 代码审查：在团队协作中，git blame 可以帮助审查代码的变更，确保代码质量。

如何使用 git blame

使用git blame非常简单，基本语法如下：

 git blame [options] <file>

• [options]：你可以添加一些选项来定制输出，比如限制显示的行数或显示完整提交信息。

• <file>：这是你要查看的文件名。

基本用法

如果你想查看某个文件的每一行最后被谁修改，可以直接运行：

 git blame <file>

例如，如果你有一个名为app.js的文件，你可以这样查看：

 git blame app.js

输出结果会显示每一行代码对应的提交信息，包括提交者的姓名、日期和提交的摘要信息。

示例输出

假设你运行了git blame app.js，输出可能是这样的：

 9e15a148 (Alice Smith 2024-01-01 10:30:00 +0800) 1: function greet() {

 9e15a148 (Alice Smith 2024-01-01 10:30:00 +0800) 2: console.log('Hello!');

 c6f3b47a (Bob Lee 2024-01-02 14:15:00 +0800) 3: // Added a comment for clarity.

 9e15a148 (Alice Smith 2024-01-01 10:30:00 +0800) 4: }

每一行的输出包含以下信息：

• SHA-1哈希值（如9e15a148）：这是最后一次修改该行的提交的唯一标识符。

• 提交者的姓名（如Alice Smith）。

• 提交的日期和时间（如2024-01-01 10:30:00 +0800）。

• 提交信息摘要（如function greet()）。

• 行号（如1:）。

• 实际的代码行内容。

更多选项

git blame 还支持许多选项来定制输出，例如：

如果你想查看app.js文件第5行到第10行的修改历史，可以这样运行：

 1git blame -L 5,10 app.js

实际场景中的应用

假设你在开发一个Web应用，突然发现用户登录功能出现了问题。你不确定是什么时候引入的这个问题，也不知道是谁修改了这部分代码。你可以使用git blame来追踪：

1. 找到出现问题的文件，比如login.js。

2. 运行 git blame login.js 查看每一行的修改记录。

3. 发现第15行的代码有问题，然后看到这条记录是由Bob在两天前的提交中修改的。

4. 通过这种方式，你可以快速定位问题的来源，并联系Bob询问他当时的修改原因，从而更快地解决问题。

8 git status | grep ...

想象一下，在一个大型工程中，一次编译会产生非常多的产物，这些产物可能都会影响到了仓库状态，而如果我们只想关注哪些源文件发生了变化，这个时候应该怎么办呢？

我们可以通过git status + grep命令来解决这个问题。

 git status --short | grep '\.(c|h)$'

• git status --short：输出一个简洁的格式，每行包含一个状态代码和文件名。

• grep '\.(c|h)$'：筛选出以.c或.h结尾的文件。

结语

在日常的开发工作中，Git是我们不可或缺的好帮手，它帮助我们管理代码的版本、协同工作并追踪每一次的改动。从确保与远程仓库同步的git remote update，到临时保存工作进度的git stash；从避免不必要的文件被纳入版本控制的.gitignore和.gitkeep，到生成补丁文件以便审查和应用的git patch；从整理提交历史、使代码审查更加清晰的git squash，到管理子模块状态的git submodule status；再到追踪代码修改源头的git blame，以及快速筛选特定文件改动的git status | grep组合——这些技巧都是Git强大功能的一部分。本文介绍了几个在实际工作中非常实用的Git技巧，希望能让你的开发体验更加高效和顺畅。

原文来源：https://mp.weixin.qq.com/s/VhmCENaL7BjhaL-MG01x1A