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 | project を使って 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 部分を設定；
- トークンなどを設定します。
56 | プロジェクトに詳細なガイド文書を追加するには？#
Wiki 機能。
優れた wiki ライブラリを参考にし、ローカルにクローンして、リポジトリの対応するWiki アドレス（プロジェクト名の後に.wiki を追加）にプッシュすることで、自分の説明文書を作成できます。
- プロジェクトの Settings——Options で Wikis を有効にする必要があるかもしれません。
これは非常に実用的な章で、主に GitHub に焦点を当てています。次の章では Gitlab を一緒に見てみましょう～