2

We have a develop branch.
Every new feature gets created on a branch that runs off the develop branch.
Then a pull request is made to the develop branch.

This triggers our CI/CD and slowly but surely makes it way to the master branch and deployed live after all the quality checks and tests are validated.

Here's our issue:

  • Developer1 creates a branch off develop for feature 1.

  • Developer 2 creates a branch off develop for feature 2.

  • Then, developer1 creates a pull request that includes an updated composer.json and composer.lock.

  • His PR gets approved and merged.

  • Then, developer2 tries to do a pull request to the develop branch but there's a conflict, because the composer.json and composer.lock were modified on the develop branch by developer1.

What's the best way to go about this?

Should developer2 first merge the develop branch back into his feature2 branch?

Or is there a better way of managing composer introduced merge conflicts?

0

I will suggest what I follow in order to neglect these issue. I have a experience of using git almost 4 years. Following is my approach

There should be one parent branch of git. You can name it production or Development depends on your naming sense. In this branch there should be live state of code of system. Whenever any developer make a branch it should be inherit from parent branch. When developer finish his/her work he/she should merge his/her branch to parent branch and push it. So when other is going to merge his branch he should first checkout the parent branch (production or Development) and pull it so the changes of other developer would appear to him/her after that he should merge his/her branch and push it in to parent branch.

Another way of doing it or avoiding the conflict is that developer may merge the parent branch (production or Development) in his/her branch so his/her has the same state of parent branch after other developer already merge his/her branch in to parent branch (production or Development) then developer merge his/her branch to parent branch.

These are my practises I hope this will help

0

As per my practice till now there should be total 2 branches on the remote of git that is the master branch (contains the code which is running on the live site) & the development branch (contains the code which is running on the development site (used for the testing & all)).

  • Now at the developers end what they can do is just take the pull of that development branch into their local development branch.
  • For the development of functionality they will create a branch locally make the changes there & commit into that particular local branch that is made for the functionality.
  • Now move to the local development branch take the pull of remote development branch, now merge the functionality branch's code into the local development branch & push it to the remote development branch
  • After testing the code & functionality there we can simply push it to the remote master & from the remote master we can take the pull to the live sites(local master branch of live site).

This way I think the conflict will not come there! If there is something else then please let me know

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.