GithubFlowモデルの機能の定義？

Question

私はしばらくの間gitを主にCLiで使用しています。これまでこのプロジェクトに取り組んでいるのは私だけです。 1つのmasterブランチと1つのproductionブランチがあります。 productionブランチは、そのブランチ内のすべてのテストに合格するように名前が付けられています。私はマスターブランチで直接作業しています。

最近問題が発生したため、ベストプラクティスを使用していないのではないかと思いました。 featureAの作業を終了し、featureBの作業を開始しました。 featureBの作業中に、featureAのコードにいくつかの変更を加えましたが、featureAのテストは実行しませんでした。後でfeatureBのテストを実行しているときに、featureAが機能することを確認し、featureAのテストが機能しなくなったことも確認しました。これにより、機能をどのように定義しているかを考えるようになりました。おそらく、各機能で行っている作業を分離できるはずです。これにより、このバグの原因となった変更をすばやく把握できます。私がこれらをfeatureAおよびfeatureBとして定義しているのは、後から考えるだけです。

他の人と話をしていると、機能ごとにブランチを使用することになっていることに気付き、各機能を完了するときにそれらをマージします。

適切なワークフローを見つけるために、私は2つの主要なワークフローに出くわしました：gitflow Vincenによって提案されました： http://nvie.com/posts/a-successful-git-branching-model/ ==

そして

github-flow Githubによって提案されました： https://guides.github.com/introduction/flow/

また、次のような他の複数のドキュメントも確認しました。

git-flowとgithubを使用したコードレビュー、

2つのワークスローの比較： https://www.youtube.com/watch?v=nPNA8ZfDjKM

これらのことから、私は自分で作業しているので、gitflowはオーバーヘッドが大きすぎるようです。だから私はgithub flowを使うことを考えています。

質問

作業のGitHubフローモデルで、マスターからブランチを作成する必要があることを理解しています。ただし、機能をどのように定義しますか？私はこのコードベースで自分で作業しているので、パッケージ全体を機能と見なし、単一のブランチで作業することになりました。ただし、Githhub flowモデルとgitflowモデルを読んだ後、機能の定義ははるかにきめ細かくなっているようです。私はこれまで読んだこれらのドキュメントや他のドキュメントで機能が何を表すのかについての定義に出くわしていません。機能は関数ですか、クラスですか？また、定期的にgithubの問題を使用して、役立つと思われる変更をファイルに保存していますが、今は時間がありません。 GitHubの問題を使用して問題を作成してから、それらを使用して機能を作成する必要がありますか？

amon · Answer

明確な定義はありません。通常、機能の範囲はチームの開発プロセスによって異なります。機能は、タイプミスの修正、またはモジュールの完全な再実装である可能性があります。場合によります。

1つの適切な概算：機能は、プルリクエストとして合理的にレビューでき、それでも「完全」であることができるものです。頻繁な小さな変更は煩わしいですが、大きなプルリクエストは完全にレビューできません。クラスのように、プルリクエストはまとまりがあり、弱く関連する多くのことを行わないようにする必要があります。機能は、何も壊さずにマージできるように、十分に完全である必要があります。

これは、機能がすぐに出荷可能でなければならないという意味ではありません。 早期にマージし、頻繁にマージするの場合、多くのGitの問題が解消または軽減されます。つまり、機能は小さく、完全に準備が整う前でもマージする必要があります。これを管理する1つの方法は、フィーチャートグルを使用することです。フィーチャーの一部はすでにマスターブランチにあります（したがって、他の変更と統合できます）が、何らかのスイッチで明示的にアクティブ化する必要があります。したがって、これらの不完全な機能は本番環境では使用されません。

あなたはソロ開発者なので、これはすべて実際には当てはまりません。通常、ブランチやマージをまったく行わなくても、一度に1つの機能を開発できます。それは完全に有効なプロセスです。分岐モデルは、その逆ではなく、ニーズを満たす必要があります。

したがって、GitFlowとGitHubFlowの両方を実装しようとしているのは少し驚きです。これら2つは似ているように聞こえますが、目標は大きく異なります。

GitFlowは、複数の開発者を調整しようとするかなり重い分岐モデルであり、リリースされたバージョンの明確な概念があり、しばらくの間サポートすることを前提としています。
GitHub Flowは、プルリクエストコメントなどのGitHub機能を紹介しようとするかなり軽量のブランチモデルであり、マスターブランチから継続的デプロイを行うことを前提としています。

これら2つのブランチモデルの重複は、「マスターブランチはリリースされたものを表す」と「開発は機能ブランチで行われる」です。それらは良いが必須ではないアイデアです。例えば。マスターブランチを統合ブランチとして使用することも一般的ですが、必ずしもこの状態をデプロイ/リリースする必要はありません。代わりに、リリースにはタグが付けられます。したがって、既存の分岐モデルを調べて、それらを脇に置いて、自分に合ったプロセスを考え出すのが賢明かもしれません。

あなたの経験ではうまくいかなかったと思われる側面の1つは、テストでした。これらのワークフローはどこでテストを想定していますか？

GitFlowでは、通常、機能ブランチを開発ブランチにマージする際のテストと、リリースブランチの準備中のより徹底的なQAが行われます。
GitHub Flowでは、プルリクエストが確認され、デプロイパイプラインの一部として自動テストが実行されます。テストが成功した場合にのみ、展開が続行されます。

すべての場合において、変更をコミットおよび/またはプッシュする前に、ローカルでテストを実行することが賢明です。これは、問題を早期に検出するのに役立ちます。一般的に賢明なアプローチの1つ：すべてのコミットは正常にビルドされるはずです！コードをプッシュするたびに最新のコミットをビルドするビルドサーバー（Jenkinsなど）をセットアップするのはかなり簡単です。これにより、チェックイン前にクイックテストを実行し、後で包括的なテストスイートを実行できます。

フィーチャートグルを使用する場合、テストはこれを考慮に入れる必要があります。統合コードが機能するかどうかを確認するためにテストを実行する場合は、すべての機能を有効にする必要があります。リリースをQAするためにテストを実行する場合は、もちろん、リリースする構成をテストする必要があります。通常、フィーチャートグルのすべての組み合わせを個別にテストすることは不可能です。そのため、フィーチャーが永続的に有効になったらすぐに削除する必要があります。

要約すると、明確な定義はありません。「機能」は、多くの場合、「個別のコミット」と「リリース」の間にあるある種の変更です。一人で作業する場合、明確な区別を維持する必要はおそらくありません。他の人と仕事をするときは、既存のプロセスに従うよりも、ニーズに合った共通のプロセスに従うことが重要です。しかし、何をするにしても、自動テストは非常に役立ちます。