<p>It's important to note that the terms "checkin" and "checkout" have different meanings depending on the type of SCM system.  </p>

<p>Centralized systems like TFVC, Subversion, and Clearcase use "exclusive" checkouts.  This is like Pierre's book borrowing metaphor, where only one user can have a file checked out at one time.</p>

<p>Distributed systems like git have a "checkout" command, but it means something completely different. <code>git checkout</code> is used to switch between branches when working with a local repository.</p>

CC BY-SA 3.0
2018-04-28T19:51:51.053Z
I should clarify: git checkout is used to check out objects from the repository.  That can be a branch, or a single file.
Dave Swersky
CC BY-SA 3.0
2017-03-01T18:24:26.703Z
Good point Dave about the distributed systems! Actually that's also why myself at first (when I first learned about GIT) was terribly confused. To not invalidate your answer (by adapting my question), I refined my own answer to clarify it a bit.
Pierre.Vriens
CC BY-SA 3.0
2017-03-01T18:11:39.347Z
2017-03-01T18:11:39.347Z
Dave Swersky
<p>With the <em>SCM repository</em> as the main subject then'</p>

<ul>
<li><strong>checkout</strong> is getting changes <strong>out</strong> from the local or remote repository (into your local working directory).</li>
<li><strong>checkin</strong> is putting changes back <strong>into</strong> the the local or remote repository (from your local working directory).</li>
</ul>

CC BY-SA 4.0
2018-09-12T21:17:14.497Z
Merci for this answer *also*. That's indeed a way to explain it, though I still wonder if you can think of some sort of "metaphor" (as in my question). E.g. to explain it to somebody you'd be teaching, who doesn't even have a clue what a local or remote *repository* really is.
Pierre.Vriens
CC BY-SA 4.0
2018-09-12T21:49:54.077Z
True, if they have no clue about what a repository is then trying to teach checkin and checkout will be meaningless. Now, for a metaphor for source control in general you can compare it to financial accounting/bookkeeping. It is fundamentally keeping track of changes to the value of assets. You record either single individual changes or groups of changes (e.g. "Travel from A to B" rather than taxi ticket + bus ticker + train ticket + ...) although not too large groups (e.g. "All expenses on Monday"). Similarly a repository keeps track of source code changes, individual or not too large groups.
hlovdal
CC BY-SA 4.0
2018-09-12T17:39:24.320Z
2018-09-12T17:39:24.320Z
hlovdal
<p>For centralized systems, think of it like a technical library. (might be a stretch of the imagination how this hypothetical library functions...)</p>

<p>If you are an author of a document, you might <code>checkout</code> the library copy, make changes, return it <code>check it back in</code> to the library for the world to see.</p>

<p>This can become an issue if the library has digital copies, and I <code>checkout</code> a document, someone else also <code>checks out</code> a document, we both make changes, there will be a conflict (merge conflict) that might be difficult to resolve.  When then the initial "fix" for this is exclusive <code>checkout</code> functionality...</p>

<hr>

<p>Of course for large projects the chances of a critical merge conflict issue is reduced (people will be working on different parts of the system) so <code>checkout</code>/<code>checkin</code> is not needed nearly as much.  And since distributed systems by design somewhat require good merge functionality, along with many other benefits, that concept doesn't really exist in git and other DVCS</p>

CC BY-SA 3.0
2017-03-01T18:40:04.350Z
That's another way to look at it. Though in my experience I don't think it's a good idea to also add things like "conflicts" and "merging" (if they don't even feel comfortable yet with checkout and checkin).
Pierre.Vriens
CC BY-SA 3.0
2017-03-02T21:06:11.150Z
Fair, I added it because its the main reason that checkout/checkin exists that I could think of.  And feel like grasping a concept is extra difficult if you don't know what that concept is actually useful for.
Thymine
CC BY-SA 3.0
2017-03-01T18:28:24.257Z
2017-03-01T18:28:24.257Z
Thymine
<blockquote>
  <ul>
  <li><strong>Checkout</strong> is an exclusive lock on modifying a branch of object in a repository.</li>
  <li><strong>Checkin</strong> is a release of exclusive lock.</li>
  </ul>
</blockquote>

<p>There are two kinds of source control systems depending on what is the smallest unit of branching.</p>

<p>1) <strong>Per repository</strong> branching (CVS, SVN, GIT, Perforce, ... etc)</p>

