3

Alright, I have a development branch that is tracked remotely and shared by everyone on this project.

Locally I have branched off of this to do some ongoing work. However, in the mean time another developer has committed and pushed changes to the development branch that I would like reflected in my local branch. Is this the time to rebase?

I don't want to simply commit my local branch to development and then start a new branch because I would like to maintain my commit history.

As I understand it, rebase would take the development branch at HEAD and re-apply all of my commits over top of it, but will that overwrite the other developer's changes without throwing a conflict if we have made changes to the same lines?

Improve this question
5
  • Why not store your changes into a patch, pull his changes, and then apply your patch? Commented Oct 16, 2012 at 22:04
  • 1
    @shortstuffsushi I may be misunderstanding you (I know almost nothing about patch), but I don't see how pulling will get his changes into my private branch. Only to my local copy of the development branch. Commented Oct 16, 2012 at 22:18
  • @shortstuffsushi; git rebase will do that automatically, so why make things more difficult? Commented Oct 16, 2012 at 22:18
  • @itsbruce That may be the case, I've just never had success with rebasing. I've never really working on a clean tree, though. Commented Oct 17, 2012 at 1:47
  • @shortstuffsushi You should always be working with a clean tree. Most of Git's features (rebase, quickly switching between branches or back into history, bisect) work so much better if you don't have extra cruft lying around. Use your .gitignore so that you don't have extra files getting in your way, and use git stash if you have half-finished changes that you're not ready to commit. git status should report that there's nothing to commit unless you are actively working on something. Commented Oct 17, 2012 at 3:05

2 Answers 2

Reset to default
6

First, you fetch, then you rebase. You don't clobber the other guy's changes by doing this; what you do is redo your changeset so that it's a delta against his changes rather than the earlier version. It eliminates unnecessary and unhelpful merge messages from the logs and makes the log more meaningful if this is really how the development history should be represented.

Go ahead and rebase; sounds like the right thing to do in this case. way too many people just git pull without thinking.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

+1 for "way too many people just git pull without thinking".
5

Yes, you are right that rebase will take the head of the development branch, and re-apply all of your commits on it.

No, it will not overwrite other developers changes without throwing a conflict. If there is a conflicting change, you will need to resolve the conflicts, just like in a merge (fix the conflicts, and use git add to stage the fix), and then tell rebase to continue using git rebase --continue.

Yes, this is an appropriate time to do a rebase. That's how a lot of people work; if they have unpushed local commits, and there are upstream commits, they rebase their local commits before continuing to work or pushing to a public repo.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.