1. 9
  1.  

  2. 1

    This workflow is something which I usually advocate, and most of the time people are more than happy to pick it up. There have been cases, though, where it has caused serious issues. These issues have always been around and the force-pushing which is inevitable when interactively rebasing. I’ve wasted many hours when a dev has accidentally force-pushed an old ref to master, and many more hours when people have merged on top of the old ref.

    My experience is that this workflow is great in small teams, but trying to make it work in medium and large teams is usually not worth it. Obviously there are exceptions – if everybody in a large team is very Git-savvy, then it will work fine. But this is often not the case.

    1. 1

      I’ve wasted many hours when a dev has accidentally force-pushed an old ref to master, and many more hours when people have merged on top of the old ref.

      That’s what we are trying to fix with Mercurial evolve.

      1. 1

        The rule of thumb that we use is that you don’t force push to any shared branches. By shared I mean branches with multiple people contributing to it. If I’m working on adding a feature I’ll create a branch and continuously rebase it on top of master as master evolves. When I am ready to share it I’ll make sure the git commits are “clean” and then ask someone to review/merge it. At the point where I ask for other contributors it’s shared and I don’t rebase. We usually consider master a shared branch so we never change it’s history once published.