You don't say anything about what type of revision control system (RCS) you use. However, the type of problem you describe is exactly the type of problem GIT, being a distributed RCS, was created to fix.

If everybody works on the master branch, or if everybody tries to consolidate every commit made by another team to their branch instantly, GIT will not help you. But GIT will let you divide the project up in sub-tasks localized to specific areas of the code, and let a team create its own branch to work on its designated sub-task and not interfere with other areas of code. You then postpone mergeing a team's branch into the master branch until its sub-task is completed. This basically means that commits made by others will not affect you until you merge. When you merge, you consolidate everybody's work, and then everybody (for a moment) shares the code of the master branch, before continuing on their own branch.

Teams may also help each other between merges, but the general rule when you use GIT to coordinate work between distributed teams is that if somebody does some work on a sub-task or code area assigned another team, they don't commit, but submit a pull request.

IMHO, if GIT is used right it does a very good job of solving coordination problems. GIT let each team work for a long time on a separate branch and check in their code in a shared repo without effecting the build of any other team.

When sub-tasks are complete, its branch need to be merged into the master branch. If the project is well managed and the teams disciplined, merging is painless. If they are not disciplined, GIT will report conflicts which has to be solved manually. This may sometimes require some work, but is always doable.

There is no explicit mention of what RCS you use in the question. But since you talk about "pull" and "main branch" I assume you do, and maybe the one you use is GIT. If you do, and still have the problems described in the question, you need to look into how you use GIT, and how you manage your distributed teams.

You don't say anything about what type of revision control system (RCS) you use. However, the type of problem you describe is exactly the type of problem Git, being a distributed RCS, was created to fix.

If everybody works on the master branch, or if everybody tries to consolidate every commit made by another team to their branch instantly, GIT will not help you. But Git will let you divide the project up in subtasks localized to specific areas of the code, and let a team create its own branch to work on its designated sub-task and not interfere with other areas of code. You then postpone merging a team's branch into the master branch until its sub-task is completed. This basically means that commits made by others will not affect you until you merge. When you merge, you consolidate everybody's work, and then everybody (for a moment) shares the code of the master branch, before continuing on their own branch.

Teams may also help each other between merges, but the general rule when you use GIT to coordinate work between distributed teams is that if somebody does some work on a subtask or code area assigned another team, they don't commit, but submit a pull request.

IMHO, if Git is used right it does a very good job of solving coordination problems. Git let each team work for a long time on a separate branch and check in their code in a shared repo without affecting the build of any other team.

When subtasks are complete, its branch need to be merged into the master branch. If the project is well managed and the teams disciplined, merging is painless. If they are not disciplined, Git will report conflicts which has to be solved manually. This may sometimes require some work, but is always doable.

There is no explicit mention of what RCS you use in the question. But since you talk about "pull" and "main branch" I assume you do, and maybe the one you use is GIT. If you do, and still have the problems described in the question, you need to look into how you use Git, and how you manage your distributed teams.

You don't say anything about what type of revision control system (RCS) you use. However, the type of problem you describe is exactly the type of problem GIT, being a distributed RCS, was created to fix.

If everybody works on the master branch, or if everybody tries to consolidate every commit made by another team to their branch instantly, GIT will not help you. But GIT will let you divide the project up in sub-tasks localized to specific areas of the code, and let a team create its own branch to work on its designated sub-task and not interfere with other areas of code. You then postpone mergeing a team's branch into the master branch until its sub-task is completed. This basically means that commits made by others will not affect you until you merge.

Teams may also help each other between merges, but the general rule when you use GIT to coordinate work between distributed teams is that if somebody does some work on a sub-task or code area assigned another team, they don't commit, but submit a pull request.

IMHO, if GIT is used right it does a very good job of solving coordination problems. GIT let each team work for a long time on a separate branch and check in their code in a shared repo without effecting the build of any other team.

When sub-tasks are complete, its branch need to be merged into the master branch. If the project is well managed and the teams disciplined, merging is painless. If they are not disciplined, GIT will report conflicts which has to be solved manually. This may sometimes require some work, but is always doable

There is no explicit mention of what RCS you use in the question. But since you talk about "pull" and "main branch" I assume you do, and maybe the one yiu use is GIT. If you do, and still have the problems described in the question, you need to look into how you use GIT, and how you manage your distributed teams.

You don't say anything about what type of revision control system (RCS) you use. However, the type of problem you describe is exactly the type of problem GIT, being a distributed RCS, was created to fix.

If everybody works on the master branch, or if everybody tries to consolidate every commit made by another team to their branch instantly, GIT will not help you. But GIT will let you divide the project up in sub-tasks localized to specific areas of the code, and let a team create its own branch to work on its designated sub-task and not interfere with other areas of code. You then postpone mergeing a team's branch into the master branch until its sub-task is completed. This basically means that commits made by others will not affect you until you merge. When you merge, you consolidate everybody's work, and then everybody (for a moment) shares the code of the master branch, before continuing on their own branch.

Teams may also help each other between merges, but the general rule when you use GIT to coordinate work between distributed teams is that if somebody does some work on a sub-task or code area assigned another team, they don't commit, but submit a pull request.

IMHO, if GIT is used right it does a very good job of solving coordination problems. GIT let each team work for a long time on a separate branch and check in their code in a shared repo without effecting the build of any other team.

When sub-tasks are complete, its branch need to be merged into the master branch. If the project is well managed and the teams disciplined, merging is painless. If they are not disciplined, GIT will report conflicts which has to be solved manually. This may sometimes require some work, but is always doable.

There is no explicit mention of what RCS you use in the question. But since you talk about "pull" and "main branch" I assume you do, and maybe the one you use is GIT. If you do, and still have the problems described in the question, you need to look into how you use GIT, and how you manage your distributed teams.