[Bf-committers] How Merge master changes into remote branch

[Wander Lairson Costa]

2013/11/20 Joshua Leung <aligorith at gmail.com>:
> Good points Julien/_FrnchFrgg_
>
> I'm personally of the opinion that usage of rebase in general is a Bad
> Thing (TM). For small/short-lived projects (or local feature branches for
> small features), it's probably ok to use rebase (though again, that depends
> heavily on the nature of how things developed).
>
> However, when you've got larger branches that have been going for a longer
> period of time, with somewhat complex history, IMO you're better off making
> an explicit merge (i.e. a "git merge --no-ff", perhaps followed by
> hand-editing of the merge commit's log message detailing the extent and
> implications of the branch which you've just merged in). By using rebase,
> you're throwing away a lot of contextual information about how the project
> developed - and end up wasting time "sanitising" the development history so
> that it will now make sense in light of this.

You mean, when merging to master?

>
> Besides, adding rebase to your workflow just ends up complicating things.
>
>

I agree that rebase is a feature that takes a lot of pain to learn how
to use judiciously, but IMO it helps a lot with a clean history.

-- 
Best Regards,
Wander Lairson Costa