In Postman, what does forking a shared collection give you that duplicating it does not?
answer
- Both copies start identical
- One of them remembers its origin
- The relationship is what makes review possible
- The merge is decided in their account
- Borrowed vocabulary, not a repository operation
basics
~20 sA Postman fork keeps a recorded link back to the collection it came from, so later work can be offered back and merged through a review held in the vendor's account. A duplicate is an orphan.
solid answer
~40 sForking makes your own copy of a shared collection in a space you control, and the vendor records where that copy came from. The recorded origin is the whole difference: it is what makes offering the work back a supported motion, reviewed and accepted on their side by whoever holds the source, rather than a copy-and-paste. Duplicating produces an unrelated collection — identical on day one, unrelated afterwards, with nothing to say later which of the two moved. Note the boundary out loud: the vocabulary is borrowed from version control but this is not a version-control operation. No remote, no branch, no commit; and a merge accepted on the vendor's side leaves your repository and your build with nothing to react to.
go deeper
Recall that both start as the same content, and only one of them keeps a record of where it came from. That record is what a later merge relies on.
Explain the mechanics: the origin is held by the vendor, the merge is reviewed in their account by whoever holds the source, and your repository observes none of it.
Demonstrate operating judgment about drift: keep forks short-lived, name the owner who carries an accepted merge back, and refuse a second review path over a document your repository already holds.
Own the question of which system holds the reviewable truth for shared request definitions, and what it costs the organisation when review lives where audit and automation cannot reach.
## What a fork is in this setting A **fork** here is a copy of a shared collection made into a workspace you control, created through the vendor's application, with the vendor recording that the new copy came from the old one. Every part of that arrangement lives in their account: the copy, the record of its origin, and the mechanism by which work on the copy can later be offered back to the source. None of it touches your repository, and none of it produces anything your build can observe. ## The recorded link is the whole point On the day it is made, a fork and a duplicate hold the same content. What differs is the relationship the vendor keeps: - A **duplicate** is an unrelated collection from the moment it exists. Nothing records that it began as somebody else's document, so nothing can later tell you which of the two moved, or where they last agreed. - A **fork** carries its origin, which lets the application treat source and copy as two states of one document rather than as two documents. - That relationship is what turns *offering the work back* into a reviewable motion instead of a person pasting requests from one window into another. - The link records where the copy came from. It does not promise the copy stays equal to the source, and it does not stop either side moving independently. ## Where a merge back is decided A merge back is reviewed and accepted in the vendor's account, by whoever holds rights over the source there. That produces a set of consequences a middle engineer is expected to name: - the reviewer set is the source workspace's, not your repository's, and the two lists are maintained separately; - an accepted change lands in the source at once for everyone who opens it next, with no commit anywhere on your side; - your required reviews and required checks apply to none of it, because nothing was ever proposed to your repository; - if the collection also exists as a file you keep, that file has not been updated by the merge, and nothing will announce that it is now behind. ## Duplicate against fork | | Duplicate | Fork | |---|---|---| | Origin recorded | no | yes, by the vendor | | Offering work back | paste it in by hand | a review step in their account | | Who decides it lands | whoever may edit the target | whoever holds the source | | Visible to your repository | no | no | | Detecting divergence later | nothing to compare against | the source is at least identified | ## The vocabulary trap The words are borrowed from version control and the mechanics are not. There is no remote here, no branch, no commit, no shared object history, and no rebase-against-merge decision to make — those belong to your version-control system and are a different subject with its own answer. Two things follow. First, a candidate who answers this question by explaining upstream remotes has answered a different question, and a good interviewer will say so. Second, and more practically, an accepted merge gives your pipeline nothing to react to: no push happened, so no build ran, so nobody was told. ## When to reach for it, and when not to 1. **Use a fork when the workspace is genuinely the collection's home** and people who may not edit the source need a way to propose changes to it. 2. **Use it for short-lived work.** The longer a fork lives, the more the source moves underneath it, and reconciling two documents that have both moved is manual work that nobody has scheduled. 3. **Do not adopt it as the review system for something your repository also holds.** You would then have two review paths with two quorums over one subject, and the one that leaves a record is not the one people used. 4. **Decide up front who carries an accepted merge back into the repository copy**, if one exists. Unowned, that step is skipped, and the file in your repository quietly becomes fiction. The honest summary for an interview is that the fork gives you a relationship, and the relationship buys exactly one thing: a supported way to offer changes back with someone reviewing them. Everything else — history you can search, a gate that can refuse a change, a record your auditors can read, a notification when something breaks — remains with whichever system actually owns the document, and if that system is the vendor's account, then it is their record, their reviewers and their interface, not yours.
- Your fork has diverged from its source for weeks. Why is that worse here than a long-lived branch?Because reconciliation is human. There is no build watching either side, no check that fails when they part, and no notification when the source moves. A long-lived fork is discovered rather than reported, usually by whoever opens it next and finds requests that no longer match the service.
- If a merge is accepted on the vendor's side, what does your build see?Nothing. No push occurred in your repository, so no pipeline ran and nobody was told. If a checked-in copy of the same collection exists, it is now behind and silently so. Somebody has to own the step that carries the accepted result back, or that file stops describing reality.
A duplicate is a photocopy: identical, and from then on it has no idea where it came from. A fork is a photocopy that remembers which cabinet it was taken from, which is what lets you hand your edits back to whoever owns that cabinet.
saying these in an interview costs you the question
- Answering with git remotes, upstream and rebase mechanics
- Claiming a fork stays synchronised with its source automatically
- Believing a duplicate can be merged back like a fork
- Expecting your repository reviewers to approve the merge
- Assuming an accepted merge triggers your build