We have a testing branch and me and my coworkers will pull off of testing to do our branches. So testing > feature1, testing > feature2

Then as commits roll through, we merge them into testing.

However during the sprint, people are pulling and merging into testing at different times.

So at the end especially near a launch, we have some code that seems to be older rewriting the newer changes because say someone was working on feature1 branch which on header.js and someone was working on feature2 on header.js. If they change the same sort of area like the same html attributes or function, sometimes the branch that pulled earlier (say feature1 which has older code) will then come out the winner at the end.

I assume it's because when it's merged, someone is not doing a good job making sure which conflicts should be accepted. If feature1 got merged into testing first, then when feature2 gets merged they have to decide between incoming and current changes.

Code changes are additions and deletions usually aren't a problem. It usually is code that is touched by 2 people at different times in the same line or function.

Well as someone who is doing the merging but didnt work on feature1 OR feature2, how would they know which one to accept as the newest?

This happened to two of my branches which had maybe 20-30 files touched. And I had to use git diff to track down every single code and see what's not being updated.

So my questions are:

1. How to do a better job preventing this from a merging practice? It's coming from someone on the team that's not me
2. How do I fix this without using git diff branch1..branch2 and then individually changing the code that's older? I use gitlens and its easier to see but I would still have to figure out which files were touched in feature2, then look up and compare those to testing and see parts were not accepted.

Is it possible to just re-merge feature2 AGAIN and have it override everything in testing or settle merge conflicts again?

CodePudding user response：

So at the end especially near a launch, we have some code that seems to be older rewriting the newer changes because say someone was working on feature1 branch which on header.js and someone was working on feature2 on header.js. If they change the same sort of area like the same html attributes or function, sometimes the branch that pulled earlier (say feature1 which has older code) will then come out the winner at the end.

In a case like this where two people edit the same line of code on two different branches, you will get a merge conflict after you merge both of them. This merge conflict often must be fixed manually before the merge is completed. To fix this, you will need to communicate between team members. One way to facilitate that is for both team members to work together on all merges, so that both changes are correctly accepted into the final merge.

Is it possible to just re-merge feature2 AGAIN and have it override everything in testing or settle merge conflicts again?

No, a "re-merge" isn't possible. After this already happened, you will need to create a new branch and make the necessary changes.