My Way to Organize a Git Repository for Bash, Mikrotik, FortiGate and other Scripts

Organize a Git Repository Structure for Scripts

In this post, I’ll share my way to organize a Git repository for Bash, MikroTik, FortiGate, and other scripts, based on the real-world needs I faced while managing multiple systems and configurations.

Over time, I’ve accumulated a large collection of scripts: Bash automation tools, MikroTik router configs, FortiGate CLI triggers, Docker projects, and Ansible playbooks. At first, they were scattered across multiple servers and folders — each one a bit different, hard to track, and easy to lose.

Eventually, I realized I needed a better way to manage all of this. That’s where Git came in.

This post shares the structure I’m using to organize everything in one Git repository — not as a universal standard, but as a proven method that works for my workflow.

Why I Started Using Git

When working across multiple servers, it’s easy to fall into the trap of:

Copying files manually
Forgetting which version is where
Breaking something and not knowing how to undo it

These were exactly the kinds of problems I ran into. Git helped me:

Maintain consistent versions of scripts across machines
Track changes over time
Experiment with changes without fear of breaking something
Keep everything organized in one central place

Even if you’re working solo, Git is an invaluable tool for keeping your infrastructure scripts under control.

Benefits of Using Git for Scripts and Automation

Here’s why using Git for managing Bash scripts, network automation, and infrastructure configs is a game-changer:

Version control: Easily revert to working versions when something breaks
Centralization: All your scripts live in one place
Change history: Know what changed, when, and why
Multi-environment use: Clone the repo to staging, production, and lab systems
Safe experimentation: Use Git branches to try new ideas
Portability and backup: Sync with GitHub, GitLab, or your own private Git server

How I Organized My Git Repository

I grouped my scripts and configs into folders by technology and purpose. This makes it easier to find what I need, avoid duplication, and manage things long-term.

Here’s the structure I use:

my-scripts/
│
├── mikrotik/
│   ├── config_backup.sh
│   ├── firewall_reset.sh
│   └── snmp_setup.sh
│
├── fortigate/
│   ├── backup_config.sh
│   ├── get_routing_table.sh
│   └── apply_policy_via_ssh.sh
│
├── linux/
│   ├── backup/
│   │   ├── db_backup.sh
│   │   ├── rsync_home.sh
│   │   └── logrotate_setup.sh
│   ├── monitoring/
│   │   ├── cpu_temp_check.sh
│   │   ├── disk_space_alert.sh
│   │   └── uptime_report.sh
│   ├── network/
│   │   ├── ddos_blocker.sh
│   │   ├── ip_blocker.sh
│   │   └── ping_sweep.sh
│   └── misc/
│       ├── repeat_command.sh
│       ├── clean_tmp_files.sh
│       └── update_all.sh
│
├── docker/
│   ├── wordpress_rpi4/
│   │   ├── docker-compose.yml
│   │   ├── .env
│   │   └── README.md
│   ├── ddos_proxy/
│   │   ├── Dockerfile
│   │   ├── nginx.conf
│   │   └── README.md
│   └── portainer_stack/
│       ├── docker-compose.yml
│       └── README.md
│
├── ansible/
│   ├── inventories/
│   │   ├── production/
│   │   │   └── hosts
│   │   └── staging/
│   │       └── hosts
│   ├── playbooks/
│   │   ├── fortigate_backup.yml
│   │   ├── deploy_monitoring.yml
│   │   └── update_packages.yml
│   ├── roles/
│   │   ├── common/
│   │   │   ├── tasks/
│   │   │   │   └── main.yml
│   │   │   └── handlers/
│   │   │       └── main.yml
│   │   └── nginx/
│   │       └── tasks/
│   │           └── install.yml
│   └── group_vars/
│       └── all.yml
│
├── shared_libs/
│   ├── logging.sh           # Unified logging for all scripts
│   ├── common_functions.sh  # General-purpose functions
│   ├── error_handler.sh     # Trap and exit handling
│   └── ssh_wrapper.sh       # Wrapper for SSH-based scripts
│
└── README.md

Explanation of Each Folder

`mikrotik/`

Scripts for interacting with MikroTik routers – backups, SNMP setup, firewall rules, etc.

`fortigate/`

Automating FortiGate tasks from Linux: triggering backups, pulling config, checking routes.

`linux/`

A variety of Bash scripts:

backup/: rsync, database backups, log rotation
monitoring/: CPU temperature, uptime, disk space
network/: ping sweepers, IP blocking
misc/: general-purpose utilities

`docker/`

Each subfolder is its own project:

WordPress on Raspberry Pi
Proxy server for DDoS protection
Any other containerized tools

`ansible/`

Structured for real automation:

inventories/ for different environments
playbooks/ for specific tasks
roles/ for reusable logic

`shared_libs/`

Contains shared shell functions (e.g., logging, error handling) used across multiple scripts

Conclusion

Having a well-organized Git repository has made managing my infrastructure tools and scripts much easier. It helps me avoid duplication, work safely, and track everything in one place.

This structure isn’t carved in stone — it grows and evolves as my work does. But since adopting Git and organizing things this way, I’ve had far fewer problems and a lot more confidence in my automation.

If you’ve been dealing with scattered scripts or repeated errors from inconsistent versions, I highly recommend setting up a Git repository like this. You don’t need to know everything to get started — just begin organizing and commit as you go.