|
Gitバージョン管理は、これまでのあらゆるバージョン管理手法よりも優れています。しかし、多くの組織では、プロセスが過度に煩雑になったり複雑になったりする傾向があります。この問題は、他のバージョン管理システムから移行したばかりの組織で特に顕著です。 この記事では、GitLabワークフローのプロセスを簡素化・合理化するための11のルールを概説します。これらのルールの主なメリットは（そして願わくば）、プロセスを合理化し、より効率的で明確な成果を生み出すことです。 改善の余地は常に存在し、すべての改善はあくまでも草稿段階です。皆様のご協力をお待ちしております！フィードバックやご提案は大歓迎です。 1. 機能ブランチを使用し、マスターに直接コミットしないでください。 例えばSVNから移行してきた場合は、トランクベースのワークフローに慣れているでしょう。Gitを使用する場合は、マージ前にコードレビューを完了できるように、すべての作業にブランチを作成する必要があります。 2. マスター上のコミットだけでなく、すべてのコミットをテストします。 CIを、マスターにマージされたコミットのみをテストするように設定している人がいます。これは遅すぎます。マスターで常にグリーンになるテストに信頼を置くべきです。新しい機能の開発を始める前にマスターをテストしなければならないというのは理にかなっていません。例えば、CIはそれほどコストがかからないので、このように設定するのは理にかなっています。 3. すべてのコミットですべてのテストを実行します (テストの実行に 5 分以上かかる場合は、並列で実行します)。 機能ブランチで作業していて、新しいコミットを追加している場合は、そのブランチでテストを実行してください。テストの完了に時間がかかる場合は、並列実行を検討してください。すべてのテストスイートをサーバー側のマージリクエストで実行します。開発用のテストスイートと新しいバージョン専用のテストスイートがある場合は、並列テストを設定して個別に実行することをお勧めします。 4. マスターにマージした後ではなく、マージする前にコードレビューを実行します。 週末にすべてをテストする必要はありません。その場でテストする方が、問題の原因になりそうな点を見つけやすくなり、他の人も解決策を考えやすくなります。 5. デプロイメントは自動的に行われ、ブランチまたはベースラインに基づいて行われます。 毎回masterをデプロイしたくない場合は、本番ブランチを作成できます。ただし、スクリプトを使ったり、どこかにログインして手動でデプロイする理由はありません。すべてを自動化するか、特定のブランチで本番環境へのデプロイをトリガーするようにしてください。 6. ベースラインは CI ではなく手動で作成されます。 ユーザーがベースラインを作成すると、CIはそのベースラインに基づいて操作を実行します。CIによるコードリポジトリの変更は許可しないでください。非常に詳細なメトリクスが必要な場合は、新しいバージョンをリストしたサーバーレポートを用意する必要があります。 7. タグのバージョンに基づいてリリースします。 プロジェクトのタグを生成すると、新しいバージョンがリリースされたことを意味します。 8. リセットして変更を送信しないでください。 プロジェクトへの変更をパブリック ブランチにコミットする場合は、リセット メソッドを使用しないでください (つまり、 `git rebase` を適用しないでください)。 そうしないと、プロジェクトの改善とそれに対応するテスト結果を追跡することが難しくなり、他のユーザーが最も好ましいバージョンを選択するための根拠が損なわれてしまいます。 貢献者に、ローカルの非標準の変更履歴を無視し、真の変更履歴を提供するために `git merage --spansh` を使用して変更をコミットするよう依頼する場合、このガイドラインに違反することがあります。これにより、後で変更履歴を確認する際にバージョンを逆転させやすくなります。ただし、一般的に推奨されるプラクティスは、コードはクリーンで、変更履歴は正確であることです。 9. すべての作業はメイン ブランチから開始し、常にメイン ブランチをベースとする必要があります。 つまり、どのブランチからも開始する必要がないということです。メインブランチをチェックアウトし、機能を作成し、マージリクエストを送信すれば、その後の変更はメインブランチに基づいて行われます。コンテンツをメインブランチにマージする際は、レビュープロセスを完了し、他の中間段階のコンテンツを含めないようにしてください。 10. 最初にメイン ブランチのバグを修正し、次にブランチをリリースします。 バグが見つかった場合、最悪なのは、メイン ブランチを変更せずに新しくリリースされたバージョンを変更してしまうことです。 これを回避するには、常に最初にメイン ブランチを変更し、次にリリースされたバージョンのバグを修正した別のバージョンをリリースする必要があります。 11. 提出する情報は、行った変更に関する意図を反映したものである必要があります。 何をしたかだけでなく、なぜそうしたのかを説明する必要があります。他の方法ではなく、なぜこの方法で行ったのかを説明すると、より効果的です。 |
