Confusion about using gitlab's fork&pull request mode within the team

Question

As mentioned.
The company now uses gitlab, and the approximate usage process is as follows:
1. The boss creates a main warehouse mainrepo
2. Each member forks a copy mainrepo
3. in oneself for Do development in the code from k
4. After the development is completed, issue a merge request and wait for the boss to merge the code
5. If there are new updates in the main warehouse, first fetch and then merge them into your own warehouse

I feel like this is very troublesome, and the advantages of git branches are not very obvious.
What do you think of this working model?

Answer 1

Two ways:

1. Everyone uses the same warehouse for collaborative development, branch development functions, after development is completed, establishedmerge request,进行code review, and finally merged into the develop branch

2. You can also merge it fork mainrepo, 开发完毕后,建立pull request到mainrepo
   by the person who manages the code

Benefits of using the second method:

• Protection mainrepo, 所有的合并操作必须使用pull request, cannot simply merge

The branches of

• mainrepo are more concise and do not contain redundant branches

• Individuals maintain branches in their own private warehouses, and there will be no duplicate names when creating branches

• I personally emphasize on contributing code and contribute more code to mainrepo

Answer 2

Well, this really doesn’t take advantage of branches.
There should not be only one mainrepo branch. Development, feature, hotfix branches, etc. should be separated according to needs. This is developed on the corresponding branch.

Answer 3

Of course it’s okay to do this. Your boss probably has his reasons for doing this.
However, this method of management is very centralized and does not conform to the distributed idea of ​​git, so using git is not very suitable.

Answer 4

The steps I understand

• Boss Creation Library

• Master designated boss can merge

• Create a dev library as a test environment library, and only the boss or designated manager can merge it.

• Each developer creates his or her own branch, then pushes it to the remote factory, and then the boss or manager goes to dev merge and pushes the upstream branch.