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

Wander Lairson Costa wander.lairson at gmail.com
Thu Nov 21 13:08:03 CET 2013

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

More information about the Bf-committers mailing list