Git borrowed the term “master” from BitKeeper, the proprietary tool the Linux kernel used before Git existed.
In BitKeeper, a “master repository” referred to the authoritative repository in a set of distributed clones. When Linus Torvalds created Git in 2005, he followed that naming convention and called the primary branch “master”.
The trunk metaphor doesn’t work very well in Git, because branches aren’t long-lived containers of sequential commits the way they are in SVN. There is no “root” commit that is guaranteed to have a consistent relationship with main, because branches are just names attached to a commit and can be reassigned at will.
huh I always assumed it was just taken from how HDD’s used to work back in the way if you ran multiple on your machine. you had to designated on the motherboard and/or HDD which hard drive was the “Master” and which was the “Slave”
Git borrowed the term “master” from BitKeeper, the proprietary tool the Linux kernel used before Git existed.
In BitKeeper, a “master repository” referred to the authoritative repository in a set of distributed clones. When Linus Torvalds created Git in 2005, he followed that naming convention and called the primary branch “master”.
Should have followed Subversion so we’d have “trunk” with the branches coming off it.
The trunk metaphor doesn’t work very well in Git, because branches aren’t long-lived containers of sequential commits the way they are in SVN. There is no “root” commit that is guaranteed to have a consistent relationship with main, because branches are just names attached to a commit and can be reassigned at will.
huh I always assumed it was just taken from how HDD’s used to work back in the way if you ran multiple on your machine. you had to designated on the motherboard and/or HDD which hard drive was the “Master” and which was the “Slave”