DEV Community

Cover image for Git Rebase and Code Refactoring for VShell Tool
AnhChienVu
AnhChienVu

Posted on

Git Rebase and Code Refactoring for VShell Tool

This week, I had the opportunity to delve into using git rebase while refactoring the codebase for my VShell tool. My primary task involved improving the structure and maintainability of the code while adhering to the DRY (Don't Repeat Yourself) principle, which is essential for making code more readable, maintainable, and easier to debug. Additionally, I followed various refactoring patterns outlined in the Refactoring Catalog, such as extracting function, extracting class, and renaming variables.

Before diving into the details of my refactoring efforts, I will provide an overview of the git rebase process for developers who are still getting familiar with this powerful Git feature.

Git Rebase Overview

Basic Commands:

  • git rebase <branch-to-use-as-a-new-base>: This command moves the commits from the current branch on top of the specified branch, effectively rebasing the current branch.

  • git rebase <basebranch> <topicbranch>: This command rebases the topic branch onto the base branch without needing to check out the topic branch first.
    Example: Normally, you would check out the topic branch and run git rebase, but this command allows rebasing while remaining in the base branch.

Conflict Handling:

  • git rebase --abort: Cancels the rebase and restores the branch to its previous state.
  • git add <file_changes>: Adds resolved conflicts to the staging area after resolving merge conflicts.
  • git rebase --continue: Continues the rebase process after conflicts are resolved.

Interactive rebase:

  • Use git rebase -i <branch-to-use-as-a-new-base> for squashing multiple commits into one.
  • After a successful rebase, the topic branches can be deleted, as all changes are integrated. Use git branch -d <topicbranch> to remove the branch.

Important Notes::

  • Avoid rebasing the main branch, as it affects other collaborators.
  • Rebase only on your topic branch to clean up your work before pushing.

rebase local changes before pushing to clean up your work, but never rebase anything that you’ve pushed somewhere.

Refactoring Process

  1. Creating a refactoring branch
    To prevent breaking the current working code, I created a separate refactoring branch based on the main branch. This allowed me to experiment with changes safely.

  2. Analyzing and Refactoring the Code
    Although I initially applied a modular pattern to the VShell code, further improvements were necessary to split larger modules and create a more readable code flow.

    • src/server:
      • I refactored repeated logging logic into a handleDebugMessage() function, allowing centralized logging through the stderr stream.
      • I also created a new ConfigHandler class in ConfigHandler.js to handle the configuration .toml file processing. The methods getTomlFiles() and loadConfig() were encapsulated into this class for modular handling of settings.
  • ai_config/grogConfig.js:

    • Two ways of returning responses from the chatCompletion AI had duplication in token usage retrieval. I extracted this logic into a getTokenUsage() function, allowing both readStream() and promptGroq() to reuse it.
    • Additionally, I fixed the typo in promptGroq() and renamed the temperature variable for better clarity.
  • src/ai.js:

    • I moved the handleOutput() function into a module handleOutputFile() to allow future reusability.
  • src/getFileContent.js:

    • Minimal changes were required here; I simply renamed file paths and variable names for improved readability and clarity.

Git Rebase After Refactoring

After making 11 commits during the refactoring process, it became necessary to consolidate them. To keep the commit history clean, I performed an interactive rebase using:

git rebase main -i

VSCode, configured as my Git editor, prompted me to squash the commits. After squashing, I had a single commit with all relevant changes. I then used git commit --amend to update the commit message instead of creating a new commit before merging into the main branch.

Squashed commit message

Conclusion

This week's experience with git rebase has provided me with valuable insights. Rebase is an essential tool for maintaining a clean, linear commit history, free from unnecessary merges. By mastering git rebase, I am now able to organize commit messages efficiently, minimizing confusion and ensuring a streamlined development workflow.

The refactoring effort has improved the structure and maintainability of the VShell codebase. Applying key design patterns like extracting functions and classes, I have made the codebase more modular, reusable, and easier to work with moving forward.

Top comments (0)