top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Git rebase for cleanup, after pushing

0 votes
326 views

I run across this problem quite a bit: I have a branch that I'm working on. Unfortunately for me, in order to get my code tested and built by our build servers and infrastructure (which is a requirement before it can be code reviewed and merged, plus it builds my code on platforms I don't otherwise have easy access to) I have to push it to our main git repo, since that's the only place the build infrastructure can get it from.

This means I have to publish my work-in-progress branches up to the git server, including all the false starts, backups, single-line "oops" fixes, etc. Then if I merge my branch into the master branch, all that
becomes part of the mainline of the code.

If it's a small change which is really just one thing I can just use a squash merge into master. But for larger changes what I'd like to do is clean it all up into a smaller set of well-formed commits and push
those. This sounds like a job for rebase -i.

However, I've already pushed my branch to master. I know rebasing stuff you've already pushed is considered a no-no in general, but I can't avoid it. Does anyone have suggestions for how to make this work better? Should I be rebasing to a brand new branch, then merge that to master? Just rebase directly to master? None of the above? Something else entirely?

posted May 31, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

I dont understand why you dont do all this cleanup *before* you merge into master.

Theres no problem with rebasing published history per se, only with rebasing history that someone else might have pulled into their own history. You can rebase to your hearts content as long as youre on your own branch, even of it does have to live on a remote server.

answer May 31, 2013 by anonymous
Similar Questions
+1 vote

Is it required to do a git pull before doing a git push.and is it required to do a git rebase after git pull just before git push. one of my git repo mandates the above wondering if there is a valid reason for this.

0 votes

I work on some files and push/merge them to the remote server. Sometimes I get merge conflicts on those files and have to fix them. That's completely fine. I get that.

What I don't understand is that sometimes during this process I will get merge conflicts in files _I have never touched_. In fact they are in a completely different series of directories to the one I am working on and someone else project entirely. How am I meant to know how to fix these? I dont know what the other developer wanted to do and if they have done it right.

I thought git only merged/pushed the files you have changed? If someone else has changed Group A files on the remote repo, why must I change my local Group A files when I am _pushing _completely different set of Group B files?

Sure, Id understand if I were pulling files down to my local and had to resolve merge conflicts then, but this isn't happening when I push the files up.

Any help or advice is much appreciated. Sorry if I sound frustrated - I am really trying hard to get my head round this whole git thing but its just so weird.

+2 votes

Could somebody tell me how to make git rebase -i show diff of squashed commits (for example), like git commit -v does it?

...