47 | チームプロジェクトの作成#
リポジトリを作成する際には、Owner は組織を選択します。
- Team を追加して権限を割り当てることができます。
48 | 自分のチームに適したワークフローを選択する方法#
考慮すべき要素：チームの構成、開発設計能力、製品の特徴、プロジェクトの難易度。
1）トランクベースの開発方法（Google、Meta）
- 特徴：変更は直接トランクに統合され、迅速なイテレーションが可能です。
- 適用条件：
- チームのシステム設計と開発能力が強く、有効なフィーチャースイッチングメカニズムがあり、機能スイッチングの能力があります。
- チームメンバーの能力が高く、開発が簡単で独立しており、コンポーネントのアップグレードコストが低い、つまりコンポーネントの開発です。
2）Git Flow
- 特徴：手順が複雑で、やや煩雑です。
- 適用条件：チームがトランクベースの開発能力を持っていない、予定されたリリースサイクルがあり、製品の品質要件が高く、厳格なリリースプロセスを実行する必要がある場合。
3）Github Flow
- 特徴：master をメインラインとして使用し、Git Flow よりも厳格です。
- 適用条件：チームがトランクベースの開発能力を持っていない、随時統合と随時リリースが必要な場合。
4）Gitlab Flow（+ プロダクションブランチ）
- 特徴：master ブランチ + プロダクションブランチ、リリースはまずプロダクションブランチにデプロイする必要があります。
- 適用条件：チームがトランクベースの開発能力を持っていない、正確なリリースタイミングを制御できない場合。
5）Gitlab Flow（+ 環境ブランチ）
- 特徴：master ブランチ + 環境ブランチ + プロダクションブランチ、テストするために環境ブランチにデプロイし、テストが合格したらプロダクションブランチにデプロイします。
- 適用条件：チームがトランクベースの開発能力を持っていない、各テスト環境の検証を個別に通過する必要がある場合に使用します。
6）Gitlab Flow（+ リリースブランチ）
- 特徴：master ブランチ + 複数のリリースブランチ、異なるバージョンを管理できます。
- 適用条件：チームがトランクベースの開発能力を持っていない、異なるバージョンを公開およびメンテナンスする必要がある場合。
まとめ：各ワークフローには独自の特徴がありますが、いくつかの類似点もあります。チームは自分に適したワークフローを選択すればよいです。
49 | 適切なブランチ統合戦略を選択する方法は？#
バージョンツリーの進化：Insights——Network
例：
ブランチマージポリシーの設定：Settings——Options——Merge Button、3 つのオプションがあります。
1）非線形：マージを使用して統合する（ git merge ，⚠️ git merge --squash ではありません）
例：
2）線形：マージするすべてのコミットを 1 つのコミットにまとめて、ターゲットブランチに追加する（ git rebase ，⚠️ git merge --squash ではありません）
例：
3）線形：マージするすべてのコミットをターゲットブランチに追加する（ git rebase ）
例：
❗️：
- Github に Pull Request がある場合、管理者は上記の 3 つのオプションのいずれかを選択してマージすることができます（Github で実行）。
- 後の 2 つのオプションでは、ブランチが出会うことはありません。
50 | 要件とタスクの追跡に issue を使用する方法#
Issues
- 特徴：ステータスは open と close に分かれており、Labels で分類され、Milestone で大きなバージョンの変更を示します。
- テンプレートを設定できます：Feature、Bug、カスタム。優れたサードパーティライブラリを参照してください。
- 役割：チームのコミュニケーションを促進し、コミュニケーションの詳細を記録します。
PS：優れたライブラリの例：vuejs/vue——Issues
51 | プロジェクトを使用して issue を管理する方法#
Projects
- カンバン機能を作成して管理を容易にします。
- Issue、PR、CR などに対してテンプレートを設定できます。
52 | プロジェクト内でのコードレビューの実施方法#
Settings——Branches——Add rule（Branch protection rules）
- 適用するブランチパターンを指定します。
- コードレビューなどの必要なルールにチェックを入れます。
例：
53 | チーム協力時の複数ブランチの統合方法#
（統合結果は第 49 節を参照してください。この節では競合の解決方法について説明します）
シナリオ：1）Beijing->master；2）Shanghai->master。⚠️：2）は競合が発生します
- マージ
Shanghai->master の競合を処理する方法：
Github はまず master を Shanghai にマージして競合を解決し、新しいコミットを作成してから master にマージします。
- スカッシュ
Shanghai->master の競合を処理する方法：
Github はまず master を Shanghai にマージして競合を解決し、新しいコミットを作成してからスカッシュマージを行います。
- リベース
Shanghai->master の競合を処理する方法：Github はマージできず、競合の解決で止まります。
手動で以下の状態に戻ります。
Shanghai をローカルでリモートの master をベースにリベースし、競合を解決します（4 回、Shanghai の 4 つのコミット；より良い方法： git rerere ，公式ドキュメント）
ローカルの Shanghai ブランチをリモートに強制的にプッシュします（fast-forwards ではないため）
最後にリベースマージを行います：
7 つのコミットがクローンされたようなものです～
❗️見た目は多くの手間がかかるように見えますが、別の視点から見ると、Author と Committer の責任を明確に区別しています。
54 | 統合の品質を確保する方法は？#
- サービスの設定
- Marketplace で見つけることができます。例：Travis CI、codecov など。プロジェクトの Setting--Integrations で設定できます。
- それ以外にも、個人の Setting-- Developer settings--OAuth Apps でサードパーティサービスを設定したり、GitHub Apps で独自のサービスやオープンソースのサービスを追加したりすることができます。
- ブランチ保護ルールの設定
- Settings--Branches--Branch protection rules で設定します。第 52 節を参照してください。
55 | 製品パッケージを GitHub に公開する方法は？#
リリース機能：コードをバイナリ圧縮ファイルにパッケージ化して、テストやインストールを容易にします。
- CI スクリプト（.travis.yml など）の before deploy と deploy 部分を設定します。
- トークンなどの設定。
56 | プロジェクトに詳細なドキュメントを追加する方法は？#
Wiki 機能。
優れた Wiki ライブラリを参照して、ローカルにクローンし、リポジトリに対応するWiki アドレス（プロジェクト名の後に.wiki が追加されます）にプッシュすることで、独自の説明文書を作成できます。
- プロジェクトの Settings——Options で Wiki を有効にする必要があるかもしれません。
これは非常に実用的な章であり、主に Github に関連しています。次の章では、一緒に Gitlab を見てみましょう～