小規模プロジェクトのGitワークフロー/プラクティス（pngのフローチャート）

私は個人的なワークフローを考え出そうとしています。リリースの架空の寿命のフローチャートを作成しました。ある開発者が公開githubリポジトリにプッシュし、友人が何らかの機能を手伝ってバグを修正しました。

これはバージョン管理の合理的なアプローチですか？

主なアイデアは、パブリックリポジトリを整理することです。

• 新しいリリースはそれぞれ、終了時にマスターブランチで最終的にタグ付けされるまで、独自のブランチになります。

• すべての作業は、異常を防ぐために、実際のリリースブランチではなく、「機能」または「ホットフィックス」ブランチで行われます。

• 高レベルのブランチへのマージは、常にリベースまたはスカッシュされます（混乱を避けるため）。

やり過ぎだとしても、大事なプロジェクトに必要なスキルを習得することが全体的な目的なので、気にしません。唯一の問題は、私が間違っているか不必要なことを完全にやっていることです。

編集2：元のフローチャートの悪い考えを修正し、ナビゲートしやすくしました。

git / githubコミュニティでよく目にするのはこれです

支店マスター開発

あなたと貢献者は主に開発に取り組んでいますが、誰かがアイデアや新機能を持っている可能性があるため、git checkout -b user_commentsのようなトピックブランチを作成します。

その後、開発を進めながら、満足のいくバージョンをgitにマスターしたらプッシュし、masterブランチで1.0または1.1.2などとしてタグ付けします（セマンティックバージョニングを参照）