If you're ever running commands on a remote machine you should absolutely be running it in a detachable session so it doesn't die if your connection drops. Chose tmux, here's why!
What is Tmux?
Tmux is a terminal multiplexer, hence the name. It allows you to create multiple terminals to be created in a single window. It can also be run in the background allowing you to detach from a session and come back to it later.
Aren't there other solutions?
Before Tmux we typically used screens, also detachable and also 33 years old now. Screens also isn't very actively developed anymore and was never designed with UNIX in mind. It's arguably more difficult to use and has some downsides mentioned in the Tmux wiki.
Tmux is widely used and has active development. You'll find a lot of guides out there discussing configuration and usage. It's also a joy to work with, the status line is useful and most terminal commands work directly in tmux.
Why would you need a terminal multiplexer?
There are multiple reasons for using a terminal multiplexer, personally my 2 main use-cases for tmux are:
1. Running tasks on remote servers via SSH 2. Running multiple services for development
Even just for poking around on remote servers tmux is useful. It allows you to open a single connection and manage multiple tasks. Easily context switching, comparing, retaining logs in each pane.
Running tasks on remote servers
If you need to run tasks on remote servers you should always do it in a detachable session. If you cannot detach your session you run the risk of a dropped-connection killing your task. If your task is not idempotent then you also run the risk of corrupting data in irreparable ways. I've learned this the hard way, luckily not in production but it did cause a massive headache when trying to figure out how much data had already been processed.
Tmux allows us to spin up a session inside your terminal where you can then run your script. You can even create multiple splits within that session and run multiple scripts. You can now safely detach, logout, go home and eat dinner, login and continue.
Remote servers are often accessed by multiple users so I recommend naming your tmux session so any other developers can easily recognize that it's yours.
I also recommend naming your windows if you are running different tasks in each one. Or even giving them IDs if running the same task so you know which task is processing which data segment.
Running multiple services for development
With tmuxinator you can easily start multiple services in a single session. This allows you to startup your entire development environment with one command.
To create a config run
tmuxinator edit project_name
You'll be presented with a pre-filled config file. You're going to want to update the root path to the path of the project, then we can configure the tmux windows that will be created.
My typical rails development environment includes a rails server, rails console, elasticsearch, sidekiq, guard for specs, webpack-dev-server, and a window for committing changes.
With iTerm2 you can also integrate tmux nicely and make each of the tmux windows look and behave like a normal iTerm window. I have configured mine to open tabs, bury the tmux client, and show the tmux status bar content. This allows me to start up the development environment as if I've just opened tabs and ran the commands manually.
I can also kill the tmux session and all of the windows close, returning me back to the original window before I started tmuxinator.
Want to learn more?
I recommend saving some cheat sheets. Tmux can feel a bit alien at first but with cheat sheets it's easy to get by. If you want to learn more, tmux provides a lot of great documentation and FAQs in their wiki. Their Getting Started guide goes into a lot of information that will give you a good understanding of the basics.