38

First I wanna say how grateful I am that devRant exists, because my friends either don’t understand this vocab or don’t care lol.

Last week I worked on a pretty large ticket, opened a PR with 54 file changes. Just to follow standards I set the PR milestone to a future release version, but the truth is I didn’t care which version this work ended up in— I just needed it to go into the develop branch asap.

Since it was a large PR there was some expected discussion that prolonged its merging, but in the meantime I started a second branch that depended on some of the work from this branch. I set the new branch’s upstream to develop, fully expecting my PR to merge into develop, since that’s what I set the PR base to.

I completed all the work I could in the new branch, and got two colleagues to approve the initial PR so it would be merged into develop, I could add the finishing touch and get this work done seamlessly before the week was over. They approved, it got merged, I pulled develop, and… my work wasn’t there. I went to look at my PR and someone had changed the base branch to a release branch. It was my boss, who thought he was helping. (Our bosses don’t actually work on the same team as us, so he didn’t know. it’s weird. We have leads that keep track of our work instead.)

I messaged him and told him I really needed this in develop, knowing our release branch won’t be in develop for probably another week. I was very annoyed but didn’t wanna make him feel too bad so I said I’d just merge the release branch into my new branch. So many conflicts I couldn’t see straight. His response was “yeah and you’ll probably have a bunch of package manager conflicts too because that’s in that release.” He was right— I have so many package manager conflicts that I can’t even see how many compiler conflicts there are. I considered cherry picking my changes, but the whole reason I set develop as my upstream was to avoid having any conflicts since I’m working in the same functions, and this would create more.

So I could spend the next (?) days making educated guesses on possibly a thousand conflict resolutions, or I can revert my release branch merge and quietly step back and wait for the release branch to be merged into develop.

I’m sure cherry picking is the best option here but I’m genuinely too annoyed lol, and fortunately my team does not care to notice if I step back and work on something else to kill time until it’s fixed automatically. But I’m still in dire need of a rant because my entire plan was ruined by a well-meaning person who messed with my PR without asking, so here is that rant and I thank you for your time.

Comments
  • 19
    Just abort this merge and make another pr with the title starting “DAVE: do NOT fuck with this PR” the other reviewers will have to approve this new request, but they have already looked a the changes so that will only take a minute.
  • 8
    @jeeper on the other hand, making the boss look bad when he made a mistake might not be the best move.

    Especially if its otherwise a good boss.

    But you should look into having stricter routines established so that this does not happen again.
  • 4
    Your merged branch still exists right? Can't you open another pr from same branch to dev branch? Am I missing something?
  • 2
    As someone who created too many problems for myself when learning git. Honestly i think atleast if the branch wasn’t merged you could have done reflog and hard reset but looks like, as you mentioned, cherry-picking is the only option! Salute!!
  • 0
    @hack Yeah this sounds like the best option. Or somehow lift those commits onto develop as well
  • 4
    If you have your branch still locally you can easily fix it by doing a new PR. People changing your PR without previously attaining your explicit permission is almost always wrong.
    You can tell your boss i said so.
  • 0
    @Voxera yea you definitely want to do what fits your workplace. Depending on culture doing as I suggested can range from laughable to fireable
  • 1
    @jeeper I’m with you. I think..

    Revert the merge into release.. since it sounds like you don’t want this going out before it’s ready, and get a new pr into the correct branch.

    Your shop seems to have an interesting branching strategy.. why would you merge into a release branch before it’s in master (or in your case development) ?
Add Comment