How to push/pull Git rebase

Question

I'd like to use git rebase so as to cleanly merge a feature in the master branch (in less commits or at least at the top of the change log). Note that I'm the only one working on the repository.

After reading Git workflow and rebase vs merge questions, I found git rebase would be pretty nice and like Micah I'd like to git push rebased changes simply because I'm working on them from different places (ex: my notebook, my home, another PC somewhere...)

So here are two solutions (to the bi-directional ugly merge):

1. Using git push -f to push, and then pulling on other machine, but how to cleanly get the latest version on other machines?
2. Using merge to merge master changes to the feature branch, git push/pull, and once mature, do a single rebase (in one or more commits cleanly)

(2) would be like below:

git co -b feature-a
... change files
git push origin feature-a
... moving to another PC
git pull origin feature-a
... change files
git merge master
... change files (not the "special rebase")
git rebase master
git co master
git merge feature-a
git branch -d feature-a
git push origin :feature-a

Which solution do you think would work? I haven't tried either of them so far (mostly by fear of making my log more messy).

Answer 1

I always make sure I commit and push (-f) everything from any machine I leave.

When I arrive at some other machine:

 git fetch -v
 git checkout mybranch # Already checked out with old HEAD
 git reset --hard origin/mybranch

This works well because I know the other "me" at different computers consistently commits and pushes before I leave (And therefore there are no unpushed changes on the machine I arrive at)

Answer 2

Remember that git rebase replays changes and creates new commits. By rebasing and forcing pushes all over the place, you're going against the grain of the tool. Note how the "Recovering from an upstream rebase" section of the git rebase documentation begins (with added emphasis):

Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream's point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.

Even though you're the sole developer, you'll still be others (from the perspective of one repo) when working in other clones. As you've seen, this workflow is a hassle.

Let your changes cook in branches. When a branch is ready for primetime, then rebase, merge it into master, and delete its topic branch. Your life will be easiest if you keep branches' lifetimes short and their scopes narrow.