The answer is "it just works." There is no need to change the configuration files (of either master or minion). There is no need to worry about NAT or firewalls for the minions.

However, on the master, two ports need to be opened on the firewall. I accomplished this with:

iptables -A INPUT -m state --state new -m tcp -p tcp --dport 4505 -j ACCEPT
iptables -A INPUT -m state --state new -m tcp -p tcp --dport 4506 -j ACCEPT

On the minions, add an entry to /etc/hosts pointing the name "salt" to the master's IP address. Example:

root@minion2:~# cat /etc/hosts
127.0.0.1       localhost.localdomain   localhost
111.222.333.444  salt salt.example.com

Really, it is very simple.

You're thinking about this the wrong way, Salt is not designed to provide you with a history of the changes you've made on a machine but instead to dictate a "high" state the machine should be in. etckeeper follows changes made locally, logging changes made locally into git, while salt makes your boxes follow any changes in the git repo. If the minion has any local changes it'll show you when you do a highstate. Can you guess which one scales?

So here's a simple example of how to do this (this happens to use bitbucket for git):

1) Setup your salt master /etc/salt/master with:

file_roots:
  base:
    - /srv/salt

fileserver_backend:
  - git
  - roots

gitfs_remotes:
  - git@bitbucket.org:user/your-salt-repo.git

pillar_roots:
  base:
    - /srv/pillar

2) In the root of your git repo create a simple top.sls:

base:
  '*.domain.com':
    - core

3) Create some additional directories inside your git repo:

mkdir core
mkdir servers
mkdir servers/default
mkdir servers/minion01

4) Create a simple core/init.sls file:

/etc/ssh/ssh_config:
  file.managed:
    - source:
      - salt://servers/{{ grains['id'] }}/ssh_config
      - salt://servers/default/ssh_config

5) Create a default ssh_config under servers/default/ssh_config.

6) Create a minion-specific ssh_config under servers/minion01/ssh_config

7) Commit and push changes back up to your git repository (bitbucket).

8) From the salt master run: sudo salt '*' state.highstate test=true to see what changes will be applied.

When minion01 contacts the salt master it'll get servers/minion01/ssh_config, but any other minion (say minion02) where there's no ssh_config file under /servers/minion.id.whatever/ and moves down the list to the next source (servers/default). Instead of doing this by minion_id you can also do this based on other grains like os, fqdn, domain, etc (see a list of grains on a minion with salt 'minion-id' grains.items).

Once you've captured the initial state of these files you can make changes in a central place (the git repo) and then run state.highstate to roll further changes out. This initial pain is worth the effort. You could automate some of it, but what you're really looking to do is to find outliers which will by definition require some manual intervention to identify. I recommend you start with something like ssd_config and run state.highstate test=true one minion at a time. If there are changes from the default it will show you the diff and you can judge whether that warrants an exception to the default.

Note: You'll need to setup ssh keys for the root user on the salt master to have permission to read your git repository (bitbucket calls these deployment keys).