> Your link says "Merge is perfectly fine for managing your code." The > only drawback it mentions is a more cluttered log. It has far stronger > warnings about misusing rebase. > > How could anyone read this conclusion > > > 1. Merge works great, but creates lots of empty merge commits when > you are working on a team. > 2. Rebase keeps things tidy, but is destructive and potentially > dangerous if you don¹t know what you are doing. > > and not conclude that merge is better for non-experts?
Gordon, So, that is effectively what Fred and I were discussing before. I do personally think a merge workflow is easier for beginners. Fred was pointing out the history becoming difficult to follow and also that in the merge scenario the new developer is responsible for committing the combination of the files they worked on plus the merge back to the repo. If they didn't do this it would be as though they had intentionally excluded the code that was in place before. He is right about both of those things. I was simply suggesting that, perhaps, to get everyone started we acknowledge both of those issues and deal with a period of messier logs until everyone is comfortable with the basics, then evolve an approach later that might be better for a more advanced set of users. The really big educational point is just to ensure you commit all of the changes after a merge. Mike