<p>In products where you branch the entire repository, <strong>checkout</strong> will usually either create or enable modifications to local branch (copy) of the entire repository. In those products <strong>checkin</strong> is often unused and becomes a part of <strong>commit</strong> operation, which is at once <strong>checkout</strong> of remote branch, applying of local <strong>patch</strong> and <strong>checkin</strong> of remote branch in single operation. You do not <strong>checkin</strong> your local branch as it is permanently checked out. (Note: <em>In GIT you don't commit to remote branch, you push your local commit to it. Strictly syntactic difference.</em>)</p>

<p>2) <strong>Per object</strong> branching (ClearCase, AccuRev, Oracle ADE)</p>

<p>In products where you branch individual objects, like directories, files, etc. The concept of <strong>checkout</strong> and <strong>checkin</strong> applies per object per branch. You will lock the object to modify it with <strong>checkout</strong> and release it with <strong>checkin</strong>. In those products you often work on a private branch where locks do not hold anyone from working and at the time of merge of your local branch into a shared branch, the objects are also <strong>checkedout</strong> on shard branch (main, master, feature branch, etc) conflicts of merge are resolved and object is <strong>checkedin</strong> on the shared branch. This allows multiple people to "commit" at the same time to shared branch as long as they do not modify the same objects.</p>

CC BY-SA 4.0
2018-09-12T21:13:49.573Z
Hey Jiri, merci for your answer. For those 2 kinds you mentioned I would agree. But in the SCM tools in the mainframe world (were my experience originates from) one doesn't take "locking" into consideration ... Can you think of a way to add a 3rd kind to your answer?
Pierre.Vriens
CC BY-SA 4.0
2018-09-12T22:47:15.653Z
Can you give me example of a product that does not fit in those two categories? I can either tell you which of the 2 it fits or add a third, if there really is one. Checkout and checkin are operations on a branch giving and releasing the right to modify it. So partitioning on what a product branches (whole repository or individual objects) is natural for this question. I don't know if there is anything in between, what would it be? Branching of subtrees as in Perforce and Subgit is essentially the first category. Lock is just a different name for an 'exclusive right to'.
Jiri Klouda
CC BY-SA 4.0
2018-09-12T22:58:06.840Z
BTW The library metaphor as mentioned before is really a good one. When you checkout a book, you get an exclusive right to it. You take it home and do with it as you please. Read it or even scribble notes in the margins and nobody else can modify the book, while you have it checked out. Like remove some of its pages or highlight some lines. When you check in the book, people can read it at the library, where the watchful eye of librarian does not allow any modifications (vandalism) or check it out and take it home. It does serialize the changes to that book.
Jiri Klouda
CC BY-SA 4.0
2018-09-13T09:23:52.620Z
To continue the analogy, in a different branch of the library, the same book might be there with different modifications or entirely unaltered or not at all. Someone else can check it out there at the same time (ie checkout is per branch). Now original author works on 2nd edition, a master branch so to speak. He could read  notes from multiple branches, merge them together, checkout the master branch and checkin a 2nd edition. Each branch of library will refresh their copy by buying a 2nd edition. They can discard the 1st or copy still useful notes from margins to the new edition.
Jiri Klouda
CC BY-SA 4.0
2018-09-12T20:42:11.107Z
2018-09-12T20:53:36.873Z
2018-09-12T20:53:36.873Z
Jiri Klouda
<p>To explain something to anybody, try to compare it to something they are (hopefully) familiar with already.</p>
<p>So that's why I just answer such question like so:</p>
<blockquote>
<p>Think of it as arriving at a place to stay (a hotel, a resort, etc):</p>
<ul>
<li>the very <em>first</em> thing you do (when you arrive) is to <strong><code>checkin</code></strong>.</li>
<li>the very <em>last</em> thing you do (when you leave) is to <strong><code>checkout</code></strong>.</li>
</ul>
<p>A similar SCM concept applies when you want to apply changes to software components ...  except that <em><strong>it applies the other way around</strong></em>:</p>
<ul>
<li>the very <em>first</em> thing you do (when you start) is to <strong><code>checkout</code></strong> (or think of it like borrowing it).</li>
<li>the very <em>last</em> thing you do (when you finish) is to <strong><code>checkin</code></strong> (or think of it like giving it back).</li>
</ul>
</blockquote>
<p><strong>Note</strong>: this applies to centralized systems (such as the ones used in mainframe environments ...). In systems such as <a href="/questions/tagged/git" class="post-tag" title="show questions tagged &#39;git&#39;" rel="tag">git</a> the &quot;<em><code>checkout</code></em>&quot; concept has a completely different meaning (which IMO is also why in those systems there is hardly any confusion about both concepts).</p>

