ℹ️ Skipped - page is already crawled
| Filter | Status | Condition | Details |
|---|---|---|---|
| HTTP status | PASS | download_http_code = 200 | HTTP 200 |
| Age cutoff | PASS | download_stamp > now() - 6 MONTH | 0.3 months ago |
| History drop | PASS | isNull(history_drop_reason) | No drop reason |
| Spam/ban | PASS | fh_dont_index != 1 AND ml_spam_score = 0 | ml_spam_score=0 |
| Canonical | PASS | meta_canonical IS NULL OR = '' OR = src_unparsed | Not set |
| Property | Value |
|---|---|
| URL | https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html |
| Last Crawled | 2026-03-30 15:42:07 (8 days ago) |
| First Indexed | 2019-06-29 11:46:21 (6 years ago) |
| HTTP Status Code | 200 |
| Meta Title | Merge, rebase, or cherry-pick to apply changes | WebStorm Documentation |
| Meta Description | null |
| Meta Canonical | null |
| Boilerpipe Text | Last modified: 18 March 2026
In Git, there are several ways to integrate changes from one branch into another:
Merge branches
Rebase branches
Cherry-pick separate commits
Apply separate changes from a commit
Apply specific file to a branch
Merge branches
Suppose you have created a feature branch to work on a specific task, and want to integrate the results of your work (
F1
,
F2
,
F3
) into the main code base after you have completed and tested your feature:
main
feature
C1
C2
C3
F1
F2
F3
Merging
your branch into
main
is the most common way to do this.
It is very common that while you are working in your feature branch, your teammates continue to commit their work (
C4
,
C5
) to
main
:
main
feature
C1
C2
C3
F1
F2
F3
C4
C5
When you
merge
your feature branch into
main
, the changes from your feature branch are integrated into the HEAD of the target branch:
main
feature
C1
C2
C3
F1
F2
F3
C4
C5
Git creates a new commit that is referred to as a merge commit that results from combining the changes from your feature branch and
main
from the point where the two branches diverged.
The major benefit of merging is full traceability, as commits merged into the
main
code base preserve their original hash and author, and all commits that are part of one feature can be grouped together.
This workflow is good for projects where committing changes to the
main
code base involves
pull
or
merge requests
, or a hierarchical approval procedure, as existing branches are not changed in any way.
The main drawback of this approach is that extraneous merge commits are created each time you need to incorporate changes, which intensely pollutes project history and makes it difficult to read.
Merge branches
In the
Branches
popup (main menu
Git | Branches
) or in the
Branches
pane of the
Git
tool window, select the target branch that you want to integrate the changes to, and choose
Checkout
from the context menu to switch to that branch.
Do one of the following:
If you do not need to specify options for the merge, select the branch that you want to merge into the current branch and choose
Merge <branch_name> into <target_branch>
from the submenu.
If you need to specify merge options, from the main menu choose
Git | Merge
to open the
Merge
dialog:
Select the branch that you want to merge into the current branch, click
Modify options
and choose from the following:
--no-ff
: a merge commit will be created in all cases, even if the merge could be resolved as a fast-forward.
--ff-only
: the merge will be resolved only if it is possible to fast-forward.
--squash
: a single commit with all pulled changes will be created on top of the current branch.
-m
: you will be able to edit the message for the merge commit.
--no-commit
: a merge will be performed, but a merge commit will not be created so that you can inspect the result of the merge before committing.
--no-verify
: performs the merge while bypassing the pre-merge and commit-message hooks that normally run by default.
--allow-unrelated-histories
: performs a merge, overriding the safety rule that refuses to merge histories without a common ancestor.
Click
Merge
.
If your working tree is clean (which means you have no uncommitted changes), and no conflicts occur between your feature branch and the target branch, Git will merge the two branches, and the merge commit will appear in the
Log
tab of the
Git
tool window
Alt
0
9
:
If conflicts occur between your branch and the target branch, you will be prompted to resolve them (refer to
Resolve conflicts
). If there are unresolved conflicts left after a merge, the
Merge Conflicts
node will appear in the corresponding changelist in the
Commit
tool window (
Alt
0
0
) with a link to resolve them.
If you have local changes that will be overwritten by merge, WebStorm will suggest performing
Smart merge
. If you select this option, WebStorm will
stash
uncommitted changes, perform merge, and then unstash the changes.
note
You can cancel an unfinished
merge
operation by selecting the
Abort
action from the VCS widget.
Rebase branches (git-rebase)
When you
rebase
a branch onto another branch, you apply the commits from the first branch on top of the HEAD commit in the second branch.
Suppose you have created a feature branch to work on a specific task and make several commits to that branch (
F1
,
F2
,
F3
):
main
feature
C1
C2
C3
F1
F2
F3
While you develop in your branch, your teammates continue to commit their work (
C4
,
C5
) to
main
:
main
feature
C1
C2
C3
F1
F2
F3
C4
C5
To integrate the changes made by your teammates (
C4
,
C5
) to your feature branch, you can
rebase
your branch onto
main
. By doing this, you will apply your commits on top of the current HEAD commit in
main
:
main
feature
C1
C2
C3
C4
C5
F1'
F2'
F3'
The major benefit of rebasing is that you get a clean project history that is easy for others to read and understand. Your log does not contain unnecessary merge commits produced by the
merge
operation, and you get linear history that is easy to navigate and search through.
When deciding to adopt this workflow, you should keep in mind, however, that
rebase
rewrites project history as it creates new commits for each commit in the original feature branch (
F1'
instead of
F1
), so they will have different hashes, which obstructs traceability.
Rebase a branch on top of another branch
From the main menu select
Git | Rebase
From the list, select the target branch onto which you want to rebase the current branch:
If you need to rebase the source branch starting from a particular commit instead of rebasing the entire branch, click
Modify options
and choose
--onto
.
In the source branch field, enter the hash of the commit starting from which you want to apply the current branch to the new base:
tip
To copy a commit hash, select it in the
Log
, right-click it and choose
Copy Revision Number
.
If the branch you want to rebase is not currently checked out, click
Modify options
, click
Select another branch to rebase
, and choose a branch from the list that appears:
WebStorm will check out this branch before starting the rebase operation.
Depending on your particular case, choose other options from the
Modify options
list:
--rebase-merges
: preserve the branching structure within the commits that are to be rebased.
Note that any resolved merge conflicts or manual amendments in these merge commits will have to be resolved or reapplied manually.
--keep-empty
: keep empty commits, which are commits that do not change anything from their parent.
--root
: rebase all commits reachable in the branch.
--update-refs
: automatically force-update any branches that point to commits that are being rebased.
--autosquash
: automatically squash commits marked for fixup or squash.
tip
For more information on these options, refer to
git-rebase
Click
Rebase
.
note
You can cancel an unfinished
rebase
operation or resume an interrupted rebase by selecting the
Abort
or
Continue
actions respectively from the top of the VCS widget.
If you do not need to specify options for the rebase, you can initiate a rebase without invoking the rebase dialog. In the
Branches
popup or in the
Branches pane
of the
Git
tool window select a branch and choose one of the following actions:
Checkout and Rebase onto <current_branch_name>
(for both remote and local branches) to check out the selected branch and rebase it on top of the branch that is currently checked out. If the remote branch doesn't exist locally, WebStorm will silently create a tracked local branch, checkout into it and rebase.
Rebase <current_branch_name> onto <selected_branch_name>
(for both remote and local branches) to rebase the branch that is currently checked out on top of the selected.
Pull into <current_branch_name> Using Rebase
(for remote branches) to
fetch
changes from the selected branch and rebase the current branch on top of these changes.
Watch this video to get a better view on how rebase operation can be performed:
Edit Git history by performing interactive rebase
With Git integration in WebStorm, you can edit history for the sake of making it linear and meaningful by performing
interactive rebase
. This allows you to clean up the history of commits by altering individual commits, changing their order, squashing commits into one, skipping commits that contain extraneous changes, and so on before you integrate changes from your feature branch to another branch.
Edit the history of the current branch
WebStorm allows you to edit the commits history in the current branch before you apply the changes to a different branch.
note
Open the
Git
tool window
Alt
0
9
and switch to the
Log
tab.
Filter the log so that it only displays commits from the current branch:
Select the oldest commit in the series of commits that you want to edit, right-click it and choose
Interactively Rebase from Here
.
The
Interactive Rebase
dialog will be displayed containing the list of all commits in the current branch that were made after the selected commit:
If the
Interactively Rebase from Here
option is disabled, this may be due to one of the following reasons:
the selected commit has several parents
the selected commit is not in the current branch
the selected commit is pushed to a
protected branch
To identify the reason, hover over the action in the context menu and look for the message in the status bar:
tip
To view the reason, right-click in the lower-right corner of the navigation bar to open the context menu and make sure that the
Status Text
widget is enabled.
You can perform the following changes to the branch history:
Change the order
in which commits should be applied: use the
and
buttons to move commits up and down the list.
Pick a commit
: this is the default state for all commits. If you need to undo an action you've already taken on a commit, click
Pick
so that this commit is applied as is.
Edit
: click
Stop to Edit
so that when you start the rebase, you stop at this commit to be able to edit it.
When rebase is stopped at a commit, a notification pops up in the bottom-right corner of the WebStorm window letting you continue or abort the rebase:
You can modify this commit using the context actions (such as
Revert
,
Undo
,
Amend
, and so on before continuing the rebase. If you do not perform any actions, this commit will be applied as is.
If you've closed the notification, from the main menu choose
Git | Continue rebase
to resume it.
Reword the commit message
: click
Reword
or double-click a commit and edit the text in the mini-editor that opens.
Combine two commits into one
: select the commit you want to meld into the previous one and click
Squash
or the arrow next to the
Squash
button and then
Fixup
.
If you click
Squash
, by default the messages from the two commits will be combined, so if you do not modify the resulting commit message, this action will be reflected in the branch history.
If you click
Fixup
, the commit message of the fixup commit will be discarded, so this change will be invisible in the branch history.
In both cases, you will be able to edit the commit message in the mini editor that opens when you apply one of these actions.
tip
Ignore a commit
: click
Drop
so that the changes from the selected commit are not applied.
Undo all changes
: click
Reset
to discard all actions you've applied to the commits.
As a result, the
Rebasing Commits
dialog shows a graph illustrating all actions you've applied to commits in your branch so that you can review them before starting the rebase:
Click
Start Rebasing
.
Edit a branch history and integrate it into another branch
WebStorm allows you to
rebase
a branch on top of another branch and edit the source branch history before you apply the changes.
From the main menu select
Git | Rebase
Click
Modify options
and choose
--interactive
.
From the list, select the target branch onto which you want to rebase the current branch:
If you need to rebase the source branch starting from a particular commit instead of rebasing the entire branch, click
Modify options
and choose
--onto
.
In the source branch field, enter the hash of the commit starting from which you want to apply the current branch to the new base:
tip
To copy a commit hash, select it in the
Log
, right-click it and choose
Copy Revision Number
.
If the branch you want to rebase is not currently checked out, click
Modify options
, click
Select another branch to rebase
, and choose a branch from the list that appears:
WebStorm will check out this branch before starting the rebase operation.
Depending on your particular case, choose other options from the
Modify options
list:
--rebase-merges
: preserve the branching structure within the commits that are to be rebased.
Note that any resolved merge conflicts or manual amendments in these merge commits will have to be resolved or reapplied manually.
--keep-empty
: keep empty commits, which are commits that do not change anything from their parent.
--root
: rebase all commits reachable in the branch.
--update-refs
: automatically force-update any branches that point to commits that are being rebased.
--autosquash
: automatically squash commits marked for fixup or squash.
tip
For more information on these options, refer to
git-rebase
Click
Rebase
.
The
Interactive Rebase
dialog will be displayed containing the list of all commits in the current branch that were made after the selected commit.
You can perform the following changes to the branch history:
Change the order
in which commits should be applied: use the
and
buttons to move commits up and down the list.
Pick a commit
: this is the default state for all commits. If you need to undo an action you've already taken on a commit, click
Pick
so that this commit is applied as is.
Edit
: click
Stop to Edit
so that when you start the rebase, you stop at this commit to be able to edit it.
When rebase is stopped at a commit, a notification pops up in the bottom-right corner of the WebStorm window letting you continue or abort the rebase:
You can modify this commit using the context actions (such as
Revert
,
Undo
,
Amend
, and so on before continuing the rebase. If you do not perform any actions, this commit will be applied as is.
If you've closed the notification, from the main menu choose
Git | Continue rebase
to resume it.
Reword the commit message
: click
Reword
or double-click a commit and edit the text in the mini-editor that opens.
Combine two commits into one
: select the commit you want to meld into the previous one and click
Squash
or the arrow next to the
Squash
button and then
Fixup
.
If you click
Squash
, by default the messages from the two commits will be combined, so if you do not modify the resulting commit message, this action will be reflected in the branch history.
If you click
Fixup
, the commit message of the fixup commit will be discarded, so this change will be invisible in the branch history.
In both cases, you will be able to edit the commit message in the mini editor that opens when you apply one of these actions.
tip
Ignore a commit
: click
Drop
so that the changes from the selected commit are not applied.
Undo all changes
: click
Reset
to discard all actions you've applied to the commits.
As a result, the
Rebasing Commits
dialog shows a graph illustrating all actions you've applied to commits in your branch so that you can review them before starting the rebase:
Click
Start Rebasing
.
Cherry-pick separate commits
Sometimes you only need to apply a single commit to a different branch instead of rebasing or merging an entire branch. This may be useful, for example, if you are working in a feature branch and want to integrate a hotfix from
main
that was committed after the two branches have diverged. Or you may want to backport a fix to a previous release branch. You can do so by using the
Cherry-pick
action.
The status bar displays the current state of a cherry-pick operation. You can manage the cherry-pick process using the following actions:
Abort: to cancel an ongoing cherry-pick, select
Abort Cherry-Pick
in the VCS widget or click
in the status bar.
Continue: if an ongoing cherry-pick was paused (for example, to resolve conflicts), select
Continue Cherry-Pick
in the VCS widget or click
in the status bar to finish the process.
Apply a commit to another branch
In the
Branches
popup (main menu
Git | Branches
), select the target branch that you want to integrate the changes to and choose
Checkout
from the popup menu to switch to that branch.
Open the
Git
tool window
Alt
0
9
and switch to the
Log
tab.
Locate the commit containing the changes you want to cherry-pick.
You can filter commits by branch, user or date. You can also click
on the toolbar and select
Highlight | Non-Picked Commits
option to grey out the commits that have already been applied to the current branch. If you know the commit hash, or are looking for a tagged commit, you can also use the
Go to Hash / Branch / Tag
action (press
Ctrl
0
F
in the
Log
tab of the
Git
tool window
Alt
0
9
, or click
on the toolbar).
Select the required commit. Use the information in the
Commit Details
area to make sure these are the changes you want to transfer to another branch.
Click
Cherry-pick
on the toolbar. WebStorm will apply and commit changes to the target branch.
If the cherry-pick failed with conflicts, the selected changes will appear in the
Changes
area that you can see in the
Commit
tool window (
Alt
0
0
) . You can review these changes and commit them later if necessary.
If you want WebStorm to create changelists automatically in case of cherry-pick fail, switch on the corresponding setting in
Settings | Version Control | Changelists
.
Push the changes to the target branch.
The following video will help you see how cherry-pick works:
Apply separate changes
Imagine you've made some changes to a file that you want to apply to a different branch, but these changes were committed together with other modified files. WebStorm lets you apply separate changes to a changelist without committing them right away instead of cherry-picking an entire commit.
In the
Branches
popup (main menu
Git | Branches
), select the target branch that you want to integrate the changes to and choose
Checkout
from the popup menu to switch to that branch.
Open the
Git
tool window
Alt
0
9
and switch to the
Log
tab.
Locate the commit that contains the changes that you want to apply.
You can filter commits by branch, user or date. You can also click
on the toolbar and select
Highlight | Non-Picked Commits
option to grey out the commits that have already been applied to the current branch. If you know the commit hash, or are looking for a tagged commit, you can also use the
Go to Hash / Branch / Tag
action (press
Ctrl
0
F
in the
Log
tab of the
Git
tool window
Alt
0
9
, or click
on the toolbar).
In the
Commit details
pane on the right, select the files containing the changes you want to apply to the target branch and select
Cherry-Pick Selected Changes
from the context menu.
In the dialog that opens, select an existing changelist or enter the name for a new changelist and click
OK
.
Commit the changes and then push them to the target branch.
Apply separate files
In addition to applying separate changes to a single file, you can copy an entire file's contents to a different branch. This may be useful, for example, if the file you want to apply doesn't exist in the target branch, or if changes to it were made within several commits.
Switch
to the branch to which the changes will be applied.
In the
Branches
popup (main menu
Git | Branches
) or in the
Branches
pane of the
Git
tool window, select the branch that contains the file you want to apply and choose
Show Diff with Working Tree
from the context menu.
The
Changes
tool window that opens shows a list of all files that are different in the selected branch compared with the branch that is currently checked out:
Files that exist in the selected branch and are missing in the current branch are marked with gray.
Files that exist in the current branch but are missing in the selected branch are marked with green.
Files that contain differences between the selected and the current branch are marked with blue.
You can click the
Swap Branches
link to change which branch is considered as a base against which you are comparing the other branch.
Select the file that you want to apply to the current branch, and choose
Get from Branch
from the context menu or click
on the toolbar.
Commit and push the changes. WebStorm will copy the entire contents of the file to the current branch.
note
You can also apply a file to another branch from the
Project
view: select the folder containing the file you want to copy, and choose
Git | Compare with Branch | <branch_name>
from the context menu, then click the
Get
icon
on the toolbar. |
| Markdown | WebStorm
2026\.1
Shortcuts: Windows
[Get WebStorm](https://www.jetbrains.com/webstorm/download/)
- [Meet WebStorm](https://www.jetbrains.com/help/webstorm/meet-webstorm.html)
- [React](https://www.jetbrains.com/help/webstorm/react.html)
- [JavaScript](https://www.jetbrains.com/help/webstorm/javascript-specific-guidelines.html)
- [TypeScript](https://www.jetbrains.com/help/webstorm/typescript-support.html)
- [Vue.js](https://www.jetbrains.com/help/webstorm/vue-js.html)
- [Style sheets](https://www.jetbrains.com/help/webstorm/style-sheets.html)
- [JavaScript Runtimes](https://www.jetbrains.com/help/webstorm/javascript-runtime.html)
- Frontend build tools
- [AI](https://www.jetbrains.com/help/webstorm/ai.html)
- [Other languages and frameworks](https://www.jetbrains.com/help/webstorm/application-development-guidelines.html)
- [WebStorm projects](https://www.jetbrains.com/help/webstorm/creating-and-managing-projects.html)
- [Write and edit source code](https://www.jetbrains.com/help/webstorm/working-with-source-code.html)
- Run, debug, and test applications
- [Version control](https://www.jetbrains.com/help/webstorm/version-control-integration.html)
- [Git](https://www.jetbrains.com/help/webstorm/using-git-integration.html)
- [Tutorial: Getting started with Git in WebStorm](https://www.jetbrains.com/help/webstorm/working-with-git-tutorial.html)
- [Set up a Git repository](https://www.jetbrains.com/help/webstorm/set-up-a-git-repository.html)
- [Add files to Git and track changes](https://www.jetbrains.com/help/webstorm/adding-files-to-version-control.html)
- [Sync with a remote Git repository (fetch, pull, update)](https://www.jetbrains.com/help/webstorm/sync-with-a-remote-repository.html)
- [Commit and push changes to Git repository](https://www.jetbrains.com/help/webstorm/commit-and-push-changes.html)
- [Merge, rebase, or cherry-pick to apply changes](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html)
- [Manage Git branches](https://www.jetbrains.com/help/webstorm/manage-branches.html)
- [Use Git worktrees](https://www.jetbrains.com/help/webstorm/use-git-worktrees.html)
- [Sign commits with GPG keys](https://www.jetbrains.com/help/webstorm/set-up-GPG-commit-signing.html)
- [Compare file and folder versions using Diff viewer](https://www.jetbrains.com/help/webstorm/comparing-file-versions.html)
- [Investigate changes in Git repository](https://www.jetbrains.com/help/webstorm/investigate-changes.html)
- [Resolve Git conflicts](https://www.jetbrains.com/help/webstorm/resolve-conflicts.html)
- [Group changes into changelists](https://www.jetbrains.com/help/webstorm/managing-changelists.html)
- [Shelve or stash changes](https://www.jetbrains.com/help/webstorm/shelving-and-unshelving-changes.html)
- [Use patches](https://www.jetbrains.com/help/webstorm/using-patches.html)
- [Undo changes in Git repository](https://www.jetbrains.com/help/webstorm/undo-changes.html)
- [Use tags to mark specific Git commits](https://www.jetbrains.com/help/webstorm/use-tags-to-mark-specific-commits.html)
- [Edit Git project history](https://www.jetbrains.com/help/webstorm/edit-project-history.html)
- [Git integration with issue trackers](https://www.jetbrains.com/help/webstorm/handling-issues.html)
- [GitHub](https://www.jetbrains.com/help/webstorm/github.html)
- [GitLab](https://www.jetbrains.com/help/webstorm/gitlab.html)
- [Mercurial](https://www.jetbrains.com/help/webstorm/using-mercurial-integration.html)
- [Perforce](https://www.jetbrains.com/help/webstorm/using-perforce-integration.html)
- [Subversion](https://www.jetbrains.com/help/webstorm/using-subversion-integration.html)
- [Version control integration support](https://www.jetbrains.com/help/webstorm/enabling-version-control.html)
- [Main version control shortcuts](https://www.jetbrains.com/help/webstorm/main-version-control-shortcuts.html)
- [Version control settings](https://www.jetbrains.com/help/webstorm/settings-version-control.html)
- Development environment
- Remote, containerized, and cloud-based development environments
- [Additional tools](https://www.jetbrains.com/help/webstorm/advanced-features.html)
- [Database Tools and SQL](https://www.jetbrains.com/help/webstorm/relational-databases.html)
- Reference
1. [Version control](https://www.jetbrains.com/help/webstorm/version-control-integration.html)
2. [Git](https://www.jetbrains.com/help/webstorm/using-git-integration.html)
3. [Merge, rebase, or cherry-pick to apply changes](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#0)
# Merge, rebase, or cherry-pick to apply changes
Last modified: 18 March 2026
In Git, there are several ways to integrate changes from one branch into another:
- [Merge branches](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#merge)
- [Rebase branches](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#rebase-branch)
- [Cherry-pick separate commits](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#cherry-pick)
- [Apply separate changes from a commit](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#apply-separate-changes)
- [Apply specific file to a branch](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#copy-files-to-branch)
## Merge branches
Suppose you have created a feature branch to work on a specific task, and want to integrate the results of your work (`F1`, `F2`, `F3`) into the main code base after you have completed and tested your feature:
main
feature
C1
C2
C3
F1
F2
F3
Merging your branch into `main` is the most common way to do this.
It is very common that while you are working in your feature branch, your teammates continue to commit their work (`C4`, `C5`) to `main`:
main
feature
C1
C2
C3
F1
F2
F3
C4
C5
When you [merge](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#merge-branches) your feature branch into `main`, the changes from your feature branch are integrated into the HEAD of the target branch:
main
feature
C1
C2
C3
F1
F2
F3
C4
C5
Git creates a new commit that is referred to as a merge commit that results from combining the changes from your feature branch and `main` from the point where the two branches diverged.
The major benefit of merging is full traceability, as commits merged into the `main` code base preserve their original hash and author, and all commits that are part of one feature can be grouped together.
This workflow is good for projects where committing changes to the `main` code base involves [pull](https://www.jetbrains.com/help/webstorm/create-and-merge-github-pull-requests.html#create-pull-request) or [merge requests](https://www.jetbrains.com/help/webstorm/work-with-gitlab-merge-requests.html), or a hierarchical approval procedure, as existing branches are not changed in any way.
The main drawback of this approach is that extraneous merge commits are created each time you need to incorporate changes, which intensely pollutes project history and makes it difficult to read.
### Merge branches
1. In the [Branches](https://www.jetbrains.com/help/webstorm/manage-branches.html) popup (main menu Git \| Branches) or in the Branches pane of the Git tool window, select the target branch that you want to integrate the changes to, and choose Checkout from the context menu to switch to that branch.
2. Do one of the following:
- If you do not need to specify options for the merge, select the branch that you want to merge into the current branch and choose Merge \<branch\_name\> into \<target\_branch\> from the submenu.
- If you need to specify merge options, from the main menu choose Git \| Merge to open the Merge dialog:
Select the branch that you want to merge into the current branch, click Modify options and choose from the following:
- `--no-ff`: a merge commit will be created in all cases, even if the merge could be resolved as a fast-forward.
- `--ff-only`: the merge will be resolved only if it is possible to fast-forward.
- `--squash`: a single commit with all pulled changes will be created on top of the current branch.
- `-m`: you will be able to edit the message for the merge commit.
- `--no-commit`: a merge will be performed, but a merge commit will not be created so that you can inspect the result of the merge before committing.
- `--no-verify`: performs the merge while bypassing the pre-merge and commit-message hooks that normally run by default.
- `--allow-unrelated-histories`: performs a merge, overriding the safety rule that refuses to merge histories without a common ancestor.
Click Merge.
If your working tree is clean (which means you have no uncommitted changes), and no conflicts occur between your feature branch and the target branch, Git will merge the two branches, and the merge commit will appear in the Log tab of the Git tool window `Alt``09`:
If conflicts occur between your branch and the target branch, you will be prompted to resolve them (refer to [Resolve conflicts](https://www.jetbrains.com/help/webstorm/resolve-conflicts.html)). If there are unresolved conflicts left after a merge, the Merge Conflicts node will appear in the corresponding changelist in the Commit tool window (`Alt``00`) with a link to resolve them.
If you have local changes that will be overwritten by merge, WebStorm will suggest performing Smart merge. If you select this option, WebStorm will [stash](https://www.jetbrains.com/help/webstorm/shelving-and-unshelving-changes.html#stash) uncommitted changes, perform merge, and then unstash the changes.
> ### note
> You can cancel an unfinished merge operation by selecting the Abort action from the VCS widget.
## Rebase branches (git-rebase)
When you `rebase` a branch onto another branch, you apply the commits from the first branch on top of the HEAD commit in the second branch.
Suppose you have created a feature branch to work on a specific task and make several commits to that branch (`F1`, `F2`, `F3`):
main
feature
C1
C2
C3
F1
F2
F3
While you develop in your branch, your teammates continue to commit their work (`C4`, `C5`) to `main`:
main
feature
C1
C2
C3
F1
F2
F3
C4
C5
To integrate the changes made by your teammates (`C4`, `C5`) to your feature branch, you can [rebase](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#rebase-branch-onto-another-branch) your branch onto `main`. By doing this, you will apply your commits on top of the current HEAD commit in `main`:
main
feature
C1
C2
C3
C4
C5
F1'
F2'
F3'
The major benefit of rebasing is that you get a clean project history that is easy for others to read and understand. Your log does not contain unnecessary merge commits produced by the `merge` operation, and you get linear history that is easy to navigate and search through.
When deciding to adopt this workflow, you should keep in mind, however, that `rebase` rewrites project history as it creates new commits for each commit in the original feature branch (`F1'` instead of `F1`), so they will have different hashes, which obstructs traceability.
### Rebase a branch on top of another branch
1. From the main menu select Git \| Rebase
2. From the list, select the target branch onto which you want to rebase the current branch:
3. If you need to rebase the source branch starting from a particular commit instead of rebasing the entire branch, click Modify options and choose \--onto.
In the source branch field, enter the hash of the commit starting from which you want to apply the current branch to the new base:
> ### tip
> To copy a commit hash, select it in the Log, right-click it and choose Copy Revision Number.
4. If the branch you want to rebase is not currently checked out, click Modify options, click Select another branch to rebase, and choose a branch from the list that appears:
WebStorm will check out this branch before starting the rebase operation.
5. Depending on your particular case, choose other options from the Modify options list:
- `--rebase-merges`: preserve the branching structure within the commits that are to be rebased.
Note that any resolved merge conflicts or manual amendments in these merge commits will have to be resolved or reapplied manually.
- `--keep-empty`: keep empty commits, which are commits that do not change anything from their parent.
- `--root`: rebase all commits reachable in the branch.
- `--update-refs`: automatically force-update any branches that point to commits that are being rebased.
- `--autosquash`: automatically squash commits marked for fixup or squash.
> ### tip
> For more information on these options, refer to [git-rebase](https://git-scm.com/docs/git-rebase)
6. Click Rebase.
> ### note
> You can cancel an unfinished rebase operation or resume an interrupted rebase by selecting the Abort or Continue actions respectively from the top of the VCS widget.
If you do not need to specify options for the rebase, you can initiate a rebase without invoking the rebase dialog. In the Branches popup or in the [Branches pane](https://www.jetbrains.com/help/webstorm/log-tab.html#branches_pane_context_menu) of the [Git](https://www.jetbrains.com/help/webstorm/version-control-tool-window.html) tool window select a branch and choose one of the following actions:
- Checkout and Rebase onto \<current\_branch\_name\> (for both remote and local branches) to check out the selected branch and rebase it on top of the branch that is currently checked out. If the remote branch doesn't exist locally, WebStorm will silently create a tracked local branch, checkout into it and rebase.
- Rebase \<current\_branch\_name\> onto \<selected\_branch\_name\> (for both remote and local branches) to rebase the branch that is currently checked out on top of the selected.
- Pull into \<current\_branch\_name\> Using Rebase (for remote branches) to [fetch](https://www.jetbrains.com/help/webstorm/sync-with-a-remote-repository.html#fetch) changes from the selected branch and rebase the current branch on top of these changes.
Watch this video to get a better view on how rebase operation can be performed:
### Edit Git history by performing interactive rebase
With Git integration in WebStorm, you can edit history for the sake of making it linear and meaningful by performing interactive rebase. This allows you to clean up the history of commits by altering individual commits, changing their order, squashing commits into one, skipping commits that contain extraneous changes, and so on before you integrate changes from your feature branch to another branch.
### Edit the history of the current branch
WebStorm allows you to edit the commits history in the current branch before you apply the changes to a different branch.
> ### note
> If you want to use advanced rebase options such as `-autosquash`, `--root`, or `--update-refs`, refer to [Edit a branch history and integrate it into another branch](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#interactive-rebase-onto-branch).
1. Open the Git tool window `Alt``09` and switch to the Log tab.
2. Filter the log so that it only displays commits from the current branch:
3. Select the oldest commit in the series of commits that you want to edit, right-click it and choose Interactively Rebase from Here.
The Interactive Rebase dialog will be displayed containing the list of all commits in the current branch that were made after the selected commit:
If the Interactively Rebase from Here option is disabled, this may be due to one of the following reasons:
- the selected commit has several parents
- the selected commit is not in the current branch
- the selected commit is pushed to a [protected branch](https://www.jetbrains.com/help/webstorm/edit-project-history.html#protected-branch)
To identify the reason, hover over the action in the context menu and look for the message in the status bar:
> ### tip
> To view the reason, right-click in the lower-right corner of the navigation bar to open the context menu and make sure that the Status Text widget is enabled.
4. You can perform the following changes to the branch history:
- Change the order in which commits should be applied: use the  and  buttons to move commits up and down the list.
- Pick a commit: this is the default state for all commits. If you need to undo an action you've already taken on a commit, click Pick  so that this commit is applied as is.
- Edit: click Stop to Edit  so that when you start the rebase, you stop at this commit to be able to edit it.
When rebase is stopped at a commit, a notification pops up in the bottom-right corner of the WebStorm window letting you continue or abort the rebase:
You can modify this commit using the context actions (such as Revert, Undo, Amend, and so on before continuing the rebase. If you do not perform any actions, this commit will be applied as is.
If you've closed the notification, from the main menu choose Git \| Continue rebase to resume it.
- Reword the commit message: click Reword or double-click a commit and edit the text in the mini-editor that opens.
- Combine two commits into one: select the commit you want to meld into the previous one and click Squash or the arrow next to the Squash button and then Fixup.
If you click Squash, by default the messages from the two commits will be combined, so if you do not modify the resulting commit message, this action will be reflected in the branch history.
If you click Fixup, the commit message of the fixup commit will be discarded, so this change will be invisible in the branch history.
In both cases, you will be able to edit the commit message in the mini editor that opens when you apply one of these actions.
> ### tip
> Note that automatic processing of `fixup!` and `squash!` commits is affected by `rebase.autoSquash` [Git config setting](https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---autosquash).
>
> If you want to use `--autosquash` for this particular rebase without changing Git config, refer to [Edit a branch history and integrate it into another branch](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#interactive-rebase-onto-branch).
- Ignore a commit: click Drop so that the changes from the selected commit are not applied.
- Undo all changes: click Reset to discard all actions you've applied to the commits.
As a result, the Rebasing Commits dialog shows a graph illustrating all actions you've applied to commits in your branch so that you can review them before starting the rebase:
5. Click Start Rebasing.
### Edit a branch history and integrate it into another branch
WebStorm allows you to [rebase](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#rebase-branch) a branch on top of another branch and edit the source branch history before you apply the changes.
1. From the main menu select Git \| Rebase
2. Click Modify options and choose \--interactive.
3. From the list, select the target branch onto which you want to rebase the current branch:
4. If you need to rebase the source branch starting from a particular commit instead of rebasing the entire branch, click Modify options and choose \--onto.
In the source branch field, enter the hash of the commit starting from which you want to apply the current branch to the new base:
> ### tip
> To copy a commit hash, select it in the Log, right-click it and choose Copy Revision Number.
5. If the branch you want to rebase is not currently checked out, click Modify options, click Select another branch to rebase, and choose a branch from the list that appears:
WebStorm will check out this branch before starting the rebase operation.
6. Depending on your particular case, choose other options from the Modify options list:
- `--rebase-merges`: preserve the branching structure within the commits that are to be rebased.
Note that any resolved merge conflicts or manual amendments in these merge commits will have to be resolved or reapplied manually.
- `--keep-empty`: keep empty commits, which are commits that do not change anything from their parent.
- `--root`: rebase all commits reachable in the branch.
- `--update-refs`: automatically force-update any branches that point to commits that are being rebased.
- `--autosquash`: automatically squash commits marked for fixup or squash.
> ### tip
> For more information on these options, refer to [git-rebase](https://git-scm.com/docs/git-rebase)
7. Click Rebase.
The Interactive Rebase dialog will be displayed containing the list of all commits in the current branch that were made after the selected commit.
8. You can perform the following changes to the branch history:
- Change the order in which commits should be applied: use the  and  buttons to move commits up and down the list.
- Pick a commit: this is the default state for all commits. If you need to undo an action you've already taken on a commit, click Pick  so that this commit is applied as is.
- Edit: click Stop to Edit  so that when you start the rebase, you stop at this commit to be able to edit it.
When rebase is stopped at a commit, a notification pops up in the bottom-right corner of the WebStorm window letting you continue or abort the rebase:
You can modify this commit using the context actions (such as Revert, Undo, Amend, and so on before continuing the rebase. If you do not perform any actions, this commit will be applied as is.
If you've closed the notification, from the main menu choose Git \| Continue rebase to resume it.
- Reword the commit message: click Reword or double-click a commit and edit the text in the mini-editor that opens.
- Combine two commits into one: select the commit you want to meld into the previous one and click Squash or the arrow next to the Squash button and then Fixup.
If you click Squash, by default the messages from the two commits will be combined, so if you do not modify the resulting commit message, this action will be reflected in the branch history.
If you click Fixup, the commit message of the fixup commit will be discarded, so this change will be invisible in the branch history.
In both cases, you will be able to edit the commit message in the mini editor that opens when you apply one of these actions.
> ### tip
> Note that automatic processing of `fixup!` and `squash!` commits is affected by `rebase.autoSquash` [Git config setting](https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---autosquash).
>
> If you want to use `--autosquash` for this particular rebase without changing Git config, refer to [Edit a branch history and integrate it into another branch](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#interactive-rebase-onto-branch).
- Ignore a commit: click Drop so that the changes from the selected commit are not applied.
- Undo all changes: click Reset to discard all actions you've applied to the commits.
As a result, the Rebasing Commits dialog shows a graph illustrating all actions you've applied to commits in your branch so that you can review them before starting the rebase:
9. Click Start Rebasing.
## Cherry-pick separate commits
Sometimes you only need to apply a single commit to a different branch instead of rebasing or merging an entire branch. This may be useful, for example, if you are working in a feature branch and want to integrate a hotfix from `main` that was committed after the two branches have diverged. Or you may want to backport a fix to a previous release branch. You can do so by using the Cherry-pick action.
The status bar displays the current state of a cherry-pick operation. You can manage the cherry-pick process using the following actions:
- Abort: to cancel an ongoing cherry-pick, select Abort Cherry-Pick in the VCS widget or click  in the status bar.
- Continue: if an ongoing cherry-pick was paused (for example, to resolve conflicts), select Continue Cherry-Pick in the VCS widget or click  in the status bar to finish the process.
### Apply a commit to another branch
1. In the [Branches](https://www.jetbrains.com/help/webstorm/manage-branches.html) popup (main menu Git \| Branches), select the target branch that you want to integrate the changes to and choose Checkout from the popup menu to switch to that branch.
2. Open the Git tool window `Alt``09` and switch to the Log tab.
3. Locate the commit containing the changes you want to cherry-pick.
You can filter commits by branch, user or date. You can also click  on the toolbar and select Highlight \| Non-Picked Commits option to grey out the commits that have already been applied to the current branch. If you know the commit hash, or are looking for a tagged commit, you can also use the Go to Hash / Branch / Tag action (press `Ctrl``0F` in the Log tab of the Git tool window `Alt``09`, or click  on the toolbar).
4. Select the required commit. Use the information in the Commit Details area to make sure these are the changes you want to transfer to another branch.
5. Click Cherry-pick  on the toolbar. WebStorm will apply and commit changes to the target branch.
6. If the cherry-pick failed with conflicts, the selected changes will appear in the Changes area that you can see in the Commit tool window (`Alt``00`) . You can review these changes and commit them later if necessary.
If you want WebStorm to create changelists automatically in case of cherry-pick fail, switch on the corresponding setting in Settings \| Version Control \| Changelists.
7. Push the changes to the target branch.
The following video will help you see how cherry-pick works:
## Apply separate changes
Imagine you've made some changes to a file that you want to apply to a different branch, but these changes were committed together with other modified files. WebStorm lets you apply separate changes to a changelist without committing them right away instead of cherry-picking an entire commit.
1. In the [Branches](https://www.jetbrains.com/help/webstorm/manage-branches.html) popup (main menu Git \| Branches), select the target branch that you want to integrate the changes to and choose Checkout from the popup menu to switch to that branch.
2. Open the Git tool window `Alt``09` and switch to the Log tab.
3. Locate the commit that contains the changes that you want to apply.
You can filter commits by branch, user or date. You can also click  on the toolbar and select Highlight \| Non-Picked Commits option to grey out the commits that have already been applied to the current branch. If you know the commit hash, or are looking for a tagged commit, you can also use the Go to Hash / Branch / Tag action (press `Ctrl``0F` in the Log tab of the Git tool window `Alt``09`, or click  on the toolbar).
4. In the Commit details pane on the right, select the files containing the changes you want to apply to the target branch and select Cherry-Pick Selected Changes from the context menu.
5. In the dialog that opens, select an existing changelist or enter the name for a new changelist and click OK.
6. Commit the changes and then push them to the target branch.
## Apply separate files
In addition to applying separate changes to a single file, you can copy an entire file's contents to a different branch. This may be useful, for example, if the file you want to apply doesn't exist in the target branch, or if changes to it were made within several commits.
1. [Switch](https://www.jetbrains.com/help/webstorm/manage-branches.html#switch-branches) to the branch to which the changes will be applied.
2. In the [Branches](https://www.jetbrains.com/help/webstorm/manage-branches.html) popup (main menu Git \| Branches) or in the Branches pane of the Git tool window, select the branch that contains the file you want to apply and choose Show Diff with Working Tree from the context menu.
The Changes tool window that opens shows a list of all files that are different in the selected branch compared with the branch that is currently checked out:
- Files that exist in the selected branch and are missing in the current branch are marked with gray.
- Files that exist in the current branch but are missing in the selected branch are marked with green.
- Files that contain differences between the selected and the current branch are marked with blue.
You can click the Swap Branches link to change which branch is considered as a base against which you are comparing the other branch.
3. Select the file that you want to apply to the current branch, and choose Get from Branch from the context menu or click  on the toolbar.
4. Commit and push the changes. WebStorm will copy the entire contents of the file to the current branch.
> ### note
> You can also apply a file to another branch from the Project view: select the folder containing the file you want to copy, and choose Git \| Compare with Branch \| \<branch\_name\> from the context menu, then click the Get icon  on the toolbar.
Thanks for your feedback\!
Was this page helpful?
Yes
No
- [Merge, rebase, or cherry-pick to apply changes](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html)
- [Merge branches](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#merge)
- [Rebase branches (git-rebase)](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#rebase-branch)
- [Cherry-pick separate commits](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#cherry-pick)
- [Apply separate changes](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#apply-separate-changes)
- [Apply separate files](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#copy-files-to-branch)
### See also
#### External Links
- [git-rebase official documentation](https://git-scm.com/docs/git-rebase)
[Commit and push changes to Git repository](https://www.jetbrains.com/help/webstorm/commit-and-push-changes.html)
[Manage Git branches](https://www.jetbrains.com/help/webstorm/manage-branches.html)
- [Privacy & Security](https://www.jetbrains.com/privacy-security/)
- [Terms Of Use](https://www.jetbrains.com/legal/docs/company/useterms/)
- [Trademarks](https://www.jetbrains.com/legal/trademarks/)
- [Legal](https://www.jetbrains.com/legal/#licensing)
Copyright © 2000–2026 JetBrains s.r.o. |
| Readable Markdown | Last modified: 18 March 2026
In Git, there are several ways to integrate changes from one branch into another:
- [Merge branches](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#merge)
- [Rebase branches](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#rebase-branch)
- [Cherry-pick separate commits](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#cherry-pick)
- [Apply separate changes from a commit](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#apply-separate-changes)
- [Apply specific file to a branch](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#copy-files-to-branch)
Merge branches
Suppose you have created a feature branch to work on a specific task, and want to integrate the results of your work (`F1`, `F2`, `F3`) into the main code base after you have completed and tested your feature:
main
feature
C1
C2
C3
F1
F2
F3
Merging your branch into `main` is the most common way to do this.
It is very common that while you are working in your feature branch, your teammates continue to commit their work (`C4`, `C5`) to `main`:
main
feature
C1
C2
C3
F1
F2
F3
C4
C5
When you [merge](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#merge-branches) your feature branch into `main`, the changes from your feature branch are integrated into the HEAD of the target branch:
main
feature
C1
C2
C3
F1
F2
F3
C4
C5
Git creates a new commit that is referred to as a merge commit that results from combining the changes from your feature branch and `main` from the point where the two branches diverged.
The major benefit of merging is full traceability, as commits merged into the `main` code base preserve their original hash and author, and all commits that are part of one feature can be grouped together.
This workflow is good for projects where committing changes to the `main` code base involves [pull](https://www.jetbrains.com/help/webstorm/create-and-merge-github-pull-requests.html#create-pull-request) or [merge requests](https://www.jetbrains.com/help/webstorm/work-with-gitlab-merge-requests.html), or a hierarchical approval procedure, as existing branches are not changed in any way.
The main drawback of this approach is that extraneous merge commits are created each time you need to incorporate changes, which intensely pollutes project history and makes it difficult to read.
Merge branches
1. In the [Branches](https://www.jetbrains.com/help/webstorm/manage-branches.html) popup (main menu Git \| Branches) or in the Branches pane of the Git tool window, select the target branch that you want to integrate the changes to, and choose Checkout from the context menu to switch to that branch.
2. Do one of the following:
- If you do not need to specify options for the merge, select the branch that you want to merge into the current branch and choose Merge \<branch\_name\> into \<target\_branch\> from the submenu.
- If you need to specify merge options, from the main menu choose Git \| Merge to open the Merge dialog:
Select the branch that you want to merge into the current branch, click Modify options and choose from the following:
- `--no-ff`: a merge commit will be created in all cases, even if the merge could be resolved as a fast-forward.
- `--ff-only`: the merge will be resolved only if it is possible to fast-forward.
- `--squash`: a single commit with all pulled changes will be created on top of the current branch.
- `-m`: you will be able to edit the message for the merge commit.
- `--no-commit`: a merge will be performed, but a merge commit will not be created so that you can inspect the result of the merge before committing.
- `--no-verify`: performs the merge while bypassing the pre-merge and commit-message hooks that normally run by default.
- `--allow-unrelated-histories`: performs a merge, overriding the safety rule that refuses to merge histories without a common ancestor.
Click Merge.
If your working tree is clean (which means you have no uncommitted changes), and no conflicts occur between your feature branch and the target branch, Git will merge the two branches, and the merge commit will appear in the Log tab of the Git tool window `Alt``09`:
If conflicts occur between your branch and the target branch, you will be prompted to resolve them (refer to [Resolve conflicts](https://www.jetbrains.com/help/webstorm/resolve-conflicts.html)). If there are unresolved conflicts left after a merge, the Merge Conflicts node will appear in the corresponding changelist in the Commit tool window (`Alt``00`) with a link to resolve them.
If you have local changes that will be overwritten by merge, WebStorm will suggest performing Smart merge. If you select this option, WebStorm will [stash](https://www.jetbrains.com/help/webstorm/shelving-and-unshelving-changes.html#stash) uncommitted changes, perform merge, and then unstash the changes.
> ### note
> You can cancel an unfinished merge operation by selecting the Abort action from the VCS widget.
Rebase branches (git-rebase)
When you `rebase` a branch onto another branch, you apply the commits from the first branch on top of the HEAD commit in the second branch.
Suppose you have created a feature branch to work on a specific task and make several commits to that branch (`F1`, `F2`, `F3`):
main
feature
C1
C2
C3
F1
F2
F3
While you develop in your branch, your teammates continue to commit their work (`C4`, `C5`) to `main`:
main
feature
C1
C2
C3
F1
F2
F3
C4
C5
To integrate the changes made by your teammates (`C4`, `C5`) to your feature branch, you can [rebase](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#rebase-branch-onto-another-branch) your branch onto `main`. By doing this, you will apply your commits on top of the current HEAD commit in `main`:
main
feature
C1
C2
C3
C4
C5
F1'
F2'
F3'
The major benefit of rebasing is that you get a clean project history that is easy for others to read and understand. Your log does not contain unnecessary merge commits produced by the `merge` operation, and you get linear history that is easy to navigate and search through.
When deciding to adopt this workflow, you should keep in mind, however, that `rebase` rewrites project history as it creates new commits for each commit in the original feature branch (`F1'` instead of `F1`), so they will have different hashes, which obstructs traceability.
Rebase a branch on top of another branch
1. From the main menu select Git \| Rebase
2. From the list, select the target branch onto which you want to rebase the current branch:
3. If you need to rebase the source branch starting from a particular commit instead of rebasing the entire branch, click Modify options and choose \--onto.
In the source branch field, enter the hash of the commit starting from which you want to apply the current branch to the new base:
> ### tip
> To copy a commit hash, select it in the Log, right-click it and choose Copy Revision Number.
4. If the branch you want to rebase is not currently checked out, click Modify options, click Select another branch to rebase, and choose a branch from the list that appears:
WebStorm will check out this branch before starting the rebase operation.
5. Depending on your particular case, choose other options from the Modify options list:
- `--rebase-merges`: preserve the branching structure within the commits that are to be rebased.
Note that any resolved merge conflicts or manual amendments in these merge commits will have to be resolved or reapplied manually.
- `--keep-empty`: keep empty commits, which are commits that do not change anything from their parent.
- `--root`: rebase all commits reachable in the branch.
- `--update-refs`: automatically force-update any branches that point to commits that are being rebased.
- `--autosquash`: automatically squash commits marked for fixup or squash.
> ### tip
> For more information on these options, refer to [git-rebase](https://git-scm.com/docs/git-rebase)
6. Click Rebase.
> ### note
> You can cancel an unfinished rebase operation or resume an interrupted rebase by selecting the Abort or Continue actions respectively from the top of the VCS widget.
If you do not need to specify options for the rebase, you can initiate a rebase without invoking the rebase dialog. In the Branches popup or in the [Branches pane](https://www.jetbrains.com/help/webstorm/log-tab.html#branches_pane_context_menu) of the [Git](https://www.jetbrains.com/help/webstorm/version-control-tool-window.html) tool window select a branch and choose one of the following actions:
- Checkout and Rebase onto \<current\_branch\_name\> (for both remote and local branches) to check out the selected branch and rebase it on top of the branch that is currently checked out. If the remote branch doesn't exist locally, WebStorm will silently create a tracked local branch, checkout into it and rebase.
- Rebase \<current\_branch\_name\> onto \<selected\_branch\_name\> (for both remote and local branches) to rebase the branch that is currently checked out on top of the selected.
- Pull into \<current\_branch\_name\> Using Rebase (for remote branches) to [fetch](https://www.jetbrains.com/help/webstorm/sync-with-a-remote-repository.html#fetch) changes from the selected branch and rebase the current branch on top of these changes.
Watch this video to get a better view on how rebase operation can be performed:
Edit Git history by performing interactive rebase
With Git integration in WebStorm, you can edit history for the sake of making it linear and meaningful by performing interactive rebase. This allows you to clean up the history of commits by altering individual commits, changing their order, squashing commits into one, skipping commits that contain extraneous changes, and so on before you integrate changes from your feature branch to another branch.
Edit the history of the current branch
WebStorm allows you to edit the commits history in the current branch before you apply the changes to a different branch.
> ### note
1. Open the Git tool window `Alt``09` and switch to the Log tab.
2. Filter the log so that it only displays commits from the current branch:
3. Select the oldest commit in the series of commits that you want to edit, right-click it and choose Interactively Rebase from Here.
The Interactive Rebase dialog will be displayed containing the list of all commits in the current branch that were made after the selected commit:
If the Interactively Rebase from Here option is disabled, this may be due to one of the following reasons:
- the selected commit has several parents
- the selected commit is not in the current branch
- the selected commit is pushed to a [protected branch](https://www.jetbrains.com/help/webstorm/edit-project-history.html#protected-branch)
To identify the reason, hover over the action in the context menu and look for the message in the status bar:
> ### tip
> To view the reason, right-click in the lower-right corner of the navigation bar to open the context menu and make sure that the Status Text widget is enabled.
4. You can perform the following changes to the branch history:
- Change the order in which commits should be applied: use the  and  buttons to move commits up and down the list.
- Pick a commit: this is the default state for all commits. If you need to undo an action you've already taken on a commit, click Pick  so that this commit is applied as is.
- Edit: click Stop to Edit  so that when you start the rebase, you stop at this commit to be able to edit it.
When rebase is stopped at a commit, a notification pops up in the bottom-right corner of the WebStorm window letting you continue or abort the rebase:
You can modify this commit using the context actions (such as Revert, Undo, Amend, and so on before continuing the rebase. If you do not perform any actions, this commit will be applied as is.
If you've closed the notification, from the main menu choose Git \| Continue rebase to resume it.
- Reword the commit message: click Reword or double-click a commit and edit the text in the mini-editor that opens.
- Combine two commits into one: select the commit you want to meld into the previous one and click Squash or the arrow next to the Squash button and then Fixup.
If you click Squash, by default the messages from the two commits will be combined, so if you do not modify the resulting commit message, this action will be reflected in the branch history.
If you click Fixup, the commit message of the fixup commit will be discarded, so this change will be invisible in the branch history.
In both cases, you will be able to edit the commit message in the mini editor that opens when you apply one of these actions.
> ### tip
- Ignore a commit: click Drop so that the changes from the selected commit are not applied.
- Undo all changes: click Reset to discard all actions you've applied to the commits.
As a result, the Rebasing Commits dialog shows a graph illustrating all actions you've applied to commits in your branch so that you can review them before starting the rebase:
5. Click Start Rebasing.
Edit a branch history and integrate it into another branch
WebStorm allows you to [rebase](https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html#rebase-branch) a branch on top of another branch and edit the source branch history before you apply the changes.
1. From the main menu select Git \| Rebase
2. Click Modify options and choose \--interactive.
3. From the list, select the target branch onto which you want to rebase the current branch:
4. If you need to rebase the source branch starting from a particular commit instead of rebasing the entire branch, click Modify options and choose \--onto.
In the source branch field, enter the hash of the commit starting from which you want to apply the current branch to the new base:
> ### tip
> To copy a commit hash, select it in the Log, right-click it and choose Copy Revision Number.
5. If the branch you want to rebase is not currently checked out, click Modify options, click Select another branch to rebase, and choose a branch from the list that appears:
WebStorm will check out this branch before starting the rebase operation.
6. Depending on your particular case, choose other options from the Modify options list:
- `--rebase-merges`: preserve the branching structure within the commits that are to be rebased.
Note that any resolved merge conflicts or manual amendments in these merge commits will have to be resolved or reapplied manually.
- `--keep-empty`: keep empty commits, which are commits that do not change anything from their parent.
- `--root`: rebase all commits reachable in the branch.
- `--update-refs`: automatically force-update any branches that point to commits that are being rebased.
- `--autosquash`: automatically squash commits marked for fixup or squash.
> ### tip
> For more information on these options, refer to [git-rebase](https://git-scm.com/docs/git-rebase)
7. Click Rebase.
The Interactive Rebase dialog will be displayed containing the list of all commits in the current branch that were made after the selected commit.
8. You can perform the following changes to the branch history:
- Change the order in which commits should be applied: use the  and  buttons to move commits up and down the list.
- Pick a commit: this is the default state for all commits. If you need to undo an action you've already taken on a commit, click Pick  so that this commit is applied as is.
- Edit: click Stop to Edit  so that when you start the rebase, you stop at this commit to be able to edit it.
When rebase is stopped at a commit, a notification pops up in the bottom-right corner of the WebStorm window letting you continue or abort the rebase:
You can modify this commit using the context actions (such as Revert, Undo, Amend, and so on before continuing the rebase. If you do not perform any actions, this commit will be applied as is.
If you've closed the notification, from the main menu choose Git \| Continue rebase to resume it.
- Reword the commit message: click Reword or double-click a commit and edit the text in the mini-editor that opens.
- Combine two commits into one: select the commit you want to meld into the previous one and click Squash or the arrow next to the Squash button and then Fixup.
If you click Squash, by default the messages from the two commits will be combined, so if you do not modify the resulting commit message, this action will be reflected in the branch history.
If you click Fixup, the commit message of the fixup commit will be discarded, so this change will be invisible in the branch history.
In both cases, you will be able to edit the commit message in the mini editor that opens when you apply one of these actions.
> ### tip
- Ignore a commit: click Drop so that the changes from the selected commit are not applied.
- Undo all changes: click Reset to discard all actions you've applied to the commits.
As a result, the Rebasing Commits dialog shows a graph illustrating all actions you've applied to commits in your branch so that you can review them before starting the rebase:
9. Click Start Rebasing.
Cherry-pick separate commits
Sometimes you only need to apply a single commit to a different branch instead of rebasing or merging an entire branch. This may be useful, for example, if you are working in a feature branch and want to integrate a hotfix from `main` that was committed after the two branches have diverged. Or you may want to backport a fix to a previous release branch. You can do so by using the Cherry-pick action.
The status bar displays the current state of a cherry-pick operation. You can manage the cherry-pick process using the following actions:
- Abort: to cancel an ongoing cherry-pick, select Abort Cherry-Pick in the VCS widget or click  in the status bar.
- Continue: if an ongoing cherry-pick was paused (for example, to resolve conflicts), select Continue Cherry-Pick in the VCS widget or click  in the status bar to finish the process.
Apply a commit to another branch
1. In the [Branches](https://www.jetbrains.com/help/webstorm/manage-branches.html) popup (main menu Git \| Branches), select the target branch that you want to integrate the changes to and choose Checkout from the popup menu to switch to that branch.
2. Open the Git tool window `Alt``09` and switch to the Log tab.
3. Locate the commit containing the changes you want to cherry-pick.
You can filter commits by branch, user or date. You can also click  on the toolbar and select Highlight \| Non-Picked Commits option to grey out the commits that have already been applied to the current branch. If you know the commit hash, or are looking for a tagged commit, you can also use the Go to Hash / Branch / Tag action (press `Ctrl``0F` in the Log tab of the Git tool window `Alt``09`, or click  on the toolbar).
4. Select the required commit. Use the information in the Commit Details area to make sure these are the changes you want to transfer to another branch.
5. Click Cherry-pick  on the toolbar. WebStorm will apply and commit changes to the target branch.
6. If the cherry-pick failed with conflicts, the selected changes will appear in the Changes area that you can see in the Commit tool window (`Alt``00`) . You can review these changes and commit them later if necessary.
If you want WebStorm to create changelists automatically in case of cherry-pick fail, switch on the corresponding setting in Settings \| Version Control \| Changelists.
7. Push the changes to the target branch.
The following video will help you see how cherry-pick works:
Apply separate changes
Imagine you've made some changes to a file that you want to apply to a different branch, but these changes were committed together with other modified files. WebStorm lets you apply separate changes to a changelist without committing them right away instead of cherry-picking an entire commit.
1. In the [Branches](https://www.jetbrains.com/help/webstorm/manage-branches.html) popup (main menu Git \| Branches), select the target branch that you want to integrate the changes to and choose Checkout from the popup menu to switch to that branch.
2. Open the Git tool window `Alt``09` and switch to the Log tab.
3. Locate the commit that contains the changes that you want to apply.
You can filter commits by branch, user or date. You can also click  on the toolbar and select Highlight \| Non-Picked Commits option to grey out the commits that have already been applied to the current branch. If you know the commit hash, or are looking for a tagged commit, you can also use the Go to Hash / Branch / Tag action (press `Ctrl``0F` in the Log tab of the Git tool window `Alt``09`, or click  on the toolbar).
4. In the Commit details pane on the right, select the files containing the changes you want to apply to the target branch and select Cherry-Pick Selected Changes from the context menu.
5. In the dialog that opens, select an existing changelist or enter the name for a new changelist and click OK.
6. Commit the changes and then push them to the target branch.
Apply separate files
In addition to applying separate changes to a single file, you can copy an entire file's contents to a different branch. This may be useful, for example, if the file you want to apply doesn't exist in the target branch, or if changes to it were made within several commits.
1. [Switch](https://www.jetbrains.com/help/webstorm/manage-branches.html#switch-branches) to the branch to which the changes will be applied.
2. In the [Branches](https://www.jetbrains.com/help/webstorm/manage-branches.html) popup (main menu Git \| Branches) or in the Branches pane of the Git tool window, select the branch that contains the file you want to apply and choose Show Diff with Working Tree from the context menu.
The Changes tool window that opens shows a list of all files that are different in the selected branch compared with the branch that is currently checked out:
- Files that exist in the selected branch and are missing in the current branch are marked with gray.
- Files that exist in the current branch but are missing in the selected branch are marked with green.
- Files that contain differences between the selected and the current branch are marked with blue.
You can click the Swap Branches link to change which branch is considered as a base against which you are comparing the other branch.
3. Select the file that you want to apply to the current branch, and choose Get from Branch from the context menu or click  on the toolbar.
4. Commit and push the changes. WebStorm will copy the entire contents of the file to the current branch.
> ### note
> You can also apply a file to another branch from the Project view: select the folder containing the file you want to copy, and choose Git \| Compare with Branch \| \<branch\_name\> from the context menu, then click the Get icon  on the toolbar. |
| Shard | 95 (laksa) |
| Root Hash | 2692805634082760095 |
| Unparsed URL | com,jetbrains!www,/help/webstorm/apply-changes-from-one-branch-to-another.html s443 |