• F04118F@feddit.nl
    link
    fedilink
    arrow-up
    7
    ·
    1 year ago

    You can always revert (i.e. undo in a new commit) the faulty commit. That will keep the history. This meme is not just about pushing straight to master, it’s about push --force which overwrites the remote branch completely, changing history.

    • BeigeAgenda@lemmy.ca
      link
      fedilink
      arrow-up
      4
      arrow-down
      1
      ·
      1 year ago

      Sometimes there’s only the nuclear option left, I have only done it a few times, someone merged a major refactoring and we ended up reverting by changing history.

      I have also observed that when you revert with git revert and then merge back some time later git can get confused about if a commit was merged or not.

      Mind you we didn’t use git flow or other smart processes to our own regret.

    • jcg@halubilo.social
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      What happens when you want to merge again? Won’t it say already up to date or something cause the commits are already there?

      • Hexarei@programming.dev
        link
        fedilink
        arrow-up
        5
        ·
        1 year ago

        Revert doesn’t just move head back, it creates reversal commits. As such, merging again can happen since the changes are present and require a merge commit

      • Gecko@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        You could just rebase your develop branch to a commit before the merge and have a different commit history, or actually do it properly and have squash merges.

        • Double_A@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          do it properly and have squash merges

          If you have big features that deletes a lot of maybe important commit history.