Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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.
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.
git checkout -b MyNewBranchgit push origin MyNewBranchgit checkout MyNewBranchgit checkout mastergit merge MyNewBranchgit branch
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)
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.
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^
git format-patch deadbee..badcab1e - It creates .patch files for every commit separately with nice name and commit message preserved.
Jul 26, 2017 at 14:53
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.
git stash... ?