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
Easy answer: both
Harder answer: consistent merge conflicts are a result of poor architectural factoring, overstaffing, lack of planning, unskilled hiring, or all of the above.
Voxera893829dIf done right you will only ever have merge conflicts either when rebasing your own branch onto develop and then only between de development branch code and your own, or when back merging fixes on the release branch if you use that.
And those conflicts should usually be quite easy unless you have made some major refactoring.
At least that is what I and the team I am on are aiming for.
There are occasional mishaps sure, but they are quite rare.
Mine. End of story
I feel very anxious at every merge conflict. The logic is usually simple : the merge conflict would happen of someone added changes in the same file as i did, so need to keep them both .intellij ui helps a lot for this. but am always afraid if accidentally missed adding the changes coming from the remote and went forward with the merging. Hasn't happened yet but definitely could happen in future
My face whenever I try to figure out which changes to accept during merge conflict:
Voxera893828d@yowhatthefuck That would depend.
For example if you both changed the same internal logic in a class odds are that you either just want to keep one or actually incorporate the two changes to keep the function of both while not keeping either of the actual codes. Those are often the most fun(scary/difficult).
It can also be that you both changed some interface and have to find out if this is used in any external code.