介绍
本周，我加深了对 git 的理解，特别是使用 git 遥控器。作为先决条件，在处理远程时熟悉 git 合并至关重要。上周，我分享了我第一次使用 git merge 的经验并讨论了一些最佳实践。本周，我在开发新功能时应用了这些知识，不是在我自己的存储库中，而是在合作者的存储库（我朋友 mayank 的）中。同时，他还在我的存储库中开发了一项功能，使我们能够使用 git 练习远程协作。
新功能：支持toml配置
目前，我在过去几周开发的工具使用温度和模型等选项的默认值集，当用户不提供特定参数时应用这些值。此新功能的目标是通过添加对从用户主目录中的 toml 文件读取配置设置的支持来扩展该工具的功能。
例如，如果用户在 c:useranhconfig.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 合并。为了开发他的存储库中的功能，我按照以下步骤操作：
- 分叉和克隆：我分叉了他的存储库并将其克隆到我的本地计算机。
- 创建分支：我在本地副本中创建了一个新分支并开始开发新功能。
- 提交并推送：进行更改后，我将它们提交到分支并将分支推送到我的分叉存储库。
git push origin <branch_name>
一旦 mayank 将他的更改推送到新分支并请求拉取请求 (pr)，我想在合并之前测试他的代码。这就是 git remote 变得至关重要的地方：
- 添加远程：我将他的存储库作为远程添加到我的本地计算机：
git remote add <his_name> <his_repo_url>
- 获取提交：我从他的存储库中获取了最新的提交和分支：
git fetch <his_name>
- 跟踪分支：我创建了一个跟踪分支来跟踪他的更新，而不会直接影响我的存储库：
git checkout -b <tracking_branch_name> <his_name>/<his_branch_you_want_to_work>
错误识别和解决
在测试过程中，我在 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 遥控器，我获得了实践经验，这对于未来的项目来说非常宝贵。
