47 | チームのプロジェクトを作成する#
リポジトリを作成する際、オーナーは組織を選択できます。
- チームを追加し、権限を付与できます。
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
eg.
ブランチマージ戦略の設定：Settings——Options——Merge Button、全 3 種類。
1）非線形：マージの方法で統合する（ git merge 、⚠️ではなく git merge --squash ）
eg.
2）線形：統合するすべてのコミットを 1 つのコミットにまとめ、ターゲットブランチに追加する（ git rebase 、⚠️ではなく git merge --squash ）
eg.
3）線形：統合するすべてのコミットをターゲットブランチに追加する（ git rebase ）
eg.
❗️：
- GitHub 上にプルリクエストがある場合、管理者は上記の 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 にリリースするには？#
Release 機能：コードをバイナリの圧縮ファイルにパッケージ化し、テストやインストールを便利にします。
- CI スクリプト（例：.travis.yml）の before deploy と deploy 部分を設定；
- token などを設定します。
56 | プロジェクトに詳細なガイド文書を追加するには？#
Wiki 機能。
優れた wiki ライブラリを参考にし、ローカルに引き出して、リポジトリの対応するWiki アドレス（プロジェクト名の後に.wiki を追加）にプッシュすることで、自分の説明文書を作成できます。
- プロジェクトの Settings——Options で Wikis を有効にする必要があるかもしれません。
これは非常に実用的な章で、主に GitHub に焦点を当てています。次の章では Gitlab を一緒に見ていきましょう～