Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Review Suggested Edit

You can't approve or reject suggested edits because you haven't yet earned the Edit Posts ability.

This thing has a technical side and an organizational side.
The technical side is very simple: there we have branches and a merge. There is no "review", that is not a strict git terminology. "Review" is the terminology of the professional systems, restricting pushes to various branches. For example, normally it is not useful, if anyone can push into a branch, on which everything will be deployed into production on the spot.
And, the rules are clear. Roughly these: if there are no conflicting changes, the merge is automatic. If there are, then the guy doing the merge, has to solve the conflicts (i.e. use his natural intelligence to determine the expected result). Seldom it happens that there is no such solution: for example, if team1 wants X=Y, team2 wants X=Y+1, then you need to call a meeting.
More important is the organizational side.
On the organizational side, the answer is that you **do not merge two branches with fresh changes**. It could happen, but in practice it never does. Instead, you have a merge target, some "main", "master" or more often "dev" branch, where you are merging both branches.
Thus, the process is:
1. Review1 runs and merges (or throws back to the team) branch1 to "dev".
2. Review2 runs and merges (or throws back to the team) branch2 to "dev".
~~There might be a problem is branch1 was already merged. Then the merge of branch2 might cause a merge conflict.~~
~~**In this case, as "dev" branch has the central role, it is something what we could call "consent", task of the team2 is to alter their branch2 to become clean mergeable to "dev".**~~
~~Again, there might be the problem I mentioned before - it is possible that there is a direct conflict of interest between the teams, and no solution exists.~~
These happen rarely, most often if at least one of the teams did major changes without consent of the others.
~~The typical case is that the merge is trivial (knowing the code, you simply see, what is the intent to do, so you can also say, what is what fulfills both teams goal).~~

This thing has a technical side and an organizational side.
## The technical side
The technical side is very simple: there we have branches and a merge. There is no "review;" that is not strictly Git terminology. "Review" is the terminology of the professional systems, restricting pushes to various branches. For example, it is not normally useful if anyone can push onto production-deployable branches at will.
The rules are clear. Roughly these: if there are no conflicting changes, the merge is automatic. If there are, then the guy doing the merge, has to solve the conflicts (i.e. use his natural intelligence to determine the expected result). Seldom it happens that there is no such solution: for example, if team1 wants X=Y, team2 wants X=Y+1, then you need to call a meeting.
## The organizational side
On the more important organizational side, the answer is that you **do not merge two branches with fresh changes**. It could happen, but in practice it never does. Instead, you have a merge target—some "main", "master", or more often "dev" branch—where you are merging both branches.
Thus, the process is:
1. Review1 runs and merges (or throws back to the team) branch1 to "dev".
2. Review2 runs and merges (or throws back to the team) branch2 to "dev".
There might be a problem where branch1 was already merged. Then the merge of branch2 might cause a merge conflict.
**In this case, as "dev" branch has the central role, it is something what we could call "consent", the task of the team2 is to alter their branch2 to become cleanly mergeable to "dev".**
Again, there might be the problem I mentioned before – it is possible that there is a direct conflict of interest between the teams, and no solution exists.
These happen rarely, most often if at least one of the teams did major changes without consent of the others.
The typical case is that the merge is trivial (knowing the code, you simply see the intent, so you can also say what fulfills both teams' goals).

Communities

Review Suggested Edit