1. 16

  2. 5


    Rebasing a feature branch on latest master is a common way to keep your branch up-to-date and your history linear. It avoids one or many merges from master into your branch and the eventual merge of that mess back into master. I’ve done this for years.

    But when you benevolently “rewrite history” like this, you must use –force to push your branch (such as when you’re ready to open a pull request). I’ve always use git push -f to push my feature branch quite sure that I’m not overwriting anything because I’m the only one working on it. But there’s no guarantee. I’ll start using –force-with-lease, just to be sure.

    1. 2

      This is exactly how I operate; until now I’ve always carefully checked the output from the push to ensure the “from” commit matches my expectation, but it’s awkward and prone to error. This is a very nice addition.

    2. 3

      The fact that there’s a flag called “force” tells me that is probably not a recommended work flow. In the context of distributed applications, i don’t think rewriting the history of a shared object is desirable.

      1. 3

        It’s really useful in situations where you push a commit and then the tests fail, or you notice a typo, and you don’t want to litter the commit history. When you’re trying to figure out why someone did something it’s much more useful to review one commit that’s a larger change than seven small commits, most of which have poor commit messages (“WIP fix test”, “Fix test”, “Typo”, “Initial work on the controller” &c).

        1. 1

          seven small commits, most of which have poor commit messages (“WIP fix test”, “Fix test”, “Typo”, “Initial work on the controller” &c)

          Ideally the committer would cherry-pick or otherwise replay/rewrite these commits into a new “this is really it” branch and pull requests that instead. I know that isn’t always the case however and if it is a world wide public repo you could get a really terrible pull request :)

        2. 3

          It’s never appropriate for master (all objects are shared). It’s fine on private feature branches (no branch-specific objects are shared - only the parent history is). You never rewrite shared history–only the history that is local to your private branch.

          1. 1

            Only if that branch wasn’t pushed before. If it’s out there, it’s out there. I understand the reason people do it, and i understand in which cases it’s okay to do it (by that logic); i just don’t agree.

            1. 1

              Sure, once it’s pushed, it’s public. But that doesn’t mean anyone is basing their commits off it. It’s a process thing. Also, if you pushed to a private fork that no one has access to, then you’re guaranteed to be able to safely force push. --force-with-lease makes any force push safer in all of these cases.

              Lots of options to build a team’s process around.

        3. 2

          Seems a bit excessive to always force push IMO, even with --force-with-lease. Or did they mean that they always used --force-with-lease only when they otherwise would force push?

          1. 3

            only when they otherwise would force push

            This is how I read it.

            It would make no sense to always force push :)