Use bundled OpenSSH

 

        安装 Git 时，您面临的选择是使用 Git 自带的 SSH 客户端（bundled OpenSSH）还是使用系统上已安装的外部 SSH 客户端（external OpenSSH）。以下是两个选项的一些考虑因素：

1. 使用 Git 自带的 OpenSSH（Use bundled OpenSSH）:

   • 这通常是最简单的选择，因为它保证了 SSH 客户端与 Git 版本的兼容性。
   • 如果您的系统上没有安装 SSH 或者您不确定如何配置 SSH，那么这个选项可能是最好的选择。

2. 使用系统上的外部 OpenSSH（Use external OpenSSH）:

   • 如果您已经在系统上安装并配置了 SSH 客户端，并且想要 Git 使用相同的 SSH 客户端，可以选择这个选项。
   • 这可能对于需要特定 SSH 客户端配置的高级用户来说是一个更好的选择。

        如果您不确定应该选择哪个，通常建议使用 Git 自带的 OpenSSH，因为它保证了最佳的兼容性并且可以简化安装过程。如果您选择了“使用系统上的外部 OpenSSH”并且系统上没有合适的 SSH 客户端，可能会导致在使用 Git 进行远程操作时出现问题。如果您是一个普通用户或者不熟悉 SSH 客户端的配置，那么建议选择“使用 Git 自带的 OpenSSH”。

Checkout Windows-style, commit Unix-style line endings

        这个界面是 Git 安装过程中配置文本文件的行尾转换的步骤。不同的操作系统使用不同的行尾字符，Linux 和 macOS 使用 LF（Line Feed），而 Windows 使用 CRLF（Carriage Return + Line Feed）。这三个选项的意义如下：

1. Checkout Windows-style, commit Unix-style line endings:

   • 这是在 Windows 上推荐的设置。它将在您检出文件时转换 LF 到 CRLF，确保 Windows 兼容性，并在提交时将 CRLF 转换回 LF，以保持仓库内的一致性。

2. Checkout as-is, commit Unix-style line endings:

   • 这个选项在检出文件时不会转换任何东西，但是在提交时会将任何 CRLF 转换为 LF。这是跨平台项目的推荐设置，并且在 Unix 系统上使用时比较常见。

3. Checkout as-is, commit as-is:

   • 这将完全避免任何自动转换，保留在检出或提交时文件的原始行尾。这不推荐用于跨平台项目，因为可能导致行尾不一致问题。

        在大多数情况下，如果您在 Windows 上工作并且与使用其他操作系统的开发者共享代码，那么选择第一个选项（Checkout Windows-style, commit Unix-style line endings）是最佳实践。这确保了您在本地环境中的文件与 Windows 兼容，同时保持了代码库中行尾的一致性，以便其他操作系统的用户也能使用。

Use MinTTY

        这个界面是 Git 安装过程中用于配置 Git Bash 使用的终端仿真器。您有两个选项：

1. Use MinTTY (the default terminal of MSYS2):

   • MinTTY 提供了一个更现代的界面，支持窗口大小调整、非矩形选择和 Unicode 字体，这些特性使得用户体验更好。它是 MSYS2 的默认终端，通常提供比 Windows 默认控制台更好的特性和更好的用户体验。

2. Use Windows' default console window:

   • 这会使 Git Bash 在 Windows 默认的控制台窗口（cmd.exe）中运行。这可能与其他基于 cmd 的工具更加一致，但它的功能较为基础，例如滚动回溯和文本选择限制，可能需要配置以正确显示非ASCII字符。

        通常，如果您不需要特定的 Windows 控制台行为，并且希望更现代的终端体验，建议选择 MinTTY。它为 Git Bash 提供了更加丰富的功能和更好的兼容性，尤其是在处理复杂脚本和文本显示时。

        如果您经常使用 Windows 命令提示符和其他依赖 cmd.exe 的工具，并且希望保持一致的体验，或者您需要确保最大的兼容性（特别是在企业或受限环境中），您可能会选择使用 Windows 默认的控制台窗口。

        对于大多数用户，我会建议使用 MinTTY 作为 Git Bash 的终端仿真器。

Fast-forward or merge

        这个界面询问您希望 git pull 命令的默认行为是什么。在 Git 中，git pull 是 git fetch 之后紧接着 git merge 的快捷方式，用来从远程仓库更新你的本地分支。以下是三个选项的解释：

1. Fast-forward or merge:

   • 这是最常见的选项，如果可能的话，它会执行快进（fast-forward），这意味着如果远程分支在当前分支之后，Git 会直接将您的头指针移动到远程分支的最新提交。如果不可能（例如，当你的分支有一些远程分支没有的提交时），Git 会执行一个合并提交。

2. Rebase:

   • 选择这个选项会使得 git pull 执行变基操作，即它会取出你在当前分支上做的提交，"取消"它们，拉取远程分支上的更新，然后再把你的更改"放回"到这些更新之上。这会使得项目历史更加整洁，因为它避免了不必要的合并提交。

