I realize that this is subject to lots of different opinions and that my input doesn't carry much weight - At least I thought it's a topic that should be brought up (again?) --------- To start.... I hate git.. I have used it for years now and the multitude of ways that are possible to accomplish nearly the same thing are *annoying* at best.. With that rant out of the way on to the point.. --------- I super don't like "merge" workflows. 1) "merge commits" are confusing at best and normal tools don't display and work with them as you'd always expect
2) merge commits lead to multiple parents, which breaks a clean and simple to follow linear history --------- What I personally prefer is a rebase workflow. The downsides 1) Requires to you rebase before pushing. Which can be slightly more work than just a lazy resolution of the conflicting "merge commit" (depending on if you flatten your commits) 2) May not be the most popular git work-flow. 3) Due to #2 from above - may have detractors and or less people who are familiar with it. -------------- I'm of the mindset that if you're going to keep something under revision - the history should be clear and clean. Linear is the only way to fly for that. For those using cvs or svn - that's what they'll be familiar with and probably expect to find in a git log. You can start with forcing rebase and keep a clean history - if one day it proves too problematic you can switch over to "merging" - the other way isn't really possible to do cleanly, depending on your tools.. Thanks for the minute
