In Git, the analogy is not between master and slave but rather master and branch.
Here's a helpful picture:
There are several facets that could tilt toward the master/slave analogy:
- Like a slave, the branch is dependent on the master.
- The branch is less prominent and does not get released into production code.
There are several facets that steer away from the master/slave analogy:
- Unlike a slave, the branch starts out as an exact copy of the master.
- The branch gets merged back into the master, creating a new master
- Developers (a third party, and neither master nor slave) work on the branches independently and in parallel.
- Developers meet and collaborate to merge branches and determine the best course of action when branches conflict
This ZDNet article tosses the notion back and forth:
Both Git and GitHub use the term "master" for the default version of a
source code repository. Developers fork a version of the "master" to
create secondary versions, add their own code to this default version,
and then merge their changes back into the "master."
Most detractors and the explanation that often resurfaces in these
discussions is that terms like master/slave are now more broadly used
to describe technical scenarios than actual slavery and that the word
"blacklist" has nothing to do with black people, but the practice of
using black books in medieval England to write down the names of
problematic workers to avoid hiring in the future.
So perhaps a nuanced answer to the OP's question is: While the evidence points away from a master/slave relationship, Git and many other usages of master are being re-examined, regardless.