I'm trying to understand why the git developer choose the word "checkout" for the command "git checkout ". The translation of the word checkout into Portuguese (my native language) does not clarify the meaning of the term "checkout". While I understand the effects the command has on my git project, if the command were git abrakadabra it would sound the same to me.

CodePudding user response：

The idea of checking a file out did not originate in Git.

In English (at least), when you borrow a book from a library, you are said to "check the book out": you take the book from the library, promising to return it later. While you have the book, no one else can use the book, as it isn't available from the library any more.

Other source control systems work similarly. Checking out a file means that only you can edit the file. Any one else attempting to check the file out must wait until you check it back in to be able to edit it.

This type of exclusive access does not apply to Git (as a distributed source control system), but the term was retained to describe the idea of selecting a branch from the repository to populate the working directory (effectively, checking out many different files all at once to edit until you "put them back" by checking out another branch).

CodePudding user response：

I'll copy a bit here from my proto-book. The term is not specific to Git though (as chepner already said).

Thus, a [Version Control System or] VCS acts as a database of source files, with some way of retrieving specific versions of the files. This database is called the repository. When you add updated versions of your source files, the database stores the updated sources inside the repository. Each version of a file is also called a revision, so that if you fix a spelling error and enter the updated file into the repository, you now have another revision of that file.

Used as a verb, to version means to put under control of the VCS. Used as a noun, version means a specific version taken from the VCS (of one file, or of a group of files). Usually the noun form appears with additional modifiers, as in the phrase the old version of kanga.c or version 2.1 of roo.c. If no specific files are listed, we typically mean everything, or at least everything recently under discussion: version 2.1 (of everything in the repository, or of the specific files and/or directories we were talking about). The word revision is always a noun, but otherwise means the same thing as version.

Another verb, to check in, means to store into the VCS. As you might expect, if we can check in, we can also check out, meaning extract from the VCS. Some VCSes add the verb to update, which they may use to distinguish between extracting an older version (which you check out) and moving up to the latest and (we hope) greatest (to which you update). Mercurial uses update as a pure synonym for checkout.

Check in is sometimes hyphenated (check-in), or written as one word, checkin. These avoid ambiguity: I’ll check in roo.c (look through the code to see if any wallabies got in there) vs. I’ll check-in roo.c (to store a new revision). Check out is likewise often written as one word, checkout, or hyphenated, but the verb form is still checking out, which reads much better than checkouting.

Newer VCSes add more noun-and-verb words:

• To commit means much the same as to check-in, but with some technical differences we will see in a moment. As a noun, a commit also refers to a version, but specifically one as stored by the verb form of commit.
• To clone is basically a fancy term for copying an entire repository, often from a different machine over a computer network, e.g., from a web site. As a noun, a clone is a repostory made by cloning.
• To fork is functionally the same thing as cloning, but usually with a different intent. The noun form a fork is thus the same as a clone, but those making making a fork may intend for their work to diverge with little or no re-synchronization (perhaps forever or perhaps for a limited time), and/or for still others to collaborate via their fork instead of the original.

Addressing Schwern's comment about rcs co and rcs ci, it's worth noting a few historical items:

• RCS's checkout verb by default did not lock the (version-storage) file: it got you a read-only file in the working tree. You had to use co -l to obtain a lock, which provided you with a read/write file you could update.

• RCS's co and ci post-dated SCCS's checkout/checkin. However, in sccs we had two separate extraction verbs: get meant get a read-only copy and edit meant lock the file and get a read/write copy. See, e.g., the Oracle documentation for details. The "check in" command was spelled delta.

RCS was, I think, the first version control system that used the terminology that survives today. Its verbs persisted into CVS (the Concurrent Version System) and Subversion ("CVS done better"), and from there, propagated into all the modern version control systems (see Wikipedia for a rather large table). Modern SCCS is a re-implementation of the earlier Unix SCCS, which itself was probably at most loosely based on the IBM SCCS that predates that.

CodePudding user response：

actually, You need to use git checkout while you used git because this command will tell you who branch you are on right now

Try:

git checkout

Output:

Your branch is up to date with 'origin/Master by example'

please tell me if this help you