問題タブ [branch]

git トピック ブランチとは何ですか? 普通の支店と何か違うの？トピックブランチではないブランチはありますか?

コードベース（PHP）への変更要求で私たちを怒らせているクライアント（クライアントを持っている、クライアントを持っている）がいます。私たちの最初の対応は、SVN のメイン トランクで作業することだけでしたが、クライアントは頻繁に戻ってきて、特定の変更をできるだけ早くライブ サーバーにプッシュする必要があると要求しました。一方で、他の変更の優先度が突然低下します。これは、もともと他の変更とグループ化されていたものです (一見)。

変更リクエストごとにブランチを使用することを考えています。これは怒っていますか？他にどのようなソリューションが機能する可能性がありますか?

ありがとう！

編集：これは正しい答えを選ぶのが本当に難しい質問です。素晴らしい回答をありがとうございました。

編集：私が選んだベストアンサーが特に人気がなかったのは知っています。私も、この問題に対する技術的な解決策を見つけたいと思っていました。しかし、クライアントがモジュラー方式で展開できる機能を備えたソフトウェアを望んでいる場合、この問題はバージョン管理システムの使用では解決されないはずです。ソフトウェアに組み込む必要があります。

編集：ほぼ1か月後、同僚/クライアントは、複数のブランチが進むべき道であると私に確信させました。これは、クライアントの狂気によるものだけではなく、機能が「すぐに使える」か「さらに作業が必要か」などを判断できるようにする必要があるためです。私は SVN を持っていませんが、SVN クックブックからのアドバイスを使用してマージします。つまり、分岐されたリビジョンからのブランチをヘッド リビジョンにマージします。

また、このシステムを使用して、ある時点ですべてのブランチをマージし、それが新しい QA になり、ライブ ビルドになります。次に、そこから分岐します。

最終編集 (おそらく):数か月経った今でも、このシステムはうまく機能しています。チケットごとにブランチを作成し、問題が発生することはほとんどありません。一方で、人々が取り組んでいるものに関しては、物事を分けようとしています...

2 年後:現在 GIT を使用していますが、このシステムは実際には非常に合理的です。

優れた無料のバージョン管理とSubversionの本を使用して、Subversion1.5との分岐/マージについて読んでいます。Subversionコマンドラインクライアントを使用して、最も頻繁に必要なアクションを実行する方法を理解していると思います。

トランクからの変更でブランチを更新

ブランチの作業ディレクトリから次のコマンドを実行します。

svnマージhttp://svn.myurl.com/proj/trunk

ブランチをトランクにマージ

トランクの作業ディレクトリから次のコマンドを実行します。

svn merge --reintegrate http://svn.myurl.com/proj/branches/mybranch

ただし、SubversionへのインターフェースとしてTortoiseSVN1.5を使用しています。TortoiseSVNでこれらの操作を実行するための最良の方法を知りたいです。新しいダイアログには、メインメニューに3つの異なるオプションがあります。

1. 一連のリビジョンをマージする
2. ブランチを再統合します
3. 2つの異なるツリーをマージします

私が収集できることから、TortoiseSVNは常に次の構文でsvnを実行します。

svn merge [--dry-run] --force From_URL @ revN To_URL @ revM PATH

さらに、ブランチの再統合は、一部のターゲットがマージされていないため続行できないことを示すメッセージで失敗することがよくあるため、オプション＃3を使用する必要がありました。

私の質問は次のとおりです。

1. TortoiseSVN 1.5を使用して、トランクからブランチへの変更をマージするにはどうすればよいですか？
2. TortoiseSVN 1.5を使用して、reintegrateメソッドを使用する場合と使用しない場合で、ブランチをトランクにマージするにはどうすればよいですか？
3. 上記のオプションのどれをそれぞれに使用する必要がありますか、またその理由は何ですか？

編集

「ドライラン」テストを通じて、コマンドラインのSubversion操作が

svnマージhttp://svn.myurl.com/proj/trunk

リビジョン範囲を空白のままにする限り、TortoiseSVNのオプション＃1（リビジョンの範囲をマージする）に類似しています。

2 つのブランチがあります: 1. HEAD - 最新バージョン (別名 Trunc) 2. PROD - リリース済みバージョン

リリースされたバージョンのバグを修正する場合、次のうちどれを行いますか:

1. PROD で修正してから、HEAD にマージします
2. HEAD で修正してから、PROD にマージします

(1) の利点は、この方法では、HEAD からテストされていないコードを誤って持ち込んで、リリースされたバージョンに害を与えることが絶対にできないことです (PROD は常に HEAD よりも安定しており、テスト済みであるという前提があります)。

(2) の利点は、PROD よりも HEAD の方がコード片の使用法が多い可能性があることです。そのため、PROD でのみ修正すると、そのような使用法をすべて見つけることができず、バグを HEAD に滑り込ませる可能性があります。

個人的には(1)です。どう思いますか？

目的がなくなった枝をどうやって適切に取り除くべきか疑問に思っています。今のところ、それらを削除してコミットしても、特定の分岐ルート（ディレクトリ）のプロパティウィンドウに分岐として表示されます。マージを選択した場合、削除されたブランチにマージするオプションが表示されません。これは明らかに期待どおりですが、プロパティウィンドウにブランチがまだ表示されていることに戸惑っています。

この振る舞いについての説明をいただければ幸いです。

同じ SVN ブランチを 2 回作成できます。SVN で同じブランチを再度作成できないことを願っています。この問題を解決するのを手伝ってください。

git リポジトリがあり、master で作業しているとします。さかのぼってブランチを作成できますか。例えば：

A - B - C - A1 - D - A2 - E

私はそれを次のようにしたい：

特定の使用例は、古いバージョンのブランチに大量のコミットをチェリー ピックし、それを複数の古いバージョンに移動する必要があり、それらすべてのリビジョンでチェリー ピックを繰り返したくない場合です。

本質的には、そもそもフィーチャーまたはトピック ブランチとして優れていたはずのものですが、そのように作成されたわけではありません。

ブランチを作成せずにソース コードのタグ付きバージョンをチェックアウトすると、Git はどのブランチにも関連付けられていないことを示します。変更を加えてチェックインさせていただければ幸いです。それらの変更はどこに行きますか？「マスター」に戻すと、それらは消え (マスターにあったものによって上書きされ)、再び見つけることができないようです。何を与える？Git で、本質的に匿名のブランチに対して変更をコミットできる場合、それらを元に戻すことができるでしょうか?

Git で、多数のブランチにまたがるパスでファイルまたはディレクトリを検索するにはどうすればよいですか?

ブランチに何か書いたことがありますが、どのブランチか覚えていません。今、私はそれを見つける必要があります。

明確化: ブランチの 1 つで作成したファイルを探しています。内容を覚えていないので、内容ではなくパスで検索したいと思います。

X と Y の 2 つのブランチがあります。Y のサブディレクトリ (y1) を X (x1) と同等のものに置き換えたいと考えています。

とりあえず、次のことを行います: x1 を Y にコピーし、y1 を削除し、x1 を y1 に名前変更 (移動) します。

かなりヤバイと思います…

どうすればよりスマートな方法でそれを行うことができますか?