• RecluseRamble@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    5
    ·
    edit-2
    7 months ago

    Just remember to not combine it with force push or you’re in for some chaos (rewriting history team members have already fetched is a big no-no).

      • expr@programming.dev
        link
        fedilink
        arrow-up
        3
        ·
        edit-2
        7 months ago

        Or, you know, on your own feature branch to clean up your own commits. It’s much, much better than constantly littering your branch’s history with useless merge commits from upstream, and it lets you craft a high-quality, logical commit history.

        • RecluseRamble@lemmy.dbzer0.com
          link
          fedilink
          arrow-up
          1
          ·
          7 months ago

          Of course it has its uses. I didn’t mention them because the guy just learned about rebase - it’s unlikely to be applied flawlessly from the start.

          • expr@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            7 months ago

            I was replying to the other comment, not yours. Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.

            Rebasing is really not a big deal. It’s not actually hard to go back to where you were, especially if you’re using git rebase --interactive. For whatever reason people don’t seem to get that commits aren’t actually ever lost and it’s not that hard to point HEAD back to some previous commit.

            • RecluseRamble@lemmy.dbzer0.com
              link
              fedilink
              arrow-up
              1
              ·
              7 months ago

              I was replying to the other comment, not yours.

              I know. Answered anyway because I thought of the same thing as you.

              Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.

              I like to rebase after fetching and before pushing. IMO that’s the most sensible way to use it even in teams that generally prefer merge. It’s also not obvious to beginners since pull is defaulted to fetch+merge.

              • expr@programming.dev
                link
                fedilink
                arrow-up
                1
                ·
                7 months ago

                Ah gotcha.

                like to rebase after fetching and before pushing. IMO that’s the most sensible way to use it even in teams that generally prefer merge.

                What do you mean? Like not pushing at all until you’re making the MR? Because if the branch has ever been pushed before and you rebase, you’re gonna need to force push the branch to update it.

                Personally I’m constantly rebasing (like many times a day) because I maintain a clean commit history as I develop (small changes to things I did previously get commits and are added to the relevant commit as a fixup during interactive rebasing). I also generally keep a draft MR up with my most recent work (pushing at end of day) so that I can have colleagues take a look at any point if I want to validate anything about the direction I’m taking before continuing further (and so CI can produce various artifacts for me).

                It’s also not obvious to beginners since pull is defaulted to fetch+merge.

                Yeah, pull should definitely be --ff-only by default and it’s very unfortunate it isn’t. Merging on pull is kind of insane behavior that no one actually wants.

                • RecluseRamble@lemmy.dbzer0.com
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  7 months ago

                  What do you mean? Like not pushing at all until you’re making the MR? Because if the branch has ever been pushed before and you rebase, you’re gonna need to force push the branch to update it.

                  Not everyone works in large orgs that require pull requests. We have a dev branch multiple devs push to and just branch off for test phase. So I commit locally (also interactive rebasing when fixing stuff from earlier). When I’m ready to push, I fetch, rebase and push. I never force push here.

                  • expr@programming.dev
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    7 months ago

                    Uh, it’s definitely a bad idea to be concurrently developing on the same branch for a lot of reasons, large org or not. That’s widely considered a bad practice and is just a recipe for trouble. My org isn’t that huge, and on our team for our repo we have 9 developers working on it including myself. We still do MRs because that’s the industry standard best practice and sidesteps a lot of issues.

                    Like, how do you even do reviews? Patch files?

        • Transtronaut@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          1
          ·
          7 months ago

          You can do all that without force push. Just make a new branch and do the cleanup before the first push there. Allowing force push just invites disaster from junior developers who don’t know what they’re doing. If you want to clean up after them, that’s your business, I guess.

          • expr@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            7 months ago

            That’s exactly the same thing. A branch is nothing more than a commit that you’ve given a name to. Whether that name is your original branch’s name or a new branch’s name is irrelevant. The commit would be the same either way.

            A junior cannot actually do any real damage or cause any actual issue. Even if they force push “over” previous work (which again, is just pointing their branch to a new commit that doesn’t include the previous work), that work is not lost and it’s trivial to point their branch to the good commit they had previously. It’s also a good learning opportunity. The only time you actually can lose work is if you throw away uncommitted changes, but force pushing or not is completely irrelevant for that.

      • zalgotext@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        ·
        7 months ago

        Force pushes are perfectly safe if you’re working on your own branch, and even if you’re sharing a branch, you can still force push to it as long as you inform and coordinate with whoever else is working on that branch.