🍎常用的Git命令指南🍎

🍇 代码提交流程

仓库克隆

git clone [url] ：克隆一个远程仓库到本地。

如果你希望将远程仓库克隆到一个特定的目录中，可以在命令中指定目标目录，例如：

git clone [url] [target_directory]

在这个命令中，[target_directory] 是你希望将远程仓库克隆到的本地目录的路径。

例如，要将名为 example_repo 的远程仓库克隆到当前目录下的一个名为 my_project 的目录中，你可以运行以下命令：

git clone https://example.com/example_repo.git my_project

这将把远程仓库的代码克隆到 my_project 目录中，并在其中初始化一个新的 Git 仓库。

查看当前 Git 仓库状态

git status：查看工作区和暂存区的状态。

当你运行 git status 命令时，Git 会显示当前工作目录中的文件状态，包括哪些文件已被修改但尚未添加到暂存区，哪些文件已经添加到暂存区但尚未提交，以及是否有未跟踪的文件等信息。

通常，git status 的输出会告诉你：

• 已修改但未暂存的文件列表。
• 已暂存但尚未提交的文件列表。
• 未跟踪的文件列表。
• 当前所在的分支以及与远程分支的关系（如果已设置追踪）。

这个命令通常是你在进行提交前的一个必要步骤，以确保你要提交的文件状态符合你的预期。

例如，如果你运行 git status 并看到有修改但未暂存的文件，你可能会使用 git add 命令将这些文件添加到暂存区，然后再运行 git status 来确保所有要提交的文件都已暂存。

git status

这将显示当前 Git 仓库的状态信息。

将文件添加到暂存区

git add [file] ：将文件添加到暂存区。

git add [file] 是将文件或目录添加到 Git 暂存区的命令。

在这个命令中，[file] 可以是单个文件的路径，也可以是一个包含多个文件的目录路径。通过运行 git add [file] 命令，你可以将指定的文件或目录中的所有文件添加到 Git 的暂存区中，使其成为下一次提交的一部分。

如果你有多个文件需要添加到暂存区，可以使用 git add 命令多次，或者使用通配符 * 来添加某个目录中的所有文件。

例如，如果你想要将名为 example.txt 的文件添加到暂存区，你可以运行以下命令：

git add example.txt

如果你想要将某个目录中的所有文件添加到暂存区，你可以运行以下命令：

git add path/to/directory/

或者，如果你想要添加当前目录下的所有文件到暂存区，你可以运行以下命令：

git add .

这将把当前目录下的所有文件都添加到暂存区中。

提交暂存区的文件到本地仓库

git commit -m "[message]" ：提交暂存区的文件到本地仓库，并附上一条提交信息。

git commit 命令用于将暂存区中的文件提交到本地仓库，并创建一个新的提交（或称为提交记录）。

当你运行 git commit 命令时，Git 会打开一个文本编辑器（通常是配置的默认编辑器，如 Vim 或 Nano），供你输入提交信息。提交信息包括了对此次提交的简要描述，以及可选的详细说明。

如果你希望在提交时直接添加提交信息，可以使用 -m 参数，并在后面跟上提交信息的内容。例如：

git commit -m "Add new feature"

这将会直接提交暂存区中的所有修改，并使用 "Add new feature" 作为提交信息。

拉取最新代码

git pull：从远程仓库拉取最新代码并合并到本地仓库。

git pull 命令用于从远程仓库（通常是一个共享的代码仓库，如 GitHub、GitLab 等）拉取最新的更改，并将其合并到你当前所在的本地分支。

在执行 git pull 命令时，Git 会执行两个操作：首先，它会从远程仓库拉取最新的提交（使用 git fetch 命令），然后它会尝试将远程分支中的更改合并到你当前所在的本地分支中。

一般来说，git pull 命令等价于执行两个命令的组合：git fetch 和 git merge。但是，如果你在配置中设置了相应的选项，也可以通过 rebase 重新应用本地提交。

如果你是在执行 git pull 命令时遇到了冲突，Git 会停止合并过程，并让你解决冲突。解决完冲突后，你需要执行 git add 将解决后的文件标记为已解决，然后再运行 git commit 来完成合并。

在执行 git pull 命令之前，建议确保你当前的工作目录是干净的（没有未提交的更改），以避免可能出现的合并冲突或其他问题。

保存临时存储区域

git stash: 命令用于将当前工作目录中的未提交的修改（包括暂存区和工作区的修改）保存到一个临时的存储区域中，从而让你能够在不提交这些修改的情况下切换到其他分支或进行其他操作。

