Additionally, I don't think sense 29 actually makes sense here. A "master copy" is immutable. Once somebody burns a master record, that's it — you're done. You make copies from that one because it is deemed "correct" in some sense.
But git branches are not immutable; they are able to be added to at any point. The master branch can be interpreted as collating the work done by all of the other branches: non-master branches do some work, then it gets merged back to `master`. Which means... the master branch is coordinating work done in other branches. And, in many git workflows, work on the master branch itself is discouraged, meaning almost all work is done in separate branches and then the master branch is used to accumulate that work, and is the main reference point to see "the current state of things". I don't think it's a stretch to see why the master/slave relationship seems a more fitting sense of "master" than "master copy".
> Git's terminology descends from BitKeeper, which was explicitly using master/slave
That GNOME mailing list post was retracted the next year[0].
I wrote a summary of the history[1] for Git Rev News, the git developers newsletter. In short, the usage didn't come from BitKeeper, and was intended to mean 'master copy'.
After the article was published, Aaron Kushner from BitKeeper reached out and gave me some more history on the usage of 'slave repository' in that one particular spot in BitKeeper[2]: it was a presentation for a client that was already using master/slave terminology and so the same terms were used in the presentation.
If we scroll to the adjective section, we see three notable definitions:
> 28 directing or controlling: a master switch.
I assume this is the definition you are thinking of?
But I don't agree that this is the definition git is thinking of. I think it's either:
> 27 chief or principal: a master list.
or
> 29 of or relating to a master from which copies are made: master film; master matrix; master record; master tape.
I would agree that the definition you are referring to has racist connotations, but I don't think #27 or #29 does.