***
title: Fork collections and environments in Postman
updated: 2025-03-24T00:00:00.000Z
max-toc-depth: 2
----------------
A *fork* is a new instance of an element. When you modify a fork, its parent element remains unchanged. In Postman, you can fork collections and environments. Forking enables you to contribute to an element without having [Editor access](/docs/administration/roles-and-permissions/#element-based-roles) for that element.
## Create a fork
To fork an element within a public workspace, you must make your profile public in Postman [Settings](https://go.postman.co/settings/me/). For more information, see [Making your profile public](/docs/getting-started/installation/postman-profile/#make-your-profile-public).
When you fork a collection or an environment, you create a copy of it in a different workspace. You must sign in to Postman to create a fork.
To fork an element, do the following:
1. Select the element in the sidebar.
2. Select 
**Fork** in the upper right.
You can also create a fork by hovering over the element in the sidebar and selecting 
**View more actions** next to its name, then selecting **Fork**.
3. Enter a label for your fork, and select a workspace to save it to.
4. (Optional) If you are forking a collection, you can select one or more environments to include with the fork.
5. Select **Fork Collection** or **Fork Environment**.
Postman creates your fork in the selected workspace.
If there are any [mocks](/docs/design-apis/mock-apis/set-up-mock-servers/) or [monitors](/docs/monitoring-your-api/intro-monitors/) associated with the parent element, they aren't linked to the forked element. You must create mocks and monitors specifically for the fork if you need them.
If a collection is in a public workspace that you haven't been added to, you won't be able to send a request within that workspace. To send requests or make changes to a collection, you must fork the collection into an internal workspace that belongs to you.
## Edit a fork's name or label
To change a forked element's name or label, do the following:
1. Select the fork in the sidebar.
2. In the tab labeled with the names of the parent element and the fork, select the fork's name.
3. Edit the fork's name.
4. Select anywhere outside the name or label to save your changes.
## View fork information
Fork information shows details about forks and the users who have created them. You will be able to identify the users who are actively consuming and contributing to your APIs.
To view a list of users who have forked a collection or environment, select the number next to **Fork**.
To access the list of forks for a collection or environment, do the following:
1. Select **Forks** in the right sidebar.
2. Select the fork name.
You can also select the user's avatar under **Forks** to view the user's public profile.
## Pull updates from a parent element
Forked multi-protocol collections don't support pulling updates, merging changes, or resolving conflicts.
You can pull updates from a parent element into a fork without going through the [pull request process](/docs/collaborating-in-postman/using-version-control/creating-pull-requests/).
1. Hover over the fork in the sidebar.
2. Select **View more actions** next to its name.
3. Select **Pull changes**.
4. Review the diff and select **Pull changes**.
To pull updates from a parent element during the pull request process, see [Pulling updates during a pull request](/docs/collaborating-in-postman/using-version-control/reviewing-pull-requests/#pull-updates-during-a-pull-request).
## Merge changes from a fork
If you have Editor access on the element, you can *merge* a fork into the parent element without going through the [pull request process](/docs/collaborating-in-postman/using-version-control/creating-pull-requests/). For example, if you're using forks to organize the work in your workspace, you can merge changes in a fork directly back into the parent element. If you're collaborating with others, merging directly lacks the safeguards built into the pull request process. Many teams require pull requests as part of their [version control workflow](/docs/collaborating-in-postman/using-version-control/creating-pull-requests/).
To merge changes from a fork without opening a pull request, do the following:
1. Hover over the fork in the sidebar.
2. Select **View more actions** next to its name.
3. Select **Merge changes**.
4. Review the diff and select **Merge All Changes**.
5. Select one of the following merge options:
* **Merge changes** - Merge the changes into the parent element. This doesn't make any changes to the fork. You must have Editor access to the parent element.
* **Merge changes and update source** - Merge the changes into the parent element. Any differences in the parent element are also made to the fork. You must have Editor access to both the parent and forked elements.
* **Merge changes and delete source** - Merge the changes into the parent element. After the merge process is complete, Postman deletes the fork. You must have Editor access to both the parent and forked elements.
6. Select **Merge**.
To merge changes during the pull request process, see [Merge changes from a pull request](/docs/collaborating-in-postman/using-version-control/reviewing-pull-requests/#merge-changes-from-a-pull-request).
## Resolve conflicts from a fork
A merge conflict happens when you try to merge changes into an updated parent element and Postman isn't able to automatically resolve the differences between the two. If there's a conflict when you try to merge a fork, you'll need to decide how you want to resolve it before continuing.
Merge conflicts can involve changes in more than one workspace.
To resolve a merge conflict from a fork, do the following:
1. Begin the merge process described in [Merge changes from a fork](#merge-changes-from-a-fork).
2. Select **Pull the changes** for any conflict.
3. For each conflict, choose the version you want to include when you merge. Select **Keep Source** to keep the change on the parent element. Select **Keep Destination** to keep the change on your fork. You can also select the version you want to keep for each conflict.
To keep all changes on your fork, select **Keep all changes to source**. To keep all changes on the parent element, select **Keep all changes to destination**.
After you resolve the conflicts, select **Pull changes** to [pull the updates](#pull-updates-from-a-parent-element).