这个命令主要有两种应用的场景：

1、当你在进行一些工作时，突然需要切换到其他分支或者处理一些紧急情况时，但又不想提交当前的工作目录中的修改，你可以使用 git stash 命令将这些修改暂时存储起来，以后再恢复。

2、在当前分支进行代码提交时，最好先进行git pull命令进行拉去当前分支的最新代码，但是由于当前分支里面有修改内容，可能会导致拉取不成功，这样我们就可以通过使用 git stash 命令将这些修改暂时存储起来，git pull拉取最新代码后，再通过git stash pop 或者 git stash apply恢复，这样我们就不用再执行git pull命令。

使用 git stash 命令会将修改保存到一个栈中，你可以多次使用 git stash 命令来保存不同的修改，每个保存的修改都会形成一个栈顶的新条目。

一旦你需要恢复之前保存的修改，你可以使用 git stash pop 命令来从栈顶取出最近保存的修改，并将其应用到当前工作目录中。如果你想应用其他位置的存储，可以使用 git stash apply 命令并指定相应的存储索引。

除了 git stash pop 和 git stash apply，你还可以使用 git stash list 命令来查看当前存储区域中的所有存储，以及使用 git stash drop 命令来删除某个特定的存储。

命令使用

如果你学会 stash，就不用那么狼狈了。你只需要：

git stash

就这么简单，代码就被存起来了。

当你修复完线上问题，切回 feature 分支，想恢复代码也只需要：

git stash apply

相关命令

# 保存当前未commit的代码
git stash
​
# 保存当前未commit的代码并添加备注
git stash save "备注的内容"
​
# 列出stash的所有记录
git stash list
​
# 删除stash的所有记录
git stash clear
​
# 应用最近一次的stash
git stash apply
​
# 应用最近一次的stash，随后删除该记录
git stash pop
​
# 删除最近的一次stash
git stash drop

当有多条 stash，可以指定操作stash，首先使用stash list 列出所有记录：

$ git stash list
stash@{0}: WIP on ...
stash@{1}: WIP on ...
stash@{2}: On ...

应用第二条记录：

$ git stash apply stash@{1}

代码提交

git push：将本地提交推送到远程仓库。

git push 命令用于将本地的提交推送到远程仓库。在执行 git push 命令之前，你通常需要先将本地的提交通过 git commit 命令保存到本地仓库中。

一般情况下，你需要指定远程仓库的名称和分支名称，格式为 git push <remote> <branch>。例如，如果你想将本地的 main 分支推送到名为 origin 的远程仓库，则可以执行：

git push origin main

如果你已经在本地的分支上设置了追踪（tracking），则可以简化为：

git push

Git 会根据当前分支的追踪设置自动确定要推送到哪个远程仓库以及哪个分支。这意味着，如果你当前在 main 分支上，并且已经设置了与 origin/main 分支的追踪关系，那么 git push 命令会将本地的 main 分支推送到 origin 远程仓库的 main 分支。

值得注意的是，如果远程仓库的分支包含了你本地仓库没有的提交，那么 git push 命令会被拒绝，因为这会导致远程仓库的历史被修改。在这种情况下，你需要先通过 git pull 命令来拉取远程仓库的更新，然后再尝试推送。

总结

以下是我比较常用的在当前分支中提交代码的流程：

git stash
git pull
git stash apply
git add .
git commit -m '修改信息'
git push

🍊 分支相关

新建分支

git branch [branch_name] ：创建一个新的分支。

使用 git branch 命令创建一个新分支。假设你想要创建一个名为 new-feature 的新分支，你可以执行以下命令：

git branch new-feature

这将在当前的提交位置创建一个名为 new-feature 的新分支，但你仍然停留在当前分支上。

分支信息

git branch：列出本地分支。

git branch 命令用于列出所有的本地分支，并显示当前所在的分支。如果你执行 git branch 而不带任何参数，它将列出所有本地分支，并在当前所在的分支前面标记一个星号 *。

示例输出可能如下所示：

  main
* feature-branch
  development

在这个示例中，有三个本地分支：main、feature-branch 和 development。当前所在的分支是 feature-branch，因为它前面有一个星号 *。

如果你想查看远程分支，可以添加 -r 或 --remotes 选项：

git branch -r

这会列出所有的远程分支。

你也可以使用 -a 或 --all 选项来列出所有的本地和远程分支：

git branch -a

这会同时列出本地分支和远程分支。

