問題タブ [branch]

git-svn を試してみようと思った理由は、楽なマージと分岐です。次に、 man git-svn(1) が次のように言っていることに気付きました。

dcommit する予定のブランチで git-merge または git-pull を実行することはお勧めしません。Subversion は、合理的または有用な方法でマージを表すものではありません。そのため、Subversion を使用しているユーザーは、作成したマージを見ることができません。さらに、SVN ブランチのミラーである git ブランチからマージまたはプルすると、dcommit が間違ったブランチにコミットする可能性があります。

これは、svn/trunk (またはブランチ) からローカル ブランチを作成し、ハックして、svn/trunk にマージし直してから dcommit できないということですか? svn ユーザーは、1.5.x より前の svn でのマージと同じ混乱を常に経験していることを理解していますが、他に欠点はありますか? その最後の文も気になります。人々は日常的にこの種のことをしていますか？

警告の言葉：私はgit一般的には反対です. 私のチームは で機能ブランチを使用しており、特定の機能ブランチでの作業を追跡svnするために使用したいと考えています。git-svn私は (大まかに) Andy Delcambre の投稿に従ってローカル リポジトリをセットアップしましたgitが、これらの指示により、最近変更されgitたブランチがリモート リポジトリとして選択されたようです。svn問題は、それが私が気にかけているブランチではないということです。どのブランチgit-svnが使用するかを制御するにはどうすればよいですか? それとも、私はこれに完全に間違っていますか？

更新: -T、-b、および-tオプションを使用しました (私の場合、svnレポには複数のプロジェクトがありますが、git作業中のプロジェクトのみをレポに含める必要があるため)。

新しいバージョンを提供するときのポリシーは、VCS にブランチを作成し、QA チームに処理させることです。後者がゴーサインを出したら、タグを付けて製品をリリースします。テクニカル リリースを作成できるように、ブランチはバグ修正 (のみ) を受信するために保持されます。これらのバグ修正は、その後トランクにマージされます。

この間、トランクは主要な開発作業を見ており、リファクタリングの変更を受ける可能性があります。

問題は、(バグ修正のマージが成功するように) 安定したトランクを持つ必要性と、コードが別のメソッドに抽出された場合や別のクラスに移動された場合、通常はできないこととの間に緊張関係があることです。新しい機能を導入するときにリファクタリングする必要性。

私たちのポリシーは、十分な時間が経過してブランチが十分に安定するまでリファクタリングを行わないことです。この場合、トランクで変更のリファクタリングを開始でき、トランクとブランチの両方でバグ修正を手動でコミットする必要があります。

しかし、これは、開発者がトランクにリファクタリングの変更をコミットする前に、かなりの時間を待たなければならないことを意味します。これは、ブランチからトランクへの後続のマージを中断する可能性があるためです。また、バグをブランチからトランクに手動で移植しなければならないのは苦痛です。これは開発を妨げているように私には思えます...

この緊張をどのように処理しますか？

ありがとう。

TFS での根拠のないマージについての私の理解では、それは 1 回限りの取引であり、その後のマージは根拠のないものでなくても行うことができるというものでした。

からhttp://msdn.microsoft.com/en-us/library/bd6dxhfy(VS.80).aspx

/baseless - ベース バージョンなしでマージを実行します。つまり、マージ関係のないファイルとフォルダをマージすることをユーザーに許可します。根拠のないマージの後、マージ関係が存在し、将来のマージは根拠のないものである必要はありません。

ただし、今晩、次の設定で試しました。

コマンドは正常に実行され、ファイルはマージされました。ただし、ソース管理エクスプローラーに戻り、Dev ブランチで右クリックしてマージを選択すると、QA はオプションではなく、トランクのみが選択されます。

それで、私はドキュメントを誤解しましたか?彼らが実際に言ったことは、常にコマンドラインで実行する必要があり、/baseless スイッチを含める必要はなかったということでしたか?

ソフトウェアの既存のリリース用に複数のメンテナンス ブランチがあるとします。一部の開発者は、メンテナンス ブランチを直接変更し、定期的にトランクにマージしています。今度は、今後のメジャー リリースが予定されている、トランク コードラインの広範なリファクタリングが行われます。しかし、これにより、メンテナンス ブランチはトランク内のコードと根本的に互換性がなくなります。たとえば、もはや存在しないコードに依存する可能性があるためです。

実際には、この状況にどのように対処しますか?

Windowsでtortoise svnを使用しています。

SVN で分岐して、svn:external フォルダーも分岐させるにはどうすればよいですか?

クライアントのニーズとより一般的なロードマップのリズムで進化するソフトウェア製品があります。

私たちは SCRUM プロジェクト環境にいるため、新しい機能が製品に導入されることが非常に定期的に発生し、次の選択に直面します。

• この機能をすでにリリースされているブランチに実装する (実際にはブランチを持つポイントではありません)
• 新しいブランチを作成します - しかし、その後、3 週間ごとにブランチを作成し、もはや維持できなくなります

新機能をリリースしないという選択肢はありません。クライアントは、必要な機能を取得するための長期的なマイルストーン計画を待ちたくありません。また、機能をクライアント モジュールに移動することが常に可能であるとは限りません。変更が必要になる場合もあります。商品の核となる...

この種の制約が与えられた場合の優れた実践についてのフィードバックはありますか?

苦痛で死なずに、極性化された枝へのマージの影響をどのように元に戻すことができますか?

この問題は何ヶ月も私を悩ませてきましたが、ついにあきらめました.

2 つの名前付きブランチを持つ 1 つのリポジトリがあります 。AとB。

