I have a git repo on the internet and two workstations. Other developers have access to the git repo.

Workstation A is at the office and is not accessible from the internet, but can push/pull the git repo. Workstation B is at home.

I'm working on a private local branch on Workstation A and have to leave for home when it's in a dirty state. I want to continue working at home on Workstation B.

What is the best way to sync my dirty private branch to Workstation B?


In this context dirty means work that I don't think is complete. How would the flow differ for committed vs uncommitted work?

  • 1
    What does "in a dirty state" mean in this context? That you have uncommitted changes?
    – IMSoP
    Oct 18, 2016 at 13:48
  • 1
    Can you describe your branching strategy? What would be the effect of committing work to a remote branch that is not complete, not tested, and may not be working (including possibly build-breaking)?
    – Thomas Owens
    Oct 18, 2016 at 14:10
  • There is no downside to commiting the broken build to a feature branch
    – Ewan
    Oct 19, 2016 at 7:44

1 Answer 1


When I want to work on an unfinished change on another machine, I typically:

  1. Create a branch: $ git checkout -b feature/foobar
  2. Create a "WIP" commit: $ git commit --all -m "WIP: Add feature foobar"
  3. Push the branch to the remote

And them from the other computer:

  1. Fetch from the remote
  2. Checkout my branch: $ git checkout feature/foobar
  3. Finish the feature
  4. Amend the previous commit: $ git commit --all --amend
  5. Force push to overwrite the WIP commit on the remote: $ git push -f

NOTE: Only use this workflow (amend + force push) if you are the only one using the branch or are in direct communication with everyone else using this branch.

  • 2
    This is basically what I was thinking. One thing you can do to avoid the dangers of force pushing is to have a naming convention for work in progress branches - remember that branches are cheap! So you could use retrodev-wip/feature/foobar, rewrite history and force push at will, then push it as feature/foobar when you're ready for other people to see it.
    – IMSoP
    Oct 18, 2016 at 14:50
  • Could you please explain why you're doing an --amend and push -f in steps 4 and 5?
    – retrodev
    Oct 18, 2016 at 15:05
  • @retrodev --amend adds the new changes into the previously WIP commit (which should also now get an updated commit message). Because this modifies the history, force-pushing is required. Oct 18, 2016 at 15:39
  • 2
    @retrodev The "deeper" reason to use --amend is that you want to pretend to your colleagues that the intermediate WIP commit never happened - it was just your way of transporting the changes to a different computer, and wasn't a finished piece of work. If you're happy for it to show up as a commit in the final history, but just don't want people to use it yet, then the question has a much simpler answer: "Commit and push your changes to your branch, that's what branches are for."
    – IMSoP
    Oct 18, 2016 at 15:56
  • Force push breaks the version on your home machine right?
    – Ewan
    Oct 19, 2016 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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