切换分支

git checkout [branch_name] ：切换到指定分支。

git checkout [branch_name] 命令用于切换到指定的分支。假设你想要切换到名为 branch_name 的分支，你可以执行以下命令：

git checkout branch_name

这将会将你的工作目录和索引切换到指定的分支上，允许你在该分支上进行工作。

新建并切换分支

git checkout -b [branch_name] :用于创建一个新的分支并立即切换到该分支。

git checkout -b [branch_name] 命令用于创建一个新的分支并立即切换到该分支。如果你执行这个命令，Git 将会创建一个名为 branch_name 的新分支，并将你的工作目录和索引切换到这个新分支上。

示例用法如下：

git checkout -b new-feature

这个命令将创建一个名为 new-feature 的新分支，并立即切换到这个分支上。你可以在新分支上进行你的工作，而不会影响到其他分支。

这是一个快捷的方法，相当于执行了以下两个步骤：

1. git branch new-feature：创建一个名为 new-feature 的新分支。
2. git checkout new-feature：切换到新创建的 new-feature 分支上。

使用这个命令可以让你更加高效地创建并切换到新分支上进行工作。

切换历史分支

git checkout <commit_hash> :用于将工作目录切换到指定提交的状态

<commit_hash>可以通过git log查看.

git checkout <commit_hash> 命令用于将工作目录切换到指定提交的状态，你可以查看该提交的内容，但是处于分离 HEAD 状态，不属于任何分支。这通常用于查看历史提交或者进行一些临时性的操作。

使用 git checkout <commit_hash> 命令后，你可以浏览提交的内容，进行修改，甚至创建新的分支来基于该提交进行进一步的开发。然而，请注意，在分离 HEAD 状态下进行的修改不会反映到任何分支上，所以如果你在此状态下进行了更改并且希望保留，需要创建一个新的分支来保存这些更改。

🍓 代码回退

查看提交历史记录

git log：查看提交历史记录。

git log 命令用于显示项目的提交日志。它列出了当前分支的所有提交记录，并按时间顺序显示，最近的提交记录排在最前面。

默认情况下，git log 会以较为简洁的格式显示提交信息，包括每个提交的哈希值、作者、提交日期和提交信息。

示例输出可能如下所示：

commit e63fba19c55c52d96e86b0e0a2fc24e97f7b31c5
Author: John Doe <johndoe@example.com>
Date:   Mon Apr 18 15:25:43 2024 -0700
​
    Added new feature X
​
commit 42e51f9a1b9a6b76f1d09b57995b2c22e3c7b5f8
Author: Jane Smith <janesmith@example.com>
Date:   Sat Apr 16 10:12:35 2024 -0700
​
    Fixed issue #123

在这个示例中，每个提交记录由一个 commit 开始，后面跟着一串由字母和数字组成的哈希值，用来唯一标识该提交。然后是作者、提交日期和提交信息。

除了默认格式外，git log 还支持许多选项和参数，可以用来自定义输出的格式、筛选提交记录等。例如，你可以使用 --graph 选项以图形化的方式显示提交记录的分支和合并情况，或者使用 --author 参数来只显示特定作者的提交记录。

重置当前分支的状态

git reset：将文件从暂存区撤回到工作区。

git reset 命令在 Git 中用于移动 HEAD 指针和重置当前分支的状态。

它有几种不同的用法，主要有三种模式：(可以通过git log查看)

1. Soft 模式（--soft）： 在这种模式下，git reset 会将 HEAD 移动到指定的提交，但不会更改暂存区和工作目录的内容。这意味着之后你可以重新提交先前提交的更改。

   git reset --soft <commit>

2. Mixed 模式（默认，--mixed）： 这是默认的模式。在这种模式下，git reset 会将 HEAD 移动到指定的提交，并将暂存区重置为该提交，但不会更改工作目录的内容。这意味着之后你需要重新暂存你想要包含在下一次提交中的更改。

   git reset <commit>

3. Hard 模式（--hard）： 在这种模式下，git reset 会将 HEAD 移动到指定的提交，并且重置暂存区和工作目录，使它们与指定提交完全一致。这意味着之后你将丢失未提交的所有更改。

   git reset --hard <commit>

除了 <commit> 参数，你还可以使用其他标识符来指定要移动到的提交，比如分支名或者 HEAD 的相对引用（比如 HEAD~2 表示往前移动两次提交）。

请注意，git reset 是一个非常强大的命令，可以改变你项目的历史状态，请谨慎使用。

