In this lesson, we will not make changes to the functionality, instead, we’ll just move files around. This is an important best practice. You should always separate structural, formatting, and style changes from functional changes. We will do some planning and then refactor most of the logic into a repo_manager package.

Planning the refactoring

Here is the plan. We will extract the code that performs the interaction with git and manage the repos into a separate package called repo_manager. The repo_manager package will also contain unit tests to make sure it really works. The original multi-git didn’t have any tests. In addition, we will create a helpers package for general-purpose operations like creating directories and adding files.

The main() function will remain in the root directory for now. In the next lesson we will move it into its own directory under the cmd top-level directory.

The reason for these choices is to clearly identify what the core logic is (dealing with multiple repos and executing commands on all repos) and what the command-line interface used to access the core logic is.

Separating them in two steps, first the core logic and later the command-line interface, will eliminate subtle issues of interactions between these two refactorings.

This step is not really necessary for a small program like multi-git, but if you ever try to break a large real-world ball of spaghetti monolith, you will need all the help you can get. Following a methodical approach of refactoring one well-defined aspect at a time can save a lot of time, mistakes, and confusion.

Moving files around

Let’s get to the business of actually refactoring the code. As you recall in version 0.1 of multi-git, the ...

Refactoring the Core Logic

Planning the refactoring