Repository

Repository is a bit of an overused term, but it refers to the location where the source code is ultimately stored. It's sometimes referred to as a repo. Some systems refer to this as a depot. Repository is more common in several circles, so I'll stick with that.

SCC

Source code control—the technology and/or management of, and changes to, source code. The acronym SCC seems to be used more often in Microsoft circles. It has more historically been referred to as revision control or version control, or even source control. There are other systems that deal with revisions to files in a broader sense. So, I prefer "source code control" when talking about managing changes to just source code.

Edit/merge/commit

There are two basic models for how SCC systems manage the concurrency of changes made to files under their control. One is the edit/merge/commit model. This model is quickly becoming the most popular amongst the more recent SCC systems. It basically works on the fact that the system knows what version of a file you started with, and putting edits to that file into the repository is the act of merging the changes into the current version before committing the change.

Lock/edit/check-in

The other model of managing concurrent changes to a file controlled by an SCC system is lock/edit/check-in. This model is based on the principle that someone makes an exclusive lock on a file before making edits to the file and "checking them in". A drawback of this model is that only one person can edit a file at a time. Some systems get around that by switching a lock with a check-out, and making you manually deal with merging changes between concurrent edits.

Trunk

Typically, the trunk is the baseline of the source code. It's the in-development version of the source that is generally considered in development or most recent. Sometimes it is called mainline, but mainline could mean the baseline of any existing branch, not just the trunk. Whether or not a project has a trunk largely depends on the branching strategy. The overwhelming recommendation is to retain a trunk and have independent branches based on need or strategy.

Branch

Just as with real-life trees, a branch is something that divides off from the trunk. In SCC, a branch is something that is independent from the trunk, with the expectation that changes to the branch will be merged back into the trunk (or the parent branch). In many SCC systems, trunk is a type of branch.

Fork

Fork is typically another name for a branch (that is "a fork in the road"). Recently, this has become known as taking a copy of a trunk or a project, with potentially no expectation to merge anything back into the source of the fork. This is typically seen in open source projects where someone publishes a source code and someone else who wants to use it for their own purposes forks it to get a copy for themselves.

Merge

The act of integrating changes from one branch to another. Depending on the branching strategy, one of the branches may typically be the trunk.

Check-out

With more recent advances in the SCC technology, this typically isn't needed. Checking-out code generally means registering with a SCC system that you want to modify a specific revision. It has come to mean simply getting the latest version of the source code in systems that are edit/merge/commit.

Check-in

In the broadest sense this simply means moving revised code into a repository. At a more pedantic level this terminology is from source control systems that mandate a check-out model, and check-in means you no longer have code checked-out.

Changeset

Considered one or more changes made to code/files that is committed. This can be changes to files, addition of files, or deletion of files. All of the files' modifications committed at once are considered a changeset.

Lock

Although more prevalent in the lock/edit/check-in model, this refers to locking a file down for concurrent changes, so that only one change can be made at a time. Some files don't merge well (like binary files) and require that merging be avoided. Locking a file before edit/commit or edit/check-in prevents merge corruption.

Commit

Similar to check-in, this means putting edits of one or more file into the source control system. Edits will not be tracked by the system until being committed.

Push

Typically push is the term used only with distributed SCC systems. Push means merging local commits into a remote repository or a master branch stored in a remote repository.

Pull

Typically a term used with regards to distributed SCC systems. It has come to mean a request to merge independent changes. A pull request is typically done from a fork of a project. Someone working on their own code could have someone else fork from that code (unbeknownst to them). That external party could find a bug and fix it or add a feature that they feel would be useful to the original author, at which time they request the original author to pull that change into the original source (which is likely to be modified by now).

Tag/label

Most SCC systems have an ability to tag some or all of the source code under control with a name. This is a good way to pin the source code at a specific time and date. This is often a good option instead of branching if you're not sure whether you're going to need to make any changes to that code once tagged. You should be aware of how the SCC you choose performs tagging. For example, Subversion (SVN) implements tagging as a branching. That is when you tag source code in SVN it does the same thing as a branch and copies the source code. Most SCC systems let you branch from a tag or label, so if you find you do need to make changes specific to that labeled source code, you can branch first.

Shelving/shelvesets

Most SCC systems have a feature called shelving. This is generally the ability to take existing changes and put them on the server without committing or checking-in. Some teams use this as a way of code review. One team member puts their changes in a shelveset and another member gets the changes off the shelf and reviews them. When approved, the original member can commit the code or the reviewer can commit the code.

The intention of shelving is for times when you're currently in the middle of some work and need to temporarily abandon the work, to work with source code prior to your changes. As shelvesets are stored in the SCC, they are controlled in their own right and are accessible by anyone who has access to the SCC. Due to this, shelvesets can be shared between users without affecting any branches. This is useful if you want to transfer work-in-progress from one person to another, or for senior developers to review work before it is committed.