撤销之前的提交的更改

git revert:用于创建一个新的提交，以撤销之前的提交的更改。

git revert 命令用于撤销先前的提交，但是与 git reset 命令不同，它不会修改提交历史。相反，它会创建一个新的提交，该提交会将指定提交引入的更改撤销掉。

基本语法如下：

git revert <commit>

其中 <commit> 是要撤销的提交的哈希值。

git revert 命令会创建一个新的提交，该提交会将指定提交引入的更改逐个逆向应用，从而撤销该提交的效果。这样做的好处是，它不会改变提交历史，因此适用于在团队协作或者公开仓库中避免修改历史的情况下使用。

举个例子，假设我们有一个提交历史如下：

A -- B -- C -- D  <-- HEAD

如果我们想要撤销提交 C 引入的更改，可以运行：

git revert C

这会创建一个新的提交 E，其中包含了撤销提交 C 引入的更改。此时的提交历史将变为：

A -- B -- C -- D -- E  <-- HEAD

提交 E 会引入与提交 C 相反的更改，从而实现撤销的效果。

需要注意的是，由于 git revert 创建了一个新的提交来撤销先前的更改，因此会产生额外的提交历史。这在某些情况下可能会导致提交历史变得混乱，因此在使用时要注意清晰地记录撤销的原因。

git reset与git revert区别

git reset 和 git revert 都是 Git 中用于撤销更改的命令，但它们的工作方式和影响是不同的。

git reset：

• 作用： 用于移动 HEAD 指针和重置当前分支的状态。
• 影响： 可以将当前分支的 HEAD 指向另一个提交，并且可以选择性地更改暂存区和工作目录的内容。
• 谨慎使用： git reset 是一个具有破坏性的命令，如果使用不当，可能会丢失提交历史。在使用时需要格外小心。

git revert：

• 作用： 用于创建一个新的提交，以撤销之前的提交的更改。
• 影响： 创建一个新的提交，该提交将取消之前提交引入的更改，而不会更改任何之前的提交历史。
• 安全性： git revert 是一种安全的撤销方式，因为它不会改变提交历史，而是创建一个新的提交来撤销之前的更改。

区别总结：

• 重置 vs. 撤销： git reset 用于重置当前分支的状态，而 git revert 用于撤销之前的提交。
• 影响范围： git reset 可能会影响当前分支的历史记录，而 git revert 则不会改变历史记录。
• 安全性： git revert 更安全，因为它不会修改历史记录，而 git reset 则可能会导致历史记录的改变。

选择使用哪个命令取决于你想要达到的效果以及对历史记录的影响程度。通常情况下，如果你需要撤销已经提交的更改，并且希望保留提交历史，那么 git revert 是更安全的选择。如果你需要彻底重置当前分支的状态，并且明确知道你正在做什么，那么 git reset 可能更合适。

🥭 代码合并

git merge

git merge:用于将一个分支的更改合并到另一个分支。

基本语法如下：

git merge <branch>

其中 <branch> 是你想要合并到当前分支的分支名称。

下面是一个简单的示例，假设你当前在 main 分支上，想要将 feature 分支的更改合并到 main 分支上：

git checkout main
git merge feature

这将会将 feature 分支上的更改合并到 main 分支上。如果有冲突需要解决，你需要解决冲突后再提交合并。

除了基本的合并之外，还有其他一些选项和用例：

1. 合并特定提交：你可以合并一个特定的提交而不是一个分支，只需提供提交的哈希值即可。

   git merge <commit>

2. 合并并忽略历史 ：有时你可能希望将另一个分支的更改合并到当前分支上，但不希望保留该分支的提交历史。你可以使用 --squash 选项来将所有更改合并成一个新的提交，而不保留分支的历史。

   git merge --squash <branch>

3. 合并并保持历史：如果你想要保留分支的提交历史，可以正常合并分支，然后提交合并。这样会保留分支的完整历史记录。

   git merge <branch>

git rebase

git rebase:将一个分支的提交移动到另一个分支上，并在此过程中重新应用这些提交。

基本语法如下：

git rebase <base>

其中 <base> 是你想要将当前分支移动到其上的目标分支。

下面是一个简单的示例，假设你当前在 feature 分支上，想要将 feature 分支的更改移动到 main 分支上：

git checkout feature
git rebase main

这将会将 feature 分支上的提交逐个移动到 main 分支上，并将其应用到 main 分支的顶部。如果有冲突需要解决，你需要解决冲突后继续 rebase 或者使用 --skip 或 --abort 选项来处理。

