On Dec 5, 11:43 pm, Roddie Grant <gitl...@myword.co.uk> wrote:
> I develop websites on my laptop. Every so often I commit and push to the
> remote test server to see how things run there, merging to its local
> "nowork" branch. Inevitably there are one or two very minor wrinkles. I fix
> these on the laptop and then push again to the test server.
> When everything is OK, I like to rebase/squash the minor corrections into
> the substantive commit, but need to bodge the test server to match.
> I reset --hard on the test server "nowork" branch to remove the now-rebased
> commits, but I cannot then push the rebased code to the test server - it
> won't do fast forward because the remote branch has the original individual
> commits, even though I've reset the "nowork" branch. If I use
> push -f test mybranch:refs/remotes/dev/mybranch (ie with the -f option),
> will that force the remote branch to match the rebased code, and I can then
> merge it into "nowork"? I am aware this needs to be done with care, but it
> fits very nicely into the workflow I've evolved. The "nowork" branch is
> never pulled.
If the refs/remotes/dev/mybranch branch is the result of doing
$ git remote add dev URL_of_your_dev_laptop_repo
$ git fetch
on the server,
then after doing the push you described you have to
$ git checkout nowork
$ git reset --hard dev/mybranch
on the server to make its local "mybranch" point to the same commit
the just updated branch does.
That is, I'm sceptical about that ``merge it into "nowork"'' part as
after your forced push, the branches will clearly have diverged
histories: "nowork" having the original series of fixes and "dev/
mybranch" having the rebased/squashed set of the same fixes.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at