问题
I have usage the SmartGit! I know difference between rebase and merge, but I heard that rebase it classified as troubleshooting operation and it's not recommend for daily usage. So SmartGit instead reccomend that method. What would you select?
回答1:
The rule of thumb:
if you have already published commits which are to be rebased or merged, and an unspecified number of users have already got them into their private repository clones, then merge is the only option.
if you haven't publish them, or you can ask all remote users to re-fetch rebased commits, and this won't be a big disturbance for them, then you may rebase.
Actually, to keep the history of unpublished commits straight and clean, you should rebase them. If e.g. you find a mistake in a previous unpublished commit, you should reset to the broken commit, amend it, and then rebase the rest of the chain over new fixed commit.
Rationale:
In git and [some] other DVCS parent(s) of a commit is an inseparable property of a commit. So if parent property is changed, this produces a completely new commit, even it has the same source tree as the original one. The same is applied to "amended commits" (at least commit time is changed during amend).
If one publishes some commits, those commits could be used by other repository users for their derivative works. Rebasing commits, that have been already published, demands that all other users, in turn, have to rebase their works over new versions of commits. Definitely, it makes life of your colleagues harder, and I wouldn't recommend this approach without feasible arguments.
From other hand, making unnecessary merges in your local chain of changes complicates things, and the repo history quickly becomes a mess. That's why rebase is a recommended approach to re-organize/re-order an unpublished set of commits.
来源：https://stackoverflow.com/questions/37160969/what-would-you-select-between-rebase-and-merge-methods-in-pull