gitreflow

This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations. Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebase and lose all work associated with it? This is why my team and I moved to squash merging. Sure it has it's own drawbacks, but they're far less worrisome than rebasing. If you screw up a rebase, the history is re-written or force-pushed by accident. If you screw up a squash merge, you can still check out the intermediate commits if you know the hash. We won a Ruby award for our work on Git Reflow. There are big improvements co

Git reflow does this (and more). If you want to do presubmit code reviews, and squash merge to master to preserve history. You might like it. https://github.com/reenhanced/gitreflow

As one of the maintainers of git-reflow, I understand the controversy over squash-merges. Personally, on all the projects I've worked on with this workflow, I have yet to find any drawbacks when needing to use git-blame; although is not to say that there is no value in maintaining a full history nor that it is our way or the highway. We like to keep all changes in context of a feature. We have worked in environments that promote rebasing of feature branches, and while that may work well, it can lead to holes in the history of the review process due to the need to force-push. That said, we are nearing a stabilized core API and have plans to allow for more flexibility in the process. If you are interested in following our ideas behind this, feel free to follow the issue we have open: https://github.com/reenhanced/gitreflow/issues/53

I agree, but here's their reasoning: https://github.com/reenhanced/gitreflow/issues/52 > When it really comes down to it, the only place we care about enforcing a particular style of commit is in the master branch. We don't care if you make a thousand commits to get there, the only thing we care about is the individual features that come in from each (small) pull request. > And while the history is nice, the biggest advantage of using the squash merge is that over time, git blame becomes way more useful. You get to see for every line of code in your project, not only the person who changed it, but their commit in the full context of why that change was made, including an easy-to-reference link to the pull request and ideally (through the pull request description), a link to the ticket tracker. So we can tie any line of code all the way ba

In my team's projects, code review in PRs made a mess of the history (certain devs in particular :P). We switched to a squash merge based workflow to address it, git reflow is our particular poison: https://github.com/reenhanced/gitreflow

This is a more complicated version of the 2015 Fukuoka Ruby Award winner Git Reflow: http://github.com/reenhanced/gitreflow

In your flow, how would you update a pull request branch to fix a typo? Make extra commits and normal push? and how would you update a pull request branch to contain the latest master? Merge back and forth? From the looks of it, this tool is made for the force-push flow, which doesn't suit you. See https://github.com/reenhanced/gitreflow/issues/52

This is the workflow we've adopted at my company. There are 2 types of commits, you either want to release some new feature or bit of work and do it atomically, or you want to develop the feature, fix typos and throw it between machines without a care. Is it ever going to help anyone to `git blame` a line of a file and see a commit message like "Whoops, fixed a typo!"? No. But you can't avoid those types of commits. What you can do is prevent those commits from going into the released history of the product. We develop all new features in feature branches (made _very_ easy with the commandline tool we built for it) and only after code review and acceptance testing do we squash merge it to master. This lets us put together all of the commits, typo commits, WIP commits and whatever else into a combined commit that contains all of the change