Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
just8littleBit4712142dWhat’s the best colour?
alexbrooklyn14601142dRandomly sort files, then let them overwrite eachother, zip the code and email it to everyone in the company
N00bPancakes6900142dTrial by combat!
Voxera9112142dUnlessthe company have some strict rules its in my opinion dependent on the PR.
IntrusionCM5224142d@donuts the thing is: merging can be interpretated into different ... Things.
The W3C page is a list of what git merge does. Because sometimes you'll need to get your hands dirty and imho any process you don't know in a workflow is a thing that will melt your face off.
What you're asking (and I knew that) is how the merge workflow should happen.
But I think it's wiser to understand first a lot of the background information that git provides before planning on a workflow.
Git allows a lot of things.
And handling PR's is dependent on a lot of factors.
Eg. for dedicated branches the Gatekeeper Strategy / Branch Updater Strategy handle how merges happen from A to B.
But you need to look a bit deeper to understand that you not just merge commits.
You're doing versioning. You're deciding what has priority - the upstream / feature branches or the target branch.
You're deciding wether history information needs to be intact (ff only)… can be kept with hints (merge) or can be nuked and fucked up beyond comparison (allow forced push).
These decisions play a vital role in stability.