CC BY-SA 4.0
2018-09-12T20:49:15.920Z
This is a rather naive, layman answer. I've worked for a decade on internals of source control systems so I've added a bit more in-depth answer to your question.
Jiri Klouda
CC BY-SA 3.0
2017-03-02T10:24:18.327Z
Perhaps the code is more like a library book than a hotel room?
Toby Speight
CC BY-SA 3.0
2017-03-01T18:05:03.893Z
2017-03-01T18:21:29.713Z
2020-06-18T08:28:10.803Z
Pierre.Vriens
<p>When teaching SCM classes to students that are new to Software Configuration Management, it happens that a question comes up like "<strong><code>What's the difference between checkin and checkout?</code></strong>".</p>

<p>And a variation of it is that such students get confused about these SCM concepts (they understand them as the other way around).</p>

<p>So what kind of metaphor can you use to explain this crucial SCM concept to such audience?</p>

CC BY-SA 4.0
2018-09-12T20:27:14.497Z
checkout = lock ; checkin = unlock ; You take exclusive lock to edit the object in question on the branch on which you perform the operation.
Jiri Klouda
<terminology><scm>
What's the difference between checkin and checkout?
Pierre.Vriens
# What's the difference between checkin and checkout?

(Asked by: username_0 on 2017-03-01)

When teaching SCM classes to students that are new to Software Configuration Management, it happens that a question comes up like "**`What's the difference between checkin and checkout?`**".

And a variation of it is that such students get confused about these SCM concepts (they understand them as the other way around).

So what kind of metaphor can you use to explain this crucial SCM concept to such audience?

**Tags:** terminology, scm

> **Comments:**
> **username_1**: checkout = lock ; checkin = unlock ; You take exclusive lock to edit the object in question on the branch on which you perform the operation.  

---

## 5 answers

### Answer by username_0 on 2017-03-01. Score: 8 | Accepted answer

To explain something to anybody, try to compare it to something they are (hopefully) familiar with already.

So that's why I just answer such question like so:

> Think of it as arriving at a place to stay (a hotel, a resort, etc):
>
> * the very *first* thing you do (when you arrive) is to **`checkin`**.
> * the very *last* thing you do (when you leave) is to **`checkout`**.
>
> A similar SCM concept applies when you want to apply changes to software components ... except that ***it applies the other way around***:
>
> * the very *first* thing you do (when you start) is to **`checkout`** (or think of it like borrowing it).
> * the very *last* thing you do (when you finish) is to **`checkin`** (or think of it like giving it back).

**Note**: this applies to centralized systems (such as the ones used in mainframe environments ...). In systems such as [git](/questions/tagged/git "show questions tagged 'git'") the "*`checkout`*" concept has a completely different meaning (which IMO is also why in those systems there is hardly any confusion about both concepts).

> **Comments:**
> **username_5**: Perhaps the code is more like a library book than a hotel room?  
> **username_1**: This is a rather naive, layman answer. I've worked for a decade on internals of source control systems so I've added a bit more in-depth answer to your question.  

---

### Answer by username_2 on 2017-03-01. Score: 6

It's important to note that the terms "checkin" and "checkout" have different meanings depending on the type of SCM system.

Centralized systems like TFVC, Subversion, and Clearcase use "exclusive" checkouts. This is like Pierre's book borrowing metaphor, where only one user can have a file checked out at one time.

Distributed systems like git have a "checkout" command, but it means something completely different. `git checkout` is used to switch between branches when working with a local repository.

> **Comments:**
> **username_0**: Good point Dave about the distributed systems! Actually that's also why myself at first (when I first learned about GIT) was terribly confused. To not invalidate your answer (by adapting my question), I refined my own answer to clarify it a bit.  
> **username_2**: I should clarify: git checkout is used to check out objects from the repository.  That can be a branch, or a single file.  

---

### Answer by username_3 on 2018-09-12. Score: 4

With the *SCM repository* as the main subject then'

* **checkout** is getting changes **out** from the local or remote repository (into your local working directory).
* **checkin** is putting changes back **into** the the local or remote repository (from your local working directory).

> **Comments:**
> **username_0**: Merci for this answer *also*. That's indeed a way to explain it, though I still wonder if you can think of some sort of "metaphor" (as in my question). E.g. to explain it to somebody you'd be teaching, who doesn't even have a clue what a local or remote *repository* really is.  
> **username_3**: True, if they have no clue about what a repository is then trying to teach checkin and checkout will be meaningless. Now, for a metaphor for source control in general you can compare it to financial accounting/bookkeeping. It is fundamentally keeping track of changes to the value of assets. You record either single individual changes or groups of changes (e.g. "Travel from A to B" rather than taxi ticket + bus ticker + train ticket + ...) although not too large groups (e.g. "All expenses on Monday"). Similarly a repository keeps track of source code changes, individual or not too large groups.  

