web-dev-qa-db-ja.com

小さなプロジェクトのGitワークフロー/実践(pngのフローチャート)

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

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

主なアイデアは、公開リポジトリを整頓することです:

  • 新しいリリースはそれぞれ、マスターブランチでタグが付けられて終了するまで、独自のブランチを取得します。

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

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

やりすぎだとしても、大規模なプロジェクトで必要になる可能性のあるスキルを習得することが重要なので、気にしません。唯一の問題は、私が何か間違ったことや不必要なことをしている場合です。

編集2:元のフローチャートの悪い考えを修正し、ナビゲートを少し簡単にしました。

v1.1

12
iDontKnowBetter

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

ブランチマスター開発

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

次に、開発を進めながら、満足のいくバージョンをgitでマスターにプッシュし、マスターブランチで1.0または1.1.2などのタグを付けます(セマンティックバージョニングを検索します)。

3
Andre Dublin