Not another one. All good git workflows are different; all bad git workflows are bad in the same way - okay, one of the same two ways: superstitiously declarin

Not another one. All good git workflows are different; all bad git workflows are bad in the same way - okay, one of the same two ways: superstitiously declaring important parts of the git model "bad" (merge commits are bad! rebasing and amending are bad!), or superstitiously merging things that have no business being merged together left and right (this is really a special case of the first: it's 'branches are bad!', though the person doing it often doesn't realize it). GitHub certainly doesn't help matters by putting a frontend onto git that doesn't match the conceptual model of git in the least - you can't even see the graph unless you dig deep and find "Network", the world's worst graph visualizer, and the pull-request module is absolutely unreviewable and has giant inviting buttons to instantly do nontrivial things to your immutable (without inflicting cascading rebases on the entire planet) history that you may or may not even want without telling you exactly what they'll do. It's a pretty serious indictment that Bitbucket, originally designed for Mercurial, is the only web frontend to git that does a passable imitation of gitk. (Git (the command-line porcelain) doesn't help matters by assuming the user is a seasoned LKML veteran with Linus or a vice-Linus above them willing to ruthlessly reject their history if it sucks, either.) "We are a small two-person collaboration on separate chapters of a book in LaTeX, so we will forego branching, work on master, use pull --rebase, and push to the same central remote, to basically have a more robust CVS" is a git workflow you can have. "I am the maintainer of a decently large open-source project, so I will accept only signed tag pull requests of work based on the last signed and tagged stable release, with cleanly logically separated commits and no internal merges allowed unless explicitly justified, and --no-ff merge them onto my ongoing blessed integration branch after review" is another git workflow you can have, and it uses more of git's featureset - it's close to how Linux works, if you factor out the mailing lists and ignore the presence of vice-Linuses. "Rebase everything willy-nilly because merge commits are BAD" and its just-as-evil twin, "have multiple branches but merge them all into each other whenever someone blinks, because separating separate work is BAD but 'branch' is a buzzword" are not workflows you can have, they're symptoms you can exhibit. GitHub, et "considered harmful" blog posts, et superstition, delendae sunt.