團隊內部使用gitlab的fork&pull request模式的不解

Question

如題。
現在公司使用的是gitlab，大概使用流程入下：
1.老闆創建一個主倉庫mainrepo
2.每個成員fork一份mainrepo
3.在自己fork出來的程式碼裡做開發
4.開發完成後發出合併請求，等待老大合併代碼
5.如果主倉庫有新更新，先fetch,然後合併到自己的倉庫裡

我覺得這樣做好麻煩啊，而且git的分支優勢體現的不是很明顯。
大家覺得這種工作模式怎麼樣？

Answer 1

兩種方式:

1. 大家使用同一個倉庫進行合作開發,分支開發功能,開發完畢,建立merge request,进行code review,最後合併到develop分支

2. 也可以大家 fork mainrepo, 开发完毕后,建立pull request到mainrepo
   由管理程式碼的人進行合併

使用第二種方式的好處:

• 保護 mainrepo, 所有的合并操作必须使用pull request, 不能簡單的進行merge

• mainrepo的分支更加的簡潔,不會包含多餘的分支

• 個人維護自己私有倉庫內的分支,不會出現創建分支時重名的情況

• 個人強調貢獻代碼,向mainrepo貢獻更多的代碼

Answer 2

嗯，這樣確實沒發揮出分支的優勢。
不應該只有一個mainrepo分支。 應依需求分出develop，feature,hotfix分支等。這樣在對應的分支上開發。

Answer 3

這樣做當然是可以的，你們老大這麼做大約也有他的原因。
不過這種方式管理就很集中，不太符合 git 分散式的思路，所以使用 git 並不太匹配。

Answer 4

我理解的步驟

• 老大創建庫

• master 指定 老闆merge

• 建立 dev庫，作為測試環境庫，也只有老大或指定管理才能merge。

• 各個開發創建自己的分支，然後push到遠端廠庫，然後老大或管理，到dev merge，push上來的分支。