• Everyday0764@lemmy.zip
    link
    fedilink
    arrow-up
    22
    ·
    6 days ago

    in the projects i work in i always try to force semi linear history to avoid all of this, never merge (unless it’s the MR) always rebase.

    this leaves a very readable history, with each feature branch highlighted and no mixture in the commits…

    i haven’t found any downside yet… maybe that some ci/cd are built to push to main, but making them do branch pr automerge is not that difficult

    • theneverfox@pawb.social
      link
      fedilink
      English
      arrow-up
      5
      ·
      6 days ago

      How does a rebase play out? I know what it is conceptually, but usually just do the difficult merges myself

      • Ephera@lemmy.ml
        link
        fedilink
        English
        arrow-up
        8
        ·
        6 days ago

        A rebase rewrites the history of your branch, so that it’s as if you just branched off and then coded all your changes in one sitting.

        It will go through each of your commits and try to apply them one after another. If something changed on the base branch that conflicts with your changes, it will prompt you to adjust your commit. You adjust it so that looks as if you just coded it on top of the base branch.

        When you have lots of commits on your branch, this can mean that while you’re rebasing, you have to then also change your following commits which happened to touch the same lines as a previous commit. This can mean additional, stupid work.

        As such, a workflow using rebases (“trunk-based workflow”) works best, if you can rebase often and merge back early. You won’t get merge conflicts when merging back, nor merge commits, because you resolved these while rebasing.

        In particular in smaller teams where you have tight-knit communication, this workflow is absolutely stellar. It completely bypasses so many pain points that folks have with Git.
        Merge conflicts are significantly reduced when you merge often and a trunk-based workflow removes the ceremony that typically prevents teams from doing just that.

    • SleeplessCityLights@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      6 days ago

      I have made worse, I used to do a cascading merge everyday to move stuff from dev branches to staging to production. Then I did a merge in the opposite direction for a small selection of branches so they could get their updates from staging. Feature branches were rebased as needed.

  • AnimalsDream@slrpnk.net
    link
    fedilink
    English
    arrow-up
    7
    ·
    6 days ago

    At least twelve lanes on a single track. If I recall, the cool keytar instrument you could get for… was it Rock Band 3? might be able to make a song with that track in it. Not sure how many other games or instruments could do that though.

  • dragnucs@lemmy.ml
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    6 days ago

    This in fact is vert good d’or large trams that work on 3 to 7 featyres or bug fixes in thé aame tome. Simple, ans vert easy to trace.

    I’ve se en much much worse where you can’t keep track of where branches come from and where they go, and even if you do, you cannot predict what they can contain.