小規模チーム向けのGitワークフロー

私は、小さなチームで実装するgitワークフローに取り組んでいます。ワークフローのコアアイデア：

• すべてのチームメンバーが書き込み可能な共有プロジェクトマスターがあります
• すべての開発は機能ブランチでのみ行われます
• 機能ブランチは、ブランチ作成者以外のチームメンバーによってコードレビューされます
• 機能ブランチは最終的に共有マスターにマージされ、サイクルが再び開始されます

この記事では、このサイクルの手順について詳しく説明します。

https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md

これは理にかなっていますか、何か不足していますか？

git flow branching modelが好きです。masterブランチはほとんどの場合そのままで、リリースのみが含まれています。開発ブランチは常に安定している必要があり、機能ブランチは破損する可能性があります。

開発を機能ブランチにマージし、機能ブランチを開発にマージすることにより、これを継続的な統合と組み合わせることができます。もちろん、何かが機能していると確信し、壊れていない場合にのみ、何かを開発にマージする必要があります。

トピック継続的インテグレーションが欠落していると思います。すべての開発セットアップの一部である必要があります。

機能ブランチを使用すると、問題が発生します。継続的に統合するのではなく、機能が完了した後にのみ問題が発生します。

分岐された機能が短命であれば、これは受け入れられるかもしれませんが、それは間違いなく考慮すべきものです。

別の代替手段は、機能ブランチごとにCIビルドをセットアップすることです。これは確かに役立ちますが、統合ではありません。これは、機能Aと機能Bには表示されないが、機能AとBを統合した瞬間に最初のバグを見つけると明らかになります。

3番目の選択肢は、CIビルドの一部の統合ブランチにマージすることです。これは真の統合であり、作業が多少分離されている場合、実際にはgitで十分に機能しますが、ビルド中にマージの競合が発生し、ビルドが失敗します。

gitflowまたはTwgitに触発されます。

gitflowは、そのアプローチを次のように要約します。

Vincent Driessenの分岐モデルに高レベルのリポジトリ操作を提供するGit拡張。

Twgitは次のように自身を説明します。

Twgitは、Gitリポジトリの機能、修正プログラム、およびリリースを管理するための無料のオープンソース支援ツールです。ドキュメントに記載されている分岐モデルを採用するためのシンプルで高レベルのコマンドを提供します。サポートされるOS：Debian / Ubuntu Linux、Mac OSX。

両方のツールはgithubから入手できます。