2

ワークフローを次のように整理しました。

master ブランチは開発用で、ソース コードといくつかのユーティリティ スクリプトが含まれています。

リリース ブランチが配布されており、実行可能ファイルといくつかの追加ファイルが含まれています。

最初にリリース ブランチを作成したとき、そこからすべてのソース コードを削除し、コンパイル済みの実行可能ファイルを追加しました。次のリリースをしたいときは、そうします

git checkout release

git merge --no-ff -Xours master

また、変更されたすべてのソース ファイルは、-Xours オプションを使用した場合でも、削除/変更の競合を引き起こします。競合するすべてのファイルを手動で削除してから、コミットする必要があります。この競合を自動的に解決して、削除されたファイルを強制的に削除したままにする方法はありますか?

4

3 に答える 3

1

あなたはGitを使用しており、さらに言えば、まったく異なる方法でソース管理を管理しています。私はそれが間違っていると言っているわけではありませんが、git repo で達成したいことを再考することを検討する必要があります。

一般的に、releaseブランチにはコードも含める必要があります。releaseそして、常にブランチから本番実行可能ファイルをビルドします。そして、それらを別の場所に移動します。

そうは言っても、実行可能ファイルのバージョンも保持したい場合。それらをそこに保持するために、別の git リポジトリを作成します。これにより、実行可能ファイルの保守が容易になります。

Maven/Java を使用している場合は、ビルドの成果物を管理することだけを目的とした Maven Repo をお勧めします。

于 2012-06-08T05:09:57.740 に答える
1

コードから生成されたアーティファクトを保存するために同じリポジトリを使用しないでください。履歴を肥大化させ、通常の開発ではプッシュとフェッチを遅くします。新しいクローンには時間がかかりすぎるため、最終的にはこのアプローチを放棄する必要があります。アーティファクトの zip の命名規則を標準化し、別の方法で発送します。それは別の git リポジトリである可能性がありますが、コードで作業する場所であってはなりません。必要に応じて、サブモジュールを介して 2 つのリポジトリ間のリンクを作成できます。

于 2012-06-08T11:15:37.290 に答える
0

リポジトリからいくつかのファイルを削除し、いくつかの変更をコミットするときは、 -a オプションを使用する必要があります。広告のドキュメントには次のように記載されています。

-a, --all
   Tell the command to automatically stage files that have been
   modified and deleted, but new files you have not told git about are
   not affected.

これにより、削除されたファイルからすべてのリポジトリが消去されます。そして、他のブランチからマージすると、競合はありません。これがあなたを助けるとは確信していません。私はそう願っています。

于 2012-06-08T05:20:47.923 に答える