How to correctly resolve conflicts in the dev branch for two branches in development?

Question

git

We are working on a project according to the master + dev scheme. The development of any task begins with the creation of a branch from master . After development is complete, the branch is pushed to dev for testing. If everything is fine, then the same branch (not dev) is poured into master.

Because of this scheme, dev gradually lags behind master and is ahead of it in some of its commits. Work is being done on GitLab.

Sometimes situations arise that development is being carried out in one branch by one developer, in another by another. For example, it happened that the same file was affected, then the conflict resolution is performed, but the conflict resolution creates a Merge of the dev branch into the conflicting branch. Accordingly, when you try to merge this branch with master in the future, a bunch of unnecessary commits from dev are pulled up, which are not needed on the master. Is there any way to avoid such situations? How to solve such situations if the conflict was resolved in this way and the branch jumped ahead by 10-20 commits?

Answer 1

you have a bad system (although I myself spent 4 months in such a project)
dev - this is for development, not for testing. one developer - one dev. no one merges other people's maidens, if it's really necessary - through a temporary branch with the necessary commits,
and the master is divided into two parts - staging and production

Answer 2

Use Git flow or Github flow approaches

Answer 3

1. When working on a long-lived branch, the developer simply needs to periodically merge from the master into his own branch of change (you can use a rebase or a merge). Then when pushing back to the master, there will either be no conflicts, or they will be minimal. 2. The correct architecture of
the project allows you to reduce conflicts, since the code must be separated functionally, and two features with different functionality should not conflict

Answer 4

before merging the dev branch, you can prepare it, for example, do the squash
operation , there is usually an option before merging, automatically do the squash.

Answer 5

Branch always from the dev branch. And fill in the written features there. After testing, pour dev into master. The master is always only the tested dev and nothing else.
In essence, you will have dev as a staging branch (as suggested by Antonio Solo )

when you try to merge this branch with master in the future, a bunch of unnecessary commits from dev are pulled up, which are not needed on the master

Don't put too much in there. The developer has spun off from dev/staging and is working. He can make a dozen branches and hundreds of commits, but let neat commits be good to upload back.

Answer 6

the same file was affected, then conflict resolution is performed, but conflict resolution creates a Merge of the dev branch into the conflicting branch.

Does not create, conflicting branches by themselves, but resolve the conflict in the dev branch. When creating release branches from dev, this would be sufficient. But, in your case: merge the first branch into master - everything is ok, but the second one will again conflict, but with master, this is solved by merging the updated master into this branch. And yes, discrepancies between dev and master are quite possible if 2 merges were performed differently, so merge master into dev after such manipulations.