Depends on what you call a repo. I run git init almost everywhere (including my $PERL5LIB to easily switch between various versions of CPAN modules), and as I own several computers (desktop + 2 laptops), I usually need everything on all of them. GitHub nowadays offers private repos for free, but I still use a USB flash drive from the times when it didn't where I create --bare repos for all my personal projects and set them as remote origin.

> I organized the tests using the same structure as my modules

Interestingly, we used the same strategy at $job - 2. There were hundreds of modules and it was surprisingly easy to find the corresponding tests for the file one had just modified.

package Foo;

sub returnANumber {
    return 66; 
}

package FooUser;

use Foo;

if (Foo::returnANumber() < 82) {
  # do something
} else {
  # do something entirely dependent upon returnANumber being an intege
+r > 0 && <= 100...
}
[download]

Recommendation #1 is to write tests and package them alongside your scripts to ensure that one travels with the other. Or you could just store them inside a DATA segment at the end of a script...

#!/usr/bin/perl -w
use strict;
use Getopt::Long;

my ($aa, $bb, $diagnostic) = (undef, undef, 0);

if (@ARGV){
    GetOptions('aa=s'=>\$aa,
           'bb=s'=>\$bb,
           'diagnostic'=>\$diagnostic);
}

if ($diagnostic){
    my $test = '';
    while(<DATA>){
    $test .= $_;
    }
    eval($test);
    die 'Ran tests. Done.';
}


1;


__DATA__

use Test::More qq~no_plan~;

ok(1==1,'basic');

1;
[download]

"Then get right back to work. I no longer have to worry about whether my tests are including the right path to my modules..."

Unfortunately this is the problem I run into all to often. Developers and support people do all of the right things...they write tests, they modularize their code; they store things in separate libraries on a hard drive. All good. Problem: what happens if you take another job?

I get it. People say, 'well...I wrote that stuff to facilitate my work; the next person is just gonna have to figure out my stuff or cook up their own...' Yep. And the next person shows up on Perlmonks with 30 questions about how X, Y, and Z works.

You specified your workflow and even enumerated the points. Here is where I think it falls short:

1. Stop writing code and start writing down what you want code to do (use psedocode/perldoc, whatever). Then look in CPAN for modules that do what you want. Ask if they are recently modified or easy enough for you to understand that you can modify them yourself it they break. Then actually use the modules.
2. Add your own tests. You are on the right track there.
3. Everything, everything, everything must go into some form of version control that is backed up on some redundant data storage away from your machine. No exceptions whatsoever. That includes scripts and utilities. When you are away from work you are likely learning. When you learn you get some code. When you return to work you'll try to remember that code. Guess what...you lost it. That is why even your personal stuff must follow this rule. The company's stuff is company property. If you didn't back that up you misappropriated company resources.
4. Always periodically rethink our workflow. I check my history file all the time kind of like how a Russian submarine does a 'crazy Ivan' to see what I am doing repeatedly. It is odd how we don't realize that we do something that could be scripted saving us cumulatively hours per month and weeks per year.

The last one is a bit tricky because it depends a lot on the industry you are working in. If you are in some engineering firm you might find that there are numerous conditions that no one has thought about that will force you to refactor code a lot. In that case you might find you have to keep your code in some smaller pieces that can be mashed together at some later point.