I actually do like A/B tests in Git, especially if you have great commit messages and tags around this, because there really should be a historical record of all experiments that have been run.
Throwing them away is a tremendous waste of knowledge. We found this to be true with our marketing and that was the reason for the push to setting up a Wiki. Even if we don't retain code around an experiment, we have a documentation format for recording what we made, what our expectations were and our results.
I mean more about the data required for an A/B test.
For example, we want to test showing a set of images on a page. Some users get set A, some get set B, some get none, and images need to be changed weekly.
The list of image URLs might be in a file in git, and get changed by a product manager each week for the duration of the test.
The A/B test would be run by our A/B testing service, which stores historical tests and reports indefinitely.
We’d then come and move the URLs into the database and add an editing tool later on if we decided to ship the A/B test.
Throwing them away is a tremendous waste of knowledge. We found this to be true with our marketing and that was the reason for the push to setting up a Wiki. Even if we don't retain code around an experiment, we have a documentation format for recording what we made, what our expectations were and our results.