The only thing remarkable about this blog is how completely unremarkable the concepts chosen by the author really are. Let's go through them:
fetch - fetching the objects and metadata from a branch or branches from a remote repository
pulling from upstream - fetching from a remote repository (upstream, in other words all the changes flow down the stream to you, colloquial expression), then merge in the objects you fetched
cherry pick - choose which changes to apply ("cherry pick" them, colloquial term)
filter branch - modify a branch's history via filters
untracked - files that aren't being tracked by the source control system
symlink - a symbolic link, not even a git concept.
rebase - replaying all the changes committed from one branch onto another. Literally taking one base, and changing the base of a branch. i.e. re-basing the branch
tag - marking (or "tagging") a significant change in the repository
HEAD, head (note, mentioned twice by author) - a reference to the head of the revision history
working copy - the copy of a branch that you work on
path - really?
stash - you start working on some code, then you realise you want to change to another branch. So you stash away the working copy for later.
clone - cloning an existing repository so you can have your own to work on. That's why it's a DVCS
submodule - an external project from the main repository
fast-forward - when you merge a branch from another branch, git has the ability to forward the revision pointer quickly to the right point, see [1]
merge - merging changes
origin/master - the original repository. Convention.
staging area - also known as the "index", basically the concept is that you checkout a branch into a directory (called the working copy, see above), then you commit any changes into a staging area, then you push the changes into the repository
See? none of this was particularly hard to understand (although I grant you that "rebasing" and "fast forward" is a tricky concept, but hey, it's a source control system)
Comments
The only thing remarkable about this blog is how completely unremarkable the concepts chosen by the author really are. Let's go through them:
fetch - fetching the objects and metadata from a branch or branches from a remote repository
pulling from upstream - fetching from a remote repository (upstream, in other words all the changes flow down the stream to you, colloquial expression), then merge in the objects you fetched
cherry pick - choose which changes to apply ("cherry pick" them, colloquial term)
filter branch - modify a branch's history via filters
untracked - files that aren't being tracked by the source control system
symlink - a symbolic link, not even a git concept.
rebase - replaying all the changes committed from one branch onto another. Literally taking one base, and changing the base of a branch. i.e. re-basing the branch
tag - marking (or "tagging") a significant change in the repository
HEAD, head (note, mentioned twice by author) - a reference to the head of the revision history
working copy - the copy of a branch that you work on
path - really?
stash - you start working on some code, then you realise you want to change to another branch. So you stash away the working copy for later.
clone - cloning an existing repository so you can have your own to work on. That's why it's a DVCS
submodule - an external project from the main repository
fast-forward - when you merge a branch from another branch, git has the ability to forward the revision pointer quickly to the right point, see [1]
merge - merging changes
origin/master - the original repository. Convention.
staging area - also known as the "index", basically the concept is that you checkout a branch into a directory (called the working copy, see above), then you commit any changes into a staging area, then you push the changes into the repository
See? none of this was particularly hard to understand (although I grant you that "rebasing" and "fast forward" is a tricky concept, but hey, it's a source control system)
[1] http://git-scm.com/book/en/Git-Branching-Basic-Branching-and...
It all goes under the column labelled "Lore of the Jungle". Other tools have regular terminology; GIT seems to have grown its own language.
Half of that IS regular terminology. The test of the terms - there's no equivalent.