Do you think the keywords used by git (or other version control systems) are intuitive?

I'm talking to a very junior dev about git and I find myself having to explain around the fact that I don't feel the keywords are great. They are asking good questions like
* Why do you say "push the commit" but then say "make a pull request" - when I want to push why isn't it called a "push request"
* "Why are the metaphors sometimes related to trees (branches), sometimes roads (forks) but you still call it "master" instead of tree trunk or main road?
* Why do you call it "commit", what kind of commitment am I making?

I think git is a bit harder than say, svn, but I think that's a product of ethos. Git, no server, no repo is special, so you're sharing commits between repos which complicates the language.

Hm.

The thing about words and associations is that they will never be good.

A pull request is _pulling_ changes from a branch.

Bifurcation is a fancy complex word, a fork is easier to grok - after all it's a copy of a branch at a certain point of time, thus a commit.

master is just a workflow related term and has nothing specifically to do with git.

It could be called 'your mommy'… if you fancy that.

The reason the terms diverge so much little ones is because the terminology stems from different roots.

Gits internal representation of objects is infact binary tree related, but the outer workflow are just references - and as we all know, a reference can be any word we want. Internally the value of a reference or better it's string representation isn't interesting at all.

Hence we got a pretty wild terminology.

In some aspects git refers to an internal perspective, in others to a workflow.

Eg. a working tree is a reference to the internal way, but that you can stage changes in the working tree is rather workflow related. You commit the changes, so that the internal representation is changed and add an commit to the history - hence staging area and commiting refer to the workflow of changes.

Push
the changes are leaving your copy

Pull
the changes are being added to your copy.

Keeping it that simple, a "pull request" is backwards in the sense of ownership, which is why I prefer "merge request"

Pushing means making the remote branch exactly the same as the local branch.
A pull request is a request to whoever is in charge of the remote repo, do do the same by pulling in your version of the branch.
So while the first changes the remote branch now, the second is just a request for that change.

An acyclic graph with only one start node is almost always called a tree. While you definitely can have as much roots (commits, which are the first in their branch) as you like, doing so normally makes no sense in the context of version control. So the commit graph almost always is a tree (with merging branches of course - but lets not be too picky...).

Linus, the creator of GIT also created Linux - the kernel powering almost the entire Internet and over half the smartphone market today.
Forking a process in Linux means copying its state into another process and continueing running both of them.
Forking a repository works just like that: You clone it and commit content changes to your local copy...

"master" is an often-used term in tech. It normally means a version, which is copied a lot (like the gold master when pressing vinyl or compact disks), hard- or software controlling other hard- or software (which then in fact are called slaves), or just as synonym for "main" (like in GIT *g*).

While a commit should imply some sort of commitment, there sadly rarely is any... But actually, it probably has more the meaning of "consign" or "confide" in that you give your changes to the repo to be added to its ethernal history - where everyone can at any time git blame the bugs you committed...

@C0D4
You can only merge, what you fetched. Pull actually does a fetch followed by a merge. Pull request therefore is the most matching name for it (even though it technically is a request to only pull part of a branch...).

Not really intuitive

@IntrusionCM some system call pull requests merge requests which is more sane and does not require fancy logic acrobatics. (Also, you request to push your changes to target branch. I don't see how it cannot be a push request)

not intuitive, like most of our tools and languages are not really intuitive and different metaphors get mixed that do not really match (also root+branches vs. upstream/downstream)

People already explained push/PR

But one thing I think ya'll missed is that It's all tree metaphores

"Master" is just short for "master branch", It's just a name for a branch like any other branch there's no tree root because It's all branches!
And "tree fork" is a real term... Indeed the word "fork" is by no means limited to roads. Tree forks, River forks, road forks... Hell a fork(cuttlery) is called a fork because it has a handle and then it turns into several points.

Git is intuitive enough when you have deep enough understanding of the english language.

- you "push a branch" with all its changes (often that's more than just a single commit)
- conversely you "pull a branch", and you normally get more than just a single commit
- "pull request" is only when you ask someone to "pull" your branch into their repository, and only exists on platforms like GitHub, which isn't the same as git
- "commit" has lots of meanings in English, e.g. a patient is committed into a hospital (meaning they didn't just go to a hospital, they were actively accepted into the hospital by the staff), an information can be committed into memory (meaning you didn't just remember it, you actively decided to memorise it)
- "fork" in English means any sort of split into two possible directions, not just roads; when you fork a branch, each resulting branch takes on its own direction
- "master" branch "rules" over all other branches

People who don't natively speak English: Not my problem

@catholic-emacs the wording would be worse if it was in German, I'm quite happy with English here!

Does it matter? After few months of using git you should pick a side and either be one of those guys with 2 letter aliases for every command or one of the guys who don't even know git commands because they click 2 buttons in their IDE instead.

Not intuitive at all, but my issue is with the more advanced commands. Cherry picking, rebasing, squashing, etc.

Fun facts:

- centralised VCSes use trunk and branches (by convention) because, well, they're centralised (as in: there's only one tree); Git is decentralised, hence, anyone can have their own master branch and fork branches, there simply is no such thing as trunk in Git

- it isn't *called* "pull request", it's just what GitHub calls it but for example GitLab calls it "merge request" and Git doesn't call it anything because pure Git doesn't have such concept; these "requests" are web calls invented by hosting companies to create a special page on their service so that people could merge changes through www; Git doesn't come with a server, there's nothing to serve to a browser, ergo, no "requests"

- road is not the only thing that forks, branches fork as well, actually 30 years ago when you said "I came to a fork" it meant something dirty and probably painful, you had to say "I came to a fork in the road" to be understood