Unit-testing – Agile development deployment process. Where do QA and Business Owners test

This is not a Git-specific answer, but it should work regardless of the VCS system you use.

I would start with several different repositories

• One for each client, containing the client-specific files and a configuration file stating which options the client has purchased
• One or more repositories with the development code

Then I would use a make_release script (written in your favourite scripting language) that does the following:

1. Given the name of the client, checkout that client's repository to a temporary location
2. Based on the purchased options, checkout or copy (from an existing checkout) the application and modules to the same location
3. Remove all files/directories that are not relevant for the client (especially those that contain data meant for the VCS system)
4. Package the release in a convenient format (e.g. zip or tar.gz)

Then deployment should be as simple as copying the release to the client's server, unpacking it and running whatever scripts that are needed to finish the installation/upgrade.

• Git is not suitable for managing different variants of your code.
• Git is not a deployment mechanism.
• Git is just a source code management system.

One thing that gets lost when using git push as a glorified FTP command is that source code is source code, and not necessarily the same thing you deploy. That even holds for interpreted systems where the source code can be executed directly.

One way to solve this is to introduce a build and deployment process that gathers the necessary files and deploys them to a certain target. Your source tree in Git might then be in a valid state for running it in a development mode, but for your production targets different config files will be used. For example, but not necessarily, a Docker image could be such a deployment format.

If a deployment target (such as Heroku) expects you to deploy via Git, it would be possible to use another repository or branch separate from your source code that contains the state to be deployed. This feels rather hackish, but actually works very well. However, this branch/repo does not contain any source code that needs to be version controlled since it's mostly a duplicate of the actual source code (from which it can be rebuilt at any time). It may therefore be occasionally desirable to prune these branches. You also lose a direct association between the deployed commit and the corresponding source code commit. Heroku may also offer other deployment types that do not abuse Git, but I'm not aware of those.

If a deployment target lets you run run pre-deployment scripts, that would be another solution. Such a script can then set up the necessary environment. For that to work, this script must be ignored by other targets or can detect under which target it is running.

In any case, adding deployment target-specific commits during your release process that are not expected to be merged back into dev is an antipattern. These will either get removed in a merge, or never become part of the history of other branches. Git is not good at maintaining a set of changes that only live on one branch if you want to merge other branches.