介绍

本周，我加深了对 Git 的理解，特别是使用 Git 遥控器。作为先决条件，在处理远程时熟悉 Git 合并至关重要。上周，我分享了我第一次使用 Git merge 的经验并讨论了一些最佳实践。本周，我在开发新功能时应用了这些知识，不是在我自己的存储库中，而是在合作者的存储库（我朋友 Mayank 的）中。同时，他在我的存储库中开发了一项功能，使我们能够使用 Git 练习远程协作。

新功能：支持TOML配置

目前，我过去几周开发的工具使用温度和模型等选项的默认值集，当用户不提供特定参数时应用这些值。此新功能的目标是通过添加对从用户主目录中的 TOML 文件读取配置设置的支持来扩展该工具的功能。

例如，如果用户在 C:\User\Anh\config.toml 中有一个配置文件，该工具现在将检查用户主目录中是否存在 .toml 文件。如果存在此类文件，该工具将读取该文件并应用其值来设置默认配置，从而覆盖内置默认值。但是，用户仍然可以提供命令行参数，该参数将优先于 TOML 文件值。

执行

为了实现这个功能，我利用了toml包来解析TOML配置文件的内容：

import * as toml from 'toml';

由于该工具将在用户的主目录中搜索 .toml 文件，因此我使用 Node.js 的内置 os 模块来检索主目录路径：

const os = require("os");
const homeDir = os.homedir();

从用户的主目录收集所有文件后，我迭代它们以查找以 .toml 结尾的隐藏文件（以点 . 开头的文件）。找到的第一个 .toml 文件被用作该工具的配置源。

笔记

• 该工具将在主目录中查找隐藏的“点文件”（例如 .config.toml），其中包含 TOML 格式的默认选项。
• 如果文件丢失，该工具将忽略此文件并继续使用 config.js 文件中的默认设置。
• 如果文件存在但不是有效的 TOML，该工具将退出并显示相应的错误消息。
• 如果 TOML 文件存在并且没有命令行参数覆盖其值，则将使用 TOML 文件中的设置（例如默认模型）。
• 该工具将忽略 TOML 文件中任何无法识别的选项，以确保向后兼容性。

远程协作流程

如前所述，本周涉及练习 Git 远程工作流程以及 Git 与 Mayank 合并。为了开发他的存储库中的功能，我按照以下步骤操作：

1. 分叉和克隆：我分叉了他的存储库并将其克隆到我的本地计算机。
2. 创建分支：我在本地副本中创建了一个新分支并开始研究新功能。
3. 提交和推送：进行更改后，我将它们提交到分支并将分支推送到我的分叉存储库。

 git push origin 

一旦 Mayank 将他的更改推送到新分支并请求拉取请求 (PR)，我想在合并之前测试他的代码。这就是 git Remote 变得至关重要的地方：

• 添加远程：我将他的存储库作为远程添加到我的本地计算机：

  git remote add  

• 获取提交：我从他的存储库中获取了最新的提交和分支：

git fetch 

• 跟踪分支：我创建了一个跟踪分支来跟踪他的更新，而不直接影响我的存储库：

git checkout -b  /

错误识别和解决

在测试过程中，我发现了 Mayank 分支中的两个关键问题：

• 目录配置错误：该工具错误地从项目根目录而不是用户的主目录读取 TOML 文件。
• 路径解析：代码使用相对文件路径，当我在我的机器上运行它时导致错误。我建议切换到绝对路径

// Resolve the path to the configuration file
const configPath = path.resolve(__dirname, "../.toml");

// Load configuration from config.toml
const config = loadConfig(configPath);

确定这些问题后，我通过 Slack 与 Mayank 进行了讨论，并合作寻找解决方案。我还直接就他的拉取请求提供了反馈。这个过程让我感觉自己正在为一个现实世界的协作项目做出贡献。一旦我对修复感到满意，我将他的分支合并到主分支并将其推送到我的远程存储库。

结论

使用 Git 远程和合并的过程非常具有教育意义。我现在对在共享代码库上进行协作更有信心了。以前，我经常会因不同开发人员的多次提交和贡献而感到不知所措，但现在我对 Git 工作流程有了更好的控制和理解。

通过研究此功能并集成 Git 遥控器，我获得了实践经验，这对于未来的项目来说是非常宝贵的。