A に発生する変更は、必然的に B にも発生します。

B で直接発生する変更は、A で発生してはなりません。

このような構成では、「B」を「A」にマージすると、B へのすべての変更が A で行われたかのように A に表示されるため、リポジトリで悲惨な問題が発生します。

この状況から回復する唯一の「通常の」方法は、マージを「バックアウト」することです。つまり、次のようになります。

後で正しい方向にマージすることを決定するまでは、これはすべて問題なくダンディに見えますが、あらゆる種類の厄介なことが発生し、特にブランチ B で消去/コメントアウトされたコードが突然消去またはコメント解除されます。

これまでのところ、「それをやらせてから、すべての問題を手作業で修正する」以外に、これに対する実用的な解決策はありませんでした。

問題を明確にする画像を次に示します。

【原画消失】

ファイル C & E (または変更 C & E ) は、ブランチ a ではなく、ブランチ b にのみ表示される必要があります。ここのリビジョン A9 (ブランチ a、revno 9) が問題の始まりです。

リビジョン A10 と A11 は、「バックアウト マージ」フェーズと「バックアウト マージ」フェーズです。

また、リビジョン B12 は水銀的であり、ドロップしないように意図された変更を誤って繰り返しドロップしています。

このジレンマは多くのフラストレーションと青煙を引き起こしました。私はそれを終わらせたいと思っています。

ノート

フックまたはポリシーのいずれかを使用して、リバース マージが発生しないようにすることが明らかな答えかもしれません。必然的にそれが起こると仮定して、それが起こったときにそれを解決できるようにします.

詳しく説明する

モデルでは、個別のファイルを使用しました。これらは問題を単純にします。これらは、別の行になる可能性のある任意の変更を表すだけです。

また、怪我に侮辱を加えるために、ブランチ A に実質的な変更があり、「ブランチ A の変更が、変更のように見える (そしてバックアウトされた) ブランチ B の変更と競合する」という問題が残ります。代わりにブランチ A で "

履歴書き換えのトリックについて:

これらすべての遡及ソリューションの問題は次のとおりです。

1. 9000 件のコミットがあります。
2. したがって、新たにクローニングするには30分かかります
3. リポジトリの不良クローンがどこかに1 つでも存在すると、元のリポジトリに再び接触して、再びすべてをぶち壊す可能性があります。
4. 誰もがこのリポジトリを既に複製しており、進行中のコミットで数日が経過しました。
5. そのようなクローンの 1 つがたまたまライブ サイトであるため、「それを消去してゼロから始める」=「ビッグ ノノ」

（上記の多くは少しばかげていることは認めますが、私の制御の範囲外です）。

実行可能な唯一の解決策は、人々はすべて間違ったことをする可能性があり、そうするであろうこと、そしてこの間違いを「元に戻す」方法があることを前提とするものです。

私はここ数ヶ月、グループのCVSリポジトリと相互作用するローカルgitリポジトリを使用しています。私はほとんど神経症的な数の枝を作りましたが、そのほとんどはありがたいことに私のトランクに戻ってきました。しかし、ネーミングが問題になり始めています。単純なラベルで簡単に名前を付けるタスクがあるが、それぞれが独自のブランチとマージの状況を含む3つの段階でそれを実行する場合、毎回ブランチ名を繰り返すことができますが、それは歴史を少し混乱させます。ステージごとに個別の説明を付けて名前をより具体的にすると、ブランチ名が長くなり、扱いにくくなります。

ここで古いスレッドを調べて、名前に/が含まれるブランチに名前を付けることができることを学びました。つまり、トピック/タスクなどです。私はそれを始めて、それが物事をよりよく整理するのに役立つかどうかを見始めるかもしれません。

gitブランチに名前を付けるためのいくつかのベストプラクティスは何ですか？

編集：実際に命名規則を提案した人は誰もいません。ブランチが終わったら、ブランチを削除します。経営陣が常に優先順位を調整しているため、たまたまいくつかの問題が発生しています。:)タスクに複数のブランチが必要になる理由の例として、タスクの最初の個別のマイルストーンをグループのCVSリポジトリにコミットする必要があるとします。その時点で、CVSとのやり取りが不完全だったため、そのコミットを実行してから、そのブランチを強制終了しました。（その時点で同じブランチを使い続けようとすると、CVSとの相互作用があまりにも奇妙になります。）

Visual Studio TFS での分岐に問題があります。これは私が開発している方法によるものかもしれませんが、その場合は分岐のベスト プラクティスを教えてください。手順を変更します。

約 1 か月前に、Web アプリケーションの新しいバージョンの開発を開始できるようにプロジェクトを分岐しましたが、テストを行い、物事を元に戻そうとしたときに、アプリケーションのメイン トランクが変更の影響を受けないようにしました。生産レベルのステータス。

そのため、数日前の時点で、本番環境で実行されているアプリケーションの現在のバージョンにいくつかのバグがあることに気付きました。これらのバグをメイン ブランチで修正し、Web アプリケーションを再デプロイし、バグ修正をメイン アプリケーション トランクにチェックインしました。そして、ここに問題があります。現在、メイン トランクにはバグ修正がありますが、新しいバージョン ブランチにはありません。

これが私の質問です。バージョン比較などを行って、バグ修正を分岐プロジェクトに取り込むにはどうすればよいですか?

普段と違うことをしているかもしれません。これは、分岐と開発のライフ サイクルに関する知識が不足しているためです。皆さんの開発現場で実践している、より良い方法があれば教えてください。

乾杯、

ハ