現在、Git を使用してワークフローを変更し、エラーやリグレッションを最大限に回避しています...
私はこれを読みました: http://nvie.com/posts/a-successful-git-branching-model/
簡単な要約を作成するには：
- masterブランチには、製品バージョンを表すタグがあります。
- 開発ブランチは、次のリリースが準備される場所です。毎晩テストが実行されるブランチです。そしてナイトリービルドのブランチ。
- 次の機能が作成され、 developブランチの最後にマージされるFeature-Somethingブランチ。このブランチは開発者リポジトリのみにある必要があります。
- ホット フィックスが作成されたFix-Somethingブランチは、 developとmasterでマージできます
- Release-1.2ブランチは、最後の修正と変更が加えられた次のリリースが準備される場所です。プロダクションの準備ができたら、マスターと開発にマージされます。
とても気に入っていますが、私たちの要件のいくつかと互換性がないものが 1 つか 2 つあるようです。
- まず、私たちのソフトウェアには、たとえば1.0バージョンのクライアントと1.2のクライアントがあります。クライアントを 1.0 から 1.2 に移行しないのは、それ以降のバージョンで Unity 3.4 をサポートしないという単純な事実のためです。しかし、一部のクライアントはまだそれを使用しています。
しかしここで、製品のコアにバグが見つかり、バージョンごとに修正する必要があるとします。コミットを複製せずにこのワークフローでこれを行うのは複雑に思えます...
次のようなことを考えました。
この新しい変更されたワークフローでは、修正がすべての運用ブランチに適用される場合、すべてのブランチにマージするだけで済みます。そのため、メイン リリース バージョンごとにブランチを作成することを考えました。
しかし、それは良いワークフローですか？このワークフローの短所は何ですか? プロ？ちょっとややこしいかも…と思います。
- このワークフローと互換性がないと思うもう 1 つの点は、
pull- request. 私たちはシステムを使いたいと思っていますpull-request。つまり、誰かが機能を完成させたりバグを修正したりするとき、彼は自分の作業をマージしたいブランチでプルリクエストを作成する必要があります。
しかし、リンクされた記事で説明されているように、機能またはバグのすべてのブランチが開発者のコンピューター上にのみ存在する必要があるという事実により、プルリクエストの使用が不可能になるのではないかと考えていました。pull-requestをリクエストする前に、ブランチをGitHubにプッシュする必要があると思いますよね?
最後に、このワークフローについてどう思いますか? 4 人から 10 人の開発者の小さなチームでも大丈夫ですか? それをより良くするための提案はありますか？より良いワークフローはありますか？