1

私は開発環境「redmine」をセットアップしようとしています。これにより、複数の人が独自の機能や調整を含む独自のバージョンの「redmine」を簡単に開発および保守できるようになります。私はリモートブランチにあまり詳しくありませんが、次のような構成を考えました。

  • マスターブランチ：展開用
  • 開発ブランチ：ここでは、新しい機能を開発しています
  • コミュニティブランチ：これは私が行き詰まったところです。redmineのgithubコミュニティリポジトリを追跡しているブランチが欲しいので、このブランチで「git checkout v2.0」、次にdevブランチで「gitmergecommunity」と言ってマージの競合を解決します。そこに私たち自身の機能。次のredmineリリースの後、コミュニティブランチでv2.1をチェックアウトし、それをdevブランチに再度マージします...

もちろん、リモートをローカルブランチに追加し、コミュニティリポジトリからプルして自分のオリジンにプッシュすることはできますが、他の人はそれを認識せず、コミュニティリモートリポジトリを自分で追加する必要があります（右？）。これは可能ですか、それともこの「自分のプロジェクトで参照プロジェクトを追跡する」問題を解決するための別のアプローチは何ですか？

ありがとう

1月

ところで：私のオリジンリポジトリはgitosisを使用して作成されています。

4

1 に答える 1

1

開発ブランチまたはコミュニティブランチ（作業領域）のどちらにいても、機能ブランチを使用して開発、編集、および開発を提案し、構造化された方法でまとめることができるようにする必要があります。つまり、コントリビューションをマージし、それらをより高いレベルに昇格させるアプローチを選択する必要があります。git-scm.com/book/en/Git-Branching-Branching-Workflows

時間をかけてリモートの動作を理解し、追跡されたブランチが完全に重複していること（共通のフェッチ/プッシュの時点まで）を理解してください。そのため、異なる人々の貢献に同じコミュニティブランチを割り当てることを計画することはできません。そのためです。それぞれの人が独自の機能ブランチを持っている必要があります。機能が完了したら、ブランチ名を再利用できます。

git自体（github.com/git/git）には、公開された一連のブランチがあります：-pu（更新の可能性）、next、最後にmaster。puの前には、個々の寄稿者ブランチがあり（それぞれ、gitリストの場合はパッチシリーズの送信から構築されます）、メンテナが必要な場合はpuを巻き戻すことができます。次はより安定しています。ユーザーは更新をフェッチし、関連する最新リリースに基づいて作業をリベースします。

于 2012-11-11T00:17:17.437 に答える