---

### Answer by username_4 on 2017-03-01. Score: 4

For centralized systems, think of it like a technical library. (might be a stretch of the imagination how this hypothetical library functions...)

If you are an author of a document, you might `checkout` the library copy, make changes, return it `check it back in` to the library for the world to see.

This can become an issue if the library has digital copies, and I `checkout` a document, someone else also `checks out` a document, we both make changes, there will be a conflict (merge conflict) that might be difficult to resolve. When then the initial "fix" for this is exclusive `checkout` functionality...

---

Of course for large projects the chances of a critical merge conflict issue is reduced (people will be working on different parts of the system) so `checkout`/`checkin` is not needed nearly as much. And since distributed systems by design somewhat require good merge functionality, along with many other benefits, that concept doesn't really exist in git and other DVCS

> **Comments:**
> **username_0**: That's another way to look at it. Though in my experience I don't think it's a good idea to also add things like "conflicts" and "merging" (if they don't even feel comfortable yet with checkout and checkin).  
> **username_4**: Fair, I added it because its the main reason that checkout/checkin exists that I could think of.  And feel like grasping a concept is extra difficult if you don't know what that concept is actually useful for.  

---

### Answer by username_1 on 2018-09-12. Score: 1

> * **Checkout** is an exclusive lock on modifying a branch of object in a repository.
> * **Checkin** is a release of exclusive lock.

There are two kinds of source control systems depending on what is the smallest unit of branching.

1) **Per repository** branching (CVS, SVN, GIT, Perforce, ... etc)

In products where you branch the entire repository, **checkout** will usually either create or enable modifications to local branch (copy) of the entire repository. In those products **checkin** is often unused and becomes a part of **commit** operation, which is at once **checkout** of remote branch, applying of local **patch** and **checkin** of remote branch in single operation. You do not **checkin** your local branch as it is permanently checked out. (Note: *In GIT you don't commit to remote branch, you push your local commit to it. Strictly syntactic difference.*)

2) **Per object** branching (ClearCase, AccuRev, Oracle ADE)

In products where you branch individual objects, like directories, files, etc. The concept of **checkout** and **checkin** applies per object per branch. You will lock the object to modify it with **checkout** and release it with **checkin**. In those products you often work on a private branch where locks do not hold anyone from working and at the time of merge of your local branch into a shared branch, the objects are also **checkedout** on shard branch (main, master, feature branch, etc) conflicts of merge are resolved and object is **checkedin** on the shared branch. This allows multiple people to "commit" at the same time to shared branch as long as they do not modify the same objects.

> **Comments:**
> **username_0**: Hey Jiri, merci for your answer. For those 2 kinds you mentioned I would agree. But in the SCM tools in the mainframe world (were my experience originates from) one doesn't take "locking" into consideration ... Can you think of a way to add a 3rd kind to your answer?  
> **username_1**: Can you give me example of a product that does not fit in those two categories? I can either tell you which of the 2 it fits or add a third, if there really is one. Checkout and checkin are operations on a branch giving and releasing the right to modify it. So partitioning on what a product branches (whole repository or individual objects) is natural for this question. I don't know if there is anything in between, what would it be? Branching of subtrees as in Perforce and Subgit is essentially the first category. Lock is just a different name for an 'exclusive right to'.  
> **username_1**: BTW The library metaphor as mentioned before is really a good one. When you checkout a book, you get an exclusive right to it. You take it home and do with it as you please. Read it or even scribble notes in the margins and nobody else can modify the book, while you have it checked out. Like remove some of its pages or highlight some lines. When you check in the book, people can read it at the library, where the watchful eye of librarian does not allow any modifications (vandalism) or check it out and take it home. It does serialize the changes to that book.  
> **username_1**: To continue the analogy, in a different branch of the library, the same book might be there with different modifications or entirely unaltered or not at all. Someone else can check it out there at the same time (ie checkout is per branch). Now original author works on 2nd edition, a master branch so to speak. He could read  notes from multiple branches, merge them together, checkout the master branch and checkin a 2nd edition. Each branch of library will refresh their copy by buying a 2nd edition. They can discard the 1st or copy still useful notes from margins to the new edition.  

---

