4 ms·

I got the exact feeling as yours at first. :) My understanding of your concern of rebase is that if they are gonna change that (or get rid of that), it will be

I got the exact feeling as yours at first. :) My understanding of your concern of rebase is that if they are gonna change that (or get rid of that), it will be a change of the workflow instead of just a simplification of it. I used to rely on merge other than rebase when my local tree is diverted. That usually ended up with two commits (one for my local changes, one for the merge). But later I learned to use rebase. It would only result in one commit, which I feel is kinda nice coz you have a cleaner and more correct(time-wise) commit history. I don't know if this is the fundamental purpose of rebase. Advice welcome.

mikekchar 12y ago
This was a long time ago, so maybe you won't see this reply :-) Rebase is awesome as long as you never publish the branch before you rebase. If anyone uses your branch, then the history will not match up and they will not be able to merge their changes because Git will not be able to determine the order of the commits. I have gone through this more than once and it is not fun at all. Rebase works extremely well for what is was designed for: You have a lot of people working completely independently and you want to submit your changes to a central maintainer. You rebase your branch so that the changes appear to be applied directly onto their branch. It makes it much, much easier to review. If the change is accepted then it is merged and everybody uses the merged version. If not, the branch is destroyed (of course you still have your changes in your repository). As long as nobody makes any changes to (or branches off of) a branch that will be rebased, then there will be no problem. Because the vast majority of people use git as kind of a "better SVN", with a centralized repository and published branches (using Github or the like), most people should never, ever use rebase. Especially if you are trying to design a simple workflow for neophytes, then you should almost certainly not make rebase easy to reach. Like I said, I like rebase, but it is not something that fits well in a collaborative office environment. It works much better in a hugely distributed open source project, or a personal project (if you are being very careful).

mikekchar 12y ago

This was a long time ago, so maybe you won't see this reply :-) Rebase is awesome as long as you never publish the branch before you rebase. If anyone uses your branch, then the history will not match up and they will not be able to merge their changes because Git will not be able to determine the order of the commits. I have gone through this more than once and it is not fun at all. Rebase works extremely well for what is was designed for: You have a lot of people working completely independently and you want to submit your changes to a central maintainer. You rebase your branch so that the changes appear to be applied directly onto their branch. It makes it much, much easier to review. If the change is accepted then it is merged and everybody uses the merged version. If not, the branch is destroyed (of course you still have your changes in your repository). As long as nobody makes any changes to (or branches off of) a branch that will be rebased, then there will be no problem. Because the vast majority of people use git as kind of a "better SVN", with a centralized repository and published branches (using Github or the like), most people should never, ever use rebase. Especially if you are trying to design a simple workflow for neophytes, then you should almost certainly not make rebase easy to reach. Like I said, I like rebase, but it is not something that fits well in a collaborative office environment. It works much better in a hugely distributed open source project, or a personal project (if you are being very careful).