git rebase 的主要优点是可以保持线性的提交历史，因为它会将提交逐个应用到目标分支的顶部，而不像 git merge 那样创建一个新的合并提交。这样可以使提交历史更加清晰，并减少不必要的合并提交。

然而，需要注意的是，由于 git rebase 会改写提交历史，因此在团队协作或者公开仓库中使用时需要谨慎，避免对已经推送到远程仓库的提交进行 rebase 操作，以免造成混乱。

综上所述，git rebase 是一种用于合并分支的强大工具，特别适用于保持清晰的提交历史和线性的提交流程。

git rebase与git merge区别

git rebase 和 git merge 是 Git 中两种常见的合并分支的方法，它们各有优劣，适用于不同的场景。

git merge:

• 工作流简单 ：git merge 是一个简单直接的合并方法，它会创建一个新的合并提交来整合两个分支的更改。
• 保留分支历史：合并操作会保留每个分支的提交历史，使得整个提交历史更加清晰可见。
• 适用于公共仓库：由于合并操作不会改写提交历史，因此更适合在团队协作或公共仓库中使用。

git rebase:

• 线性提交历史 ：git rebase 可以将当前分支的提交移动到目标分支的顶部，使得提交历史变得更加线性，没有额外的合并提交。
• 清晰的提交历史 ：由于 git rebase 会将提交逐个应用到目标分支上，因此提交历史更加整洁清晰，不会有额外的合并提交。
• 修改提交历史 ：通过 git rebase 可以修改提交历史，包括重新排序、合并提交、修改提交消息等，有助于整理提交历史。
• 适用于个人分支 ：git rebase 更适合在个人分支上使用，可以使得提交历史更加整洁，并减少不必要的合并提交。

如何选择：

• 如果你想要保留分支的完整历史，并且希望在合并时创建一个明确的合并提交，则使用 git merge。
• 如果你想要保持提交历史的线性，并且希望提交历史更加整洁清晰，则使用 git rebase。
• 在团队协作或公共仓库中，通常更推荐使用 git merge，以避免对共享提交历史造成不必要的影响。
• 在个人分支上进行整理提交历史或者将自己的更改整合到主分支时，可以考虑使用 git rebase。

🍋 git cz

git cz 是一个用于生成规范化提交消息的命令行工具，它结合了 Commitizen 和 Commitlint 的功能，帮助开发者编写符合约定的提交消息。

通常，使用 git cz 的步骤如下：

1. 首先，确保你的项目中已经安装了 Commitizen 和相关的配置。
2. 在项目根目录下，使用 git cz 命令来替代直接使用 git commit。
3. 运行 git cz 后，你会看到一个交互式界面，引导你填写提交的各个部分，如提交类型、作用域、主题、描述等。
4. 根据提示逐步填写完整的提交消息，然后保存退出。
5. 提交消息将会被规范化并自动添加到 Git 提交记录中。

通过使用 git cz，可以确保团队成员提交的消息符合项目约定，使得提交历史更加清晰可读，方便维护和追溯。

如果你的项目还没有配置 Commitizen 和相关工具，可以通过 npm 或 yarn 来安装它们，然后进行相应的配置。

安装配置

要安装和使用 git cz，你需要进行以下步骤：

步骤一：安装 Commitizen 和适用于项目的适配器

1. 使用 npm 安装 Commitizen：

npm install -g commitizen

1. 选择适用于你项目的适配器。常用的适配器包括：

   • cz-conventional-changelog：符合 Conventional Commits 约定的适配器。
   • cz-customizable：可以根据项目需要定制的适配器。

你可以根据项目需求选择合适的适配器，并安装它们：

npm install -g cz-conventional-changelog
# 或者
npm install -g cz-customizable

步骤二：配置项目以使用 Commitizen

修改 package.json 文件，添加以下内容

{
  "config": {
    "path": "node_modules/cz-customizable"
  }
}

步骤三：使用 git cz 进行提交

1. 确保你已经暂存了你想要提交的所有更改。
2. 运行 git cz 命令来替代 git commit：

git cz

1. 然后，会出现一个交互式界面，引导你填写提交的各个部分，如提交类型、作用域、主题、描述等。
2. 根据提示逐步填写完整的提交消息，然后保存退出。
3. 提交消息将会被规范化并自动添加到 Git 提交记录中。

通过这种方式，你就可以使用 git cz 来规范化提交消息，使得提交历史更加清晰可读，方便团队合作和维护项目。