Movatterモバイル変換


[0]ホーム

URL:


Skip to content
DEV Community
Log in Create account

DEV Community

AnhChienVu
AnhChienVu

Posted on

First time working with Git remote

Introduction

This week, I deepened my understanding of Git, particularly working with Git remotes. As a prerequisite, familiarity with Git merging is essential when dealing with remotes. Last week, I shared myfirst experience with Git merge and discussed somebest practices. This week, I applied that knowledge while working on a new feature, not in my own repository, but in acollaborator’s repository—my friend Mayank's. Simultaneously, he worked on a feature inmy repository, allowing us to practice remote collaboration using Git.

New Feature: Support for TOML Configuration

Currently, the tool I’ve been developing over the past few weeks uses a default set of values for options like temperature and model, which are applied when users don’t provide specific arguments. The goal of this new feature was to extend the tool’s functionality by adding support for reading configuration settings from a TOML file located in the user’s home directory.

For instance, if a user has a configuration file atC:\User\Anh\config.toml, the tool will now check for the existence of.toml files in the user's home directory. If such a file is present, the tool reads the file and applies its values to set default configurations, overriding the built-in defaults. However, users can still provide command-line arguments, which will take precedence over the TOML file values.

Implementation

To implement this feature, I utilized thetoml package to parse the contents of the TOML configuration file:

import*astomlfrom'toml';
Enter fullscreen modeExit fullscreen mode

Since the tool will search for a.toml file in the user’s home directory, I used Node.js's built-inos module to retrieve the home directory path:

constos=require("os");consthomeDir=os.homedir();
Enter fullscreen modeExit fullscreen mode

After gathering all the files from the user’s home directory, I iterated over them to find hidden files (those starting with a dot .) that end with.toml. The first.toml file found was used as the configuration source for the tool.

Notes

  • The tool will look for a hidden "dotfile" (e.g., .config.toml) in the home directory, containing default options in TOML format.
  • If the file is missing, the tool will ignore this and continue with defaults settings as in config.js file.
  • If the file exists but is not valid TOML, the tool will exit with an appropriate error message.
  • If the TOML file exists and no command-line arguments override its values, the settings from the TOML file will be used (e.g., default model).
  • The tool will ignore any unrecognized options in the TOML file to ensure backward compatibility.

Remote Collaboration Process

As mentioned earlier, this week involved practicing Git remote workflows and Git merging with Mayank. To work on a feature in his repository, I followed these steps:

  1. Fork and Clone: I forked his repository and cloned it to my local machine.
  2. Create a Branch: I created a new branch in my local copy and began working on the new feature.
  3. Commit and Push: After making changes, I committed them to the branch and pushed the branch to my forked repository.

git push origin <branch_name>

Once Mayank pushed his changes to a new branch and requested a pull request (PR), I wanted to test his code before merging. This is where git remote became essential:

  • Add a Remote: I added his repository as a remote to my local machine:
  git remote add <his_name> <his_repo_url>
Enter fullscreen modeExit fullscreen mode
  • Fetch Commits: I fetched the latest commits and branches from his repository:
git fetch <his_name>
Enter fullscreen modeExit fullscreen mode
  • Tracking Branch: I created a tracking branch to follow his updates without directly affecting my repository:
git checkout -b <tracking_branch_name> <his_name>/<his_branch_you_want_to_work>
Enter fullscreen modeExit fullscreen mode

Bug Identification and Resolution

During testing, I identified two key issues in Mayank’s branch:

  • Directory Misconfiguration: The tool was incorrectly reading the TOML file from the project root instead of the user’s home directory.
  • Path Resolution: The code was using a relative file path, causing errors when I ran it on my machine. I suggested switching to an absolute path
// Resolve the path to the configuration fileconstconfigPath=path.resolve(__dirname,"../.toml");// Load configuration from config.tomlconstconfig=loadConfig(configPath);
Enter fullscreen modeExit fullscreen mode

After identifying these issues, I discussed them with Mayank over Slack and collaborated to find a solution. I also provided feedback directly on his pull request. This process made me feel like I was contributing to a real-world collaborative project. Once I was satisfied with the fixes, I merged his branch into the main branch and pushed it to my remote repository.

Conclusion

This process of working with Git remotes and merging has been incredibly educational. I now feel more confident collaborating on shared codebases. Previously, I would often feel overwhelmed by multiple commits and contributions from different developers, but now I have better control and understanding of Git workflows.

By working on this feature and integrating Git remotes, I’ve gained hands-on experience that will be invaluable for future projects.

Top comments(0)

Subscribe
pic
Create template

Templates let you quickly answer FAQs or store snippets for re-use.

Dismiss

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment'spermalink.

For further actions, you may consider blocking this person and/orreporting abuse

  • Joined

More fromAnhChienVu

DEV Community

We're a place where coders share, stay up-to-date and grow their careers.

Log in Create account

[8]ページ先頭

©2009-2025 Movatter.jp