🕷️ Crawler Inspector

[](https://www.baeldung.com/ops/ "Baeldung") - [](https://www.baeldung.com/ops/ "Baeldung") - [Start Here](https://www.baeldung.com/ops/start-here) - [Courses ▼▲]() - [Learn Java Collections Explore the Java Collections Framework and Algorithms](https://www.baeldung.com/courses/learn-java-collections-course) - [Learn Spring From no experience to actually building stuff](https://www.baeldung.com/courses/learn-spring-course) - [Learn Maven Simplify your build with Apache Maven](https://www.baeldung.com/courses/learn-maven-course) - [View All Courses](https://www.baeldung.com/members/all-courses) - [Pricing](https://www.baeldung.com/pricing) - [About ▼▲]() - [Full Archive The high level overview of all the articles on the site.](https://www.baeldung.com/ops/full_archive) - [About Baeldung About Baeldung.](https://www.baeldung.com/about) # Move Existing, Uncommitted Work to a New Branch in Git Last updated: February 6, 2024  Written by: [Kai Yuan](https://www.baeldung.com/ops/author/kai-yuan "Posts by Kai Yuan") - [Git](https://www.baeldung.com/ops/category/git) - [Git Branches](https://www.baeldung.com/ops/tag/git-branches) ## 1\. Overview [Git](https://www.baeldung.com/git-guide) is a quite popular version control system today. In this quick tutorial, we’ll explore how to move existing but uncommitted changes to a new branch. ## 2\. Introduction to the Problem First of all, let’s think about the typical workflow of adding a new feature to a Git managed project: - Create a new feature branch, say *feature*, and then switch to that branch - Implement the feature and commit it to our local repository - Push to the feature branch to the remote repository and create a pull request - After other teammate’s review, the new change can be merged into the *master* or *release* branch However, sometimes, we’ve started making changes but forgotten about creating a new feature branch and switching to it. As a result, we may realize that we’re on the wrong branch – for instance, the *master* branch – when we’re going to commit our changes. Therefore, we need to create a new feature branch and move the uncommitted work to the new branch. Moreover, the *master* branch shouldn’t be modified. An example may explain this scenario quickly. Let’s say we have a Git repository called *myRepo*: ``` Copy ``` As we can see from the output above, we’re currently on the *master* branch. Also, the working tree is clean. Next, let’s make some changes: ``` Copy ``` As the output above shows, we’ve added a new file, *a-new-file.txt*, and changed the content of *Readme.md*. Now, we realize that the work should be committed to a feature branch instead of the *master* branch. Next, let’s see how to move the changes to a new branch and keep *master* unchanged. ## 3\. Using the *git checkout* Command The *git checkout -b \<BranchName\>* command will create a new branch and switch to it. Moreover, this command will **leave the current branch as it is and bring all uncommitted changes to the new branch**. Next, let’s test the *git checkout* command on our *myRepo* project: ``` Copy ``` As the commands above show, we’ve created the *feature1* branch and moved all uncommitted changes from *master* to *feature1*. Next, let’s stage and commit the changes: ``` Copy ``` Now, let’s switch back to the *master* branch and check if we’ve left it unchanged: ``` Copy ``` There is no local change on the *master* branch, as we can see in the output. Further, there is no new commit on *master*, either. ## 4\. Using the *git switch* Command As we’ve known, Git’s *checkout* command is like a Swiss Army knife. The same command can do many different kinds of operations, such as restoring the working tree files, switching branches, creating branches, moving the head, and so on. The usage of the *checkout* command is pretty overloaded. Therefore, Git has introduced the [*git switch*](https://git-scm.com/docs/git-switch) command since version 2.23 to clear some of the confusion from the *checkout* command’s overloaded usage. As its name implies, *git switch* allows us to switch between branches. Moreover, **we can use the *\-C* option to create a new branch and switch to it in one shot**. It works pretty much the same as the *git checkout -b* command. Next, let’s do the same test as *git checkout -b* on the *myRepo* project: ``` Copy ``` As we can see in the output above, we’re currently on the *master* branch. This time, we’ve removed the file *Readme.md* and added a new *ReadmeNew.md* file. Next, let’s use the *git* *switch* command to move these uncommitted changes to a new branch called *feature2*: ``` Copy ``` As we can see in the output above, *git* *switch -C* creates a new branch *feature2* and brings us to *feature2*. Further, all uncommitted changes have been moved from *master* to the *feature2* branch. Then, we’ve committed the changes to the *feature2* branch. Next, let’s switch back to the *master* branch and check if it’s unmodified: ``` Copy ``` As we’ve seen, on the *master* branch, all changes to the working tree files we made previously have been restored. For example, the removed file *Readme.md* has come back. Moreover, the *git log* command shows no new commit on *master*. ## 5\. Conclusion In this article, we’ve addressed a couple of quick ways to move uncommitted changes to a new Git branch. Both commands are pretty straightforward to use: - *git checkout -b \<NEW\_BRANCH\>* - *git switch -C \<NEW\_BRANCH\>* 1 Comment Oldest Newest Inline Feedbacks View all comments View Comments Load More Comments  #### Categories - [Jenkins](https://www.baeldung.com/ops/category/jenkins) - [Kubernetes](https://www.baeldung.com/ops/category/kubernetes) - [Git](https://www.baeldung.com/ops/category/git) #### Series - [Docker Guide](https://www.baeldung.com/ops/docker-guide) - [Kubernetes Guide](https://www.baeldung.com/ops/kubernetes-series) #### About - [About Baeldung](https://www.baeldung.com/about) - [Baeldung All Access](https://www.baeldung.com/courses) - [The Full Archive](https://www.baeldung.com/ops/full_archive) - [Editors](https://www.baeldung.com/editors) - [Ebooks](https://www.baeldung.com/library) - [FAQ](https://www.baeldung.com/library/faq) - [Baeldung Pro](https://www.baeldung.com/members/) - [Terms Of Service](https://www.baeldung.com/terms-of-service) - [Privacy Policy](https://www.baeldung.com/privacy-policy) - [Company Info](https://www.baeldung.com/baeldung-company-info) - [Contact](https://www.baeldung.com/contact) Privacy Manager  wpDiscuz Insert  ## Looks like your ad blocker is on. × We rely on ads to keep creating quality content for you to enjoy for free. Please support our site by disabling your ad blocker or, use **Baeldung Pro** for a clean, absolutely **no-ads** reading experience. Disable [Baeldung Pro](https://www.baeldung.com/members) Continue without supporting us #### Choose your Ad Blocker - Adblock Plus - Adblock - Adguard - Ad Remover - Brave - Ghostery - uBlock Origin - uBlock - UltraBlock - Other 1. In the extension bar, click the AdBlock Plus icon 2. Click the large blue toggle for this website 3. Click refresh 1. In the extension bar, click the AdBlock icon 2. Under "Pause on this site" click "Always" 1. In the extension bar, click on the Adguard icon 2. Click on the large green toggle for this website 1. In the extension bar, click on the Ad Remover icon 2. Click "Disable on This Website" 1. In the extension bar, click on the orange lion icon 2. Click the toggle on the top right, shifting from "Up" to "Down" 1. In the extension bar, click on the Ghostery icon 2. Click the "Anti-Tracking" shield so it says "Off" 3. Click the "Ad-Blocking" stop sign so it says "Off" 4. Refresh the page 1. In the extension bar, click on the uBlock Origin icon 2. Click on the big, blue power button 3. Refresh the page 1. In the extension bar, click on the uBlock icon 2. Click on the big, blue power button 3. Refresh the page 1. In the extension bar, click on the UltraBlock icon 2. Check the "Disable UltraBlock" checkbox 1. Please disable your Ad Blocker Go Back

## 1\. Overview [Git](https://www.baeldung.com/git-guide) is a quite popular version control system today. In this quick tutorial, we’ll explore how to move existing but uncommitted changes to a new branch. ## 2\. Introduction to the Problem First of all, let’s think about the typical workflow of adding a new feature to a Git managed project: - Create a new feature branch, say *feature*, and then switch to that branch - Implement the feature and commit it to our local repository - Push to the feature branch to the remote repository and create a pull request - After other teammate’s review, the new change can be merged into the *master* or *release* branch However, sometimes, we’ve started making changes but forgotten about creating a new feature branch and switching to it. As a result, we may realize that we’re on the wrong branch – for instance, the *master* branch – when we’re going to commit our changes. Therefore, we need to create a new feature branch and move the uncommitted work to the new branch. Moreover, the *master* branch shouldn’t be modified. An example may explain this scenario quickly. Let’s say we have a Git repository called *myRepo*: ``` $ git branch * master $ git status On branch master nothing to commit, working tree clean ``` As we can see from the output above, we’re currently on the *master* branch. Also, the working tree is clean. Next, let’s make some changes: ``` $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: Readme.md Untracked files: (use "git add <file>..." to include in what will be committed) a-new-file.txt no changes added to commit (use "git add" and/or "git commit -a") ``` As the output above shows, we’ve added a new file, *a-new-file.txt*, and changed the content of *Readme.md*. Now, we realize that the work should be committed to a feature branch instead of the *master* branch. Next, let’s see how to move the changes to a new branch and keep *master* unchanged. ## 3\. Using the *git checkout* Command The *git checkout -b \<BranchName\>* command will create a new branch and switch to it. Moreover, this command will **leave the current branch as it is and bring all uncommitted changes to the new branch**. Next, let’s test the *git checkout* command on our *myRepo* project: ``` $ git branch * master $ git co -b feature1 Switched to a new branch 'feature1' $ git status On branch feature1 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: Readme.md Untracked files: (use "git add <file>..." to include in what will be committed) a-new-file.txt no changes added to commit (use "git add" and/or "git commit -a") ``` As the commands above show, we’ve created the *feature1* branch and moved all uncommitted changes from *master* to *feature1*. Next, let’s stage and commit the changes: ``` $ git add . && git commit -m'implemented feature1' [feature1 2ffc161] implemented feature1 2 files changed, 2 insertions(+) create mode 100644 a-new-file.txt $ git log --abbrev-commit feature1 commit 2ffc161 (HEAD -> feature1) Author: ... Date: ... implemented feature1 commit b009ddf (master) Author: ... Date: ... init commit ``` Now, let’s switch back to the *master* branch and check if we’ve left it unchanged: ``` $ git checkout master Switched to branch 'master' $ git status On branch master nothing to commit, working tree clean $ git log --abbrev-commit master commit b009ddf (HEAD -> master) Author: ... Date: ... init commit ``` There is no local change on the *master* branch, as we can see in the output. Further, there is no new commit on *master*, either. ## 4\. Using the *git switch* Command As we’ve known, Git’s *checkout* command is like a Swiss Army knife. The same command can do many different kinds of operations, such as restoring the working tree files, switching branches, creating branches, moving the head, and so on. The usage of the *checkout* command is pretty overloaded. Therefore, Git has introduced the [*git switch*](https://git-scm.com/docs/git-switch) command since version 2.23 to clear some of the confusion from the *checkout* command’s overloaded usage. As its name implies, *git switch* allows us to switch between branches. Moreover, **we can use the *\-C* option to create a new branch and switch to it in one shot**. It works pretty much the same as the *git checkout -b* command. Next, let’s do the same test as *git checkout -b* on the *myRepo* project: ``` $ git branch feature1 * master $ git status On branch master Changes not staged for commit: (use "git add/rm ...) (use "git restore ...) deleted: Readme.md Untracked files: (use "git add <file>..." to include in what will be committed) ReadmeNew.md ... ``` As we can see in the output above, we’re currently on the *master* branch. This time, we’ve removed the file *Readme.md* and added a new *ReadmeNew.md* file. Next, let’s use the *git* *switch* command to move these uncommitted changes to a new branch called *feature2*: ``` $ git switch -C feature2 Switched to a new branch 'feature2' $ git status On branch feature2 Changes not staged for commit: (use "git add/rm ...) (use "git restore ...) deleted: Readme.md Untracked files: (use "git add <file>..." to include in what will be committed) ReadmeNew.md ... $ git add . && git commit -m 'feature2 is done' [feature2 6cd5933] feature2 is done 1 file changed, 0 insertions(+), 0 deletions(-) rename Readme.md => ReadmeNew.md (100%) $ git log --abbrev-commit feature2 commit 6cd5933 (HEAD -> feature2) Author: ... Date: ... feature2 is done commit b009ddf (master) Author: ... Date: ... init commit ``` As we can see in the output above, *git* *switch -C* creates a new branch *feature2* and brings us to *feature2*. Further, all uncommitted changes have been moved from *master* to the *feature2* branch. Then, we’ve committed the changes to the *feature2* branch. Next, let’s switch back to the *master* branch and check if it’s unmodified: ``` $ git switch master Switched to branch 'master' $ git status On branch master nothing to commit, working tree clean $ ls -1 Readme.md Readme.md $ git log --abbrev-commit master commit b009ddf (HEAD -> master) Author: ... Date: ... init commit ``` As we’ve seen, on the *master* branch, all changes to the working tree files we made previously have been restored. For example, the removed file *Readme.md* has come back. Moreover, the *git log* command shows no new commit on *master*. ## 5\. Conclusion In this article, we’ve addressed a couple of quick ways to move uncommitted changes to a new Git branch. Both commands are pretty straightforward to use: - *git checkout -b \<NEW\_BRANCH\>* - *git switch -C \<NEW\_BRANCH\>*