Search Hashnode

Search posts, tags, users, and pages

Comment by j on "How do you handle back-merges?" | Hashnode

Thread

Popular posts

CommentHow do you handle back-merges?

stuff ;)

Dec 6, 2017

I would do as follows:

wait till I can merge the DEV into the QA,
delete the DEV
create a new DEV from the QA
let all feature-branches be rebased onto the new DEV.

you can ofc cross merge but I try to stick to

"merge down, rebase up"
never rebase a public branch

Dec 6, 2017

How do we handle existing PRs not yet reviewed or merged to dev if it is deleted?

stuff ;)

Dec 6, 2017

Sidhant Panda abort them and after the rebase create a new one. but I'm not even sure if that's necessary because if I remember correct, git identifies branches by "name" so, probably you don't have to do anything besides force-push the branches after the rebase.

TheSheriff

Co-Founder, Founder, Entrepreneur & Problem Solver

Dec 6, 2017

j Would it not be easier to merge QA into DEV test it oneself then merge into QA? Just so, if the QA team are busy one is not sat waiting on someone.

stuff ;)

Dec 6, 2017

well ofc a small crossmerge is possibility, my approach is more about the clean history graph.

actually the suggested cherrypick seams to be the easiest solution since the graphs should remain the same. it boils down to taste on small changes and there are still a lot of arguments of merge vs rebas