Sometimes I run into the problem of having uncommitted code on a workstation that is not ready for a commit but needs to be completed on a different workstation or laptop.

Does anyone have a solution for this problem, such as a "soft commit" or some other way of transferring the changes to another machine to work on them elsewhere?

I would prefer not to be forced to commit and push changes that are not properly implemented.


5 Answers 5


The following assumes your local repo is a clone of a repo on another server, e.g. github; and that you have rights to make changes to the upstream server. In my example, I've called this upstream repo "origin". Run git remote show to list other repos, this may give you a hint as to what it's called.

I would suggest making a branch, then you can check out the branch on another machine. In fact, if you make a branch as soon as you start work, you can "commit" to your branch, have a trail and backup of your work, without having to have a stable codeset. Once you are happy with your work, you can merge it back into your "master" branch.

  • To branch your repo: git checkout -b MyNewBranch
  • To push committed changes of your new branch: git push origin MyNewBranch
  • To check out a branch on another machine: git checkout MyNewBranch
  • To switch to another branch (e.g. "master"): git checkout master
  • When in master, to merge MyNewBranch back in: git merge MyNewBranch
  • To list branches: git branch
  • 3
    Yes, always working in your own private branch essentially solves this problem. You can commit as often as you want without affecting anyone else. Even better is to create a new branch every time you start work on a new feature or start fixing a new defect. This makes it very easy to jump back and forth between codebases.
    – user53141
    Commented Mar 10, 2014 at 2:36
  • Also, and the reason I do this: if you make a mistake halfway through, you can go to previous commits on the current branch. Or, jump back, grab a piece of it, jump forward and apply. Commented Mar 10, 2014 at 19:37
  • 2
    Wouldn't this method also include the incomplete commits in the merged master branch?
    – eimrek
    Commented Jan 24, 2016 at 19:28
  • Yes, and (in my opinion) that's probably not a bad thing. If you don't want that, do the above, then instead of committing your code, create a diff (which includes all file changes, but no commits), apply it to a fresh copy of the branch, then push that. Commented Jan 25, 2016 at 0:25
  • 3
    regarding "To switch to another branch do git branch -d master", I'm confused, doesn't that ask git to delete the master branch?? (that's the impression I get from reading the git branch manual anyway) Commented Nov 21, 2016 at 12:13

I commit it. The I push it to personal branch, check out on the other side and amend. And delete the personal branch when done.

Of course you can push directly between the repos, you can use bundle or format-patch/am, but a personal branch is by far the easiest solution. And rewriting history is not a big deal as long as it's not pushed to any shared branch. In many projects people are supposed to rewind the feature branches to keep them easier to understand for review.

  • i agree with this approach Commented Jan 18, 2021 at 11:26

You can use git diff to create a patch and then apply it on other machine. Or you can create a temporary commit, then pull it from other machine. You can even create a temporary branch on some other machine, push your temporary commit there, then delete the branch.

My favorite method is the second one: creating a temporary commit, then going to another machine and doing something like this:

$ git fetch ssh://first_machine/path/to/repo whatever_branch_i_was_working_on
$ git reset --hard FETCH_HEAD
$ git reset HEAD^
  • Why so complicated and not just using git format-patch? Commented Jul 25, 2017 at 10:14
  • Not really different from git diff. Is there something I'm missing?
    – aragaer
    Commented Jul 26, 2017 at 13:54
  • 1
    git format-patch deadbee..badcab1e - It creates .patch files for every commit separately with nice name and commit message preserved. Commented Jul 26, 2017 at 14:53
  • 1
    Does it also create a patch for changes that are not yet committed? Does it separate current index and things that are not yet staged? Looks like it doesn't.
    – aragaer
    Commented Jul 27, 2017 at 15:09
  • No, not for the uncommitted/unstaged changes. But since a commit does not hurt anybody else as long as you don't push it should be OK to commit (with a clear message that says "WIP" - work in progress). Commented Jul 27, 2017 at 20:16

The easy approach is the one you describe: copy the .git hidden directory and project files to another machine where you can either commit and finish up, or just continue working.

The .git directory is where your git history is kept, so preserving this along with the actual files keeps your entire project history intact.

If you are permanently done using the original machine, I'd probably recommend this approach.


Like others have answered, with Git you shouldn't care about non-finished code in your personal branches. However, if for some reason, you really really really don't want your unfinished work to ever touch the main repo, you can utilize Git's distributed nature!

There is a simple tool named git bundle that can help you easily pass changes around without a central repository. First, clone the repo:

git clone https://github.com/octocat/Spoon-Knife.git working_copy_1
cd working_copy_1

make some changes and commit them to a temporary branch:

git checkout -b tmp_branch
git commit -a -m "temporary changes"

Now, bundle them changes:

git bundle create ../tmp.bundle tmp_branch

Now you have a bundle file you can mail to your new machine. How do you use it there? Let's create a new working copy:

cd ..
git clone https://github.com/octocat/Spoon-Knife.git working_copy_2
cd working_copy_2

we need to treat our bundle as another remote, so we can fetch the changes from it

git remote add tmp ../tmp.bundle
git fetch tmp

since the whole point was to transfer the changes without leaving a trace, we'll want to squash them into the working copy in order to lose the temp commit:

git merge tmp/tmp_branch --squash

and all that is left is to remove the temporary remote:

git remote remove tmp

VIOLA! The changes were transferred to the new working copy without leaving a trace of neither branch nor commit!

But really - this process is quite long and cumbersome. This is Git, not SVN - there really shouldn't be any reason not to push your personal branch to the central repo.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.