1114

submitted 7 months ago by JPDev@programming.dev to c/programmer_humor@programming.dev

233 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] RecluseRamble@lemmy.dbzer0.com 5 points 7 months ago* (last edited 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).

[-] Transtronaut@lemmy.blahaj.zone 1 points 7 months ago

Facts. Force push belongs in Star Wars, and nowhere else.

[-] expr@programming.dev 3 points 7 months ago* (last edited 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.

[-] Transtronaut@lemmy.blahaj.zone 1 points 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 1 points 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.