2つの方法:

1. 全員が共同開発、ブランチ開発機能に同じウェアハウスを使用します。開発が完了したら、マージ リクエスト を作成し、コード レビュー を実施し、最後にそれをマージします。開発ブランチmerge request,进行code review,最终合并到develop分支

2. 也可以大家 fork mainrepo, 开发完毕后,建立pull request到mainrepo
   由管理代码的人进行合并

使用第二种方式的好处:

• 保护 mainrepo, 所有的合并操作必须使用pull request, 不能简单的进行merge

• mainrepo的分支更加的简洁,不会包含多余的分支

• 个人维护自己私有仓库内的分支,不会出现创建分支时重名的情况

• 个人强调贡献代码,向mainrepo

🎜🎜 mainrepo を保護します。すべてのマージ操作は pull request を使用する必要があり、単純にマージすることはできません🎜🎜 🎜🎜mainrepo のブランチはより簡潔で、冗長なブランチが含まれていません🎜🎜 🎜🎜 個人は自分のプライベート倉庫にブランチを維持しており、ブランチを作成するときに重複する名前はありません🎜🎜 🎜🎜私は個人的にコードの貢献を重視しており、より多くのコードを mainrepo に貢献します🎜🎜 🎜

そうですね、これは実際にはブランチを活用していません。
mainrepo ブランチは 1 つだけであってはなりません。 開発、機能、ホットフィックス ブランチなどは、ニーズに応じて分離する必要があります。これは、対応するブランチで開発されます。

もちろん、そうするのは問題ありません。おそらく、上司にはそうする理由があるでしょう。
ただし、この管理方法は非常に集中化されており、git の分散概念に準拠していないため、git の使用はあまり適していません。

理解した手順

• ボス作成ライブラリ

• マスター指定のボスは合体可能

• テスト環境ライブラリとして開発ライブラリを作成し、上司または指定された管理者のみがそれをマージできます。

• 各開発者は自分自身のブランチを作成し、それをリモート ファクトリにプッシュします。その後、上司またはマネージャーが開発マージに進み、上流のブランチをプッシュします。