3. Only ever fast-forward:

   • 此选项将配置 Git 仅在可以快进时执行 git pull。如果不能快进（比如远程分支与你的分支有分歧），那么 git pull 将会失败。这能保持历史线性，但可能需要手动解决分歧。

        选择哪个选项取决于您喜欢的工作流程：

• 如果您喜欢简单直接，不介意在历史中看到合并提交，那么选择 Fast-forward or merge。
• 如果您想要一个更清洁的项目历史，不介意在执行 git pull 之后解决可能出现的冲突，那么选择 Rebase。
• 如果您是在一个小团队中工作，或者在管理一个不太复杂的项目，并且想要保持历史的线性，那么选择 Only ever fast-forward。

        对于大多数用户，尤其是那些不太熟悉 Git 的人，Fast-forward or merge 是一个好的默认选择，因为它比较符合人们的直觉并且易于理解。如果您正在团队中工作，可能还需要考虑团队的工作流程约定。

Git Credential Manager

        在安装 Git 时，选择凭据帮助程序（credential helper）是一个重要的步骤，因为它可以帮助管理和存储用于与 Git 仓库交互的凭据（比如用户名和密码）。

1. Git Credential Manager:

   • 选择这个选项意味着您将使用 Git 凭据管理器来存储您的认证信息。这个跨平台的工具在您通过 HTTPS 访问 Git 仓库时，可以安全地保存您的登录信息，从而在下次访问时无需重新输入。这是一个方便的选择，特别是如果您经常需要与远程仓库交互。

2. None:

   • 如果您选择“None”，则意味着您不使用任何凭据帮助程序。这将要求您每次推送或拉取时都手动输入凭据，除非您有其他机制来管理它们。

        对于大多数用户来说，使用 Git Credential Manager 是一个方便的选择，因为它减少了每次访问远程仓库时需要输入凭据的次数。如果您对安全性有特别的要求，或者在一个自动化环境中（例如，持续集成/持续部署系统），那么您可能会选择不使用凭据帮助程序，并寻找其他的凭据管理解决方案。

        通常，对于个人开发者或小型团队，Git Credential Manager 是推荐的选项。如果您不确定，保持默认的选择通常是最佳的做法。

Enable file system caching

1. Enable file system caching:

   • 这个选项会启用文件系统缓存，它可以提高 Git 操作的性能，因为它会在内存中缓存文件系统数据。对于具有较大仓库或较慢硬盘的用户来说，这个选项可以显著提高性能。如果您的电脑配置较高，选择这个选项通常是有益的。

2. Enable symbolic links:

   • 符号链接是一个文件系统级别的快捷方式，指向另一个文件或目录。在 Git 中启用符号链接意味着您可以在仓库中创建指向其他文件或目录的链接。这在某些开发工作流程中很有用，但它需要特定的权限（SeCreateSymbolicLink），并且可能在不支持它们的平台上（如某些 Windows 版本）引发问题。如果您不确定您的系统支持符号链接或您不需要此功能，您可以不选它。

        如果您不熟悉符号链接或不确定是否需要它们，您可以不启用该选项。对于大多数用户，特别是那些使用标准开发和版本控制流程的用户，启用文件系统缓存通常是个好主意，而符号链接的使用则取决于您对它们的需求。如果您不需要符号链接或不确定它们的用途，可以安全地跳过这个选项。

Disable

1. Enable experimental support for pseudo consoles:

   • 这个选项允许在 Git Bash 窗口中运行像 Node 或 Python 这样的原生控制台程序，而不需要使用 winpty。这是一个实验性功能，可能还不够稳定。如果你需要在 Git Bash 中运行这类程序，并且愿意尝试可能还在开发中的功能，你可以选择启用它。但是，如果你希望确保你的环境尽可能稳定，你可能会想要跳过这个选项。

2. Enable experimental built-in file system monitor:

   • 这个选项会启用一个内置的文件系统监视器，旨在加快如 git status、git add 和 git commit 等常见操作，特别是在包含许多文件的工作树中。这对于那些处理大型仓库的用户来说可能非常有用，因为它可以显著提高这些操作的速度。然而，作为一个实验性功能，它可能包含未知的错误或不稳定性。

        实验性功能的一个重要考虑因素是它们可能未经充分测试，可能会有不预期的行为。如果你在一个生产环境中工作，或者你需要一个稳定和可预测的设置，你可能会想要避免启用这些选项。相反，如果你愿意尝试最新功能，并且可以容忍潜在的不稳定性，那么启用它们可能会为你带来一些好处。

        根据你的需求和对稳定性的偏好，你可以选择启用或不启用这些选项。如果你不确定，保守的做法是不启用实验性功能，确保你的 Git 安装尽可能稳定。