問題タブ [branching-and-merging]

私は HG から Plastic SCM ( http://www.plasticscm.com、主に VS 統合がはるかに優れているように思われるため) に切り替えることを検討しており、「タスク駆動型分岐」、つまりすべてのメインラインからの分岐を促進しています。特徴。これは理にかなっていますが、いくつか質問がありました。

1. 彼らは、完了後にタスクをメインラインにマージしないことを推奨しています。これは非常に直感的ではないように思えます。テスト後、後でリベースする必要がないように、すぐにマージしてチップに戻したいと思うでしょう。言うまでもなく、タスクがマージバックされず、新しいリリースが近づいていると言う場合、おそらく数百の異なるブランチをマージし、それらすべてが短期間で互いにうまく機能することを確認する必要があります (テスト独立しているということは、彼らが他の人と仲良くするという意味ではありません。だから、これは失敗するに違いないように思えますが、間違っていますか? この方法を実践していますか？
2. 次のシナリオを考えると、上記について私が間違っているとしましょう: タスク A、B、C。B、C が A の完了に依存している場合、A を完了し、それをメインラインにマージしてから、次にマージする方がよいでしょうか?そこから分岐して B/C で作業するか、最初の分岐 (A 用に作成した分岐) をサブ分岐します。それは可能ですか？おすすめされた？同じ人が A、B、C を実装している場合、私の頭の中では少しすっきりしているように思えます。

皆さんの考えを教えてください！

ありがとう。

私はブランチで作業していたリポジトリを持っていて、master最後に別のブランチに追加したい 10 個ほどのコミットを追加しました。それらは、現在実験的であると考えている作業を説明しているためです (私はまだ良い Git プラクティスを学んでいます)。

masterこの考慮事項に照らして、「リリース」/「安定」コミットのみのためにクリーンで予約できるように、これらの最後の 10 個のコミットをいわば独自のブランチを形成したいと考えています。

説明するために、私が持っているものは次のとおりです。

XとでマークされたコミットZはすべてmasterブランチ上にあることがわかりますが、私が欲しいのは でマークされたコミットZ(現在は実験的な「機能 Z」作業と見なされています) は、独自のブランチにありmaster、右端のX. 説明のために、目的のグラフは次のとおりです。

そうすれば、master必要に応じて A、B、Z 機能をマージできるように、リリースやその他の安定したコミット用に予約することができます。

では、「Z」コミットを独自のブランチに移動するにはどうすればよいですか?

私は自分のプロジェクトに Git を使用しており、ベスト プラクティスに従おうとしています。

1. 私はトピックブランチに取り組んでいます
2. 準備ができたら、を使用してトピック ブランチを開発ブランチにマージしgit merge --squashます。これにより、開発ブランチがクリーンに保たれます。
3. 開発ブランチが安定しており、チームがリリースの時期であると判断した場合はいつでも、スカッシュを使用せずに開発ブランチをマスターブランチにマージし、そのコミットをバージョン リリースとしてタグ付けします。

これにより履歴が保持され、gitk を使用して、すべてのコミットが入ってくる場所を確認できます。ただし、マスターブランチに適用されたコミットのみを確認できるようにしたいと考えています。私が試してみました：

これらのいずれも、マスターブランチの履歴だけを示しているわけではありません。これを簡単に行う方法はありますか？

私は SCM に所属しており、さまざまなツール (Subversion、Clearcase、TFS、Perforce) とテクノロジ (主に .NET、Java) を扱っています。私が仕事を始める前は、管理された支店を作るのが通常の仕事でした。

管理されたブランチを次のように定義します。 -開発者がアクセスできない昇格されたコードを含む別のブランチ。これにアクセスできるのは、ビルド エンジニアのチームだけです。

制御されたビルド: -制御されたブランチからコードを取得し、開発者が変更できないアーティファクトを生成するビルド エンジン。

その結果、このブランチへのマージは、制御されたビルド プロセスの一部として重要なステップになりました。これにより、速度とエラーの両方の問題が発生する可能性があります (自動化によってほとんど軽減されます)。

利点: 自動コード ロック (開発者はブランチを変更できないため) ブランチ名は異なる場合があります (他のチームは必ずしも標準化された慣行に従っているとは限らず、必要な圧力をかけることができるとは限りません) 正確なバージョン コードを見つける簡単な方法状態 (つまり、バージョンの管理されたブランチの最新のコードは、製品に移行したものです)

欠点: 開発者と問題について話し合うときに、開発ビルドと制御ビルドを一致させる速度が上がります (これは自動化されていますが、少し面倒です)。エラー (プロセスを台無しにする別の場所) 変更リスト/変更セット/不変ラベルを使用して、セキュリティ/役割分離機能を完全に処理できますか?

質問:

現在の管理されたブランチ戦略から移行することをお勧めしますか? 他の特典がありませんか?

私はこのような構造のアプリ（cms）を持っています：

これは、すべてのプロジェクトのベースとなる中央リポジトリです。次に、プロジェクトは独自のスキンを取得します:(テーマに基づいています/default/）

（このアプリには、デフォルトのテーマに基づいた12のカスタムテーマがあります）。

すべては、アプリケーションを維持し、すべてのクローンをBASEで最新の状態に保つことです。

ここで、BASEをリモートリポジトリとして追加します。

次に、必要に応じて更新を取得します。

の.phpファイル/applicationが変更されると、すべてがうまく機能します。default問題は、BASEリポジトリのテーマのファイルを変更したときに始まります（たとえば、タイプミスreset.css）。CLONE1/defaultテーマとすべてのテーマの変更が必要CLONEx/own-x/です。

もちろん、変更をコピーしてコミットする場所を指示するためにいくつかのbashスクリプトが必要になりますが、マージの競合なしに全体を同期させる方法はありますか？

を使用しますgit flow。現在、テーマdefaultとmobileテーマは別々のブランチにはありません。それらが必要ですか？サブモジュールはまだ使用していません。

このワークフローを整理する方法はたくさんありますが、最適なものとしてどれを選択しますか？

Mercurial リポジトリにブランチを作成する唯一の方法は、作業コピーに変更を加えてから、新しいブランチにコミットすることだと聞きました。

trunkSubversion では、(下のパスにコピーすることにより) 変更を加えることなくブランチを作成できますtags- Mercurial でもこれを行うことは可能ですか?

私は現在 TortoiseHg しか見ていないので、これはコマンドライン ツールを介してのみ実行できる可能性があり、私にはわかりません。

これに対する私のワークフローは次のとおりです。

• 機能ブランチを作成します。
• その機能ブランチでいくつかの作業を行います。
• リリース候補ブランチを作成します。
• フィーチャをマージして候補ブランチをリリースします。
• 展開、テスト、修正 展開、テスト、修正のリリース候補ブランチ。
• リリース候補ブランチをトランクにマージします。

よろしくお願いします。

Subversion 1.3 または 1.4 を使用しています。サーバーを 1.5 にまだアップグレードできません。ブランチを作成し、変更を加えました。ブランチでの作業が完了したので、ブランチをトランクにマージする必要があります。

ブランチを作成してから (約 1 か月)、多くの変更がトランクに当たりました。SVN の「リビジョンのマージ」機能を使用して、それらをブランチにマージしました。これは、ブランチに最新のトランク コードと私の変更が含まれていることを意味します。

1.5 を持っていないため、Tortoise SVN の「ブランチの再統合」機能を使用できません。ブランチのリビジョン範囲をトランクにマージしようとしましたが、大量の競合 (およびツリーの競合) が発生します。私のブランチはトランクからのすべての変更をマージした（リベースした）ため、理由はわかりません。

いくつかの再構築（ファイルの移動、ディレクトリの作成/削除）を行いました。何かが足りない気がします。ブランチに最新のトランク コードとブランチの変更がある場合、トランクへのマージで競合が発生するのはなぜですか?

更新されたブランチをトランクにすばやく簡単にマージするにはどうすればよいですか?

私が少し使っているリポジトリがあります。そこには Web サイトの約 805 のリビジョンがあります。

プロジェクトの開始時から、開発の短い道のりを歩んだら、基本的なフレームワーク用に 1 つ、最初はそのフレームワークに基づく最初の Web サイト用に 1 つ、複数のブランチに分割することが想定されていました。最終的には、このフレームワークに基づく Web サイトがさらに増える予定です。

HEAD リビジョンに基づいて 2 つのブランチを作成しました。1 つは「Framework」、もう 1 つは「Site」です。

2 つの作業コピーがあり、1 つは ubuntu Dev サーバー上にありました。これは私がほとんどの開発作業を行っていた場所ですが、Windows マシンに別の作業コピーもありました。これは、物事のデザイン面に使用されました。

これまでのところ、これは完全に機能しており、両方の作業コピーが問題なくトランクにコミットできます。

私が抱えている大きな問題は、今ではブランチがあり、Windows マシンはブランチにアクセスできますが、ubuntu マシンはエラーを出すことです:

私がTortoiseSVNを使用しているWindowsマシンの1つで、ubuntuマシンはsubversionコマンドラインです。

リポジトリは次の場所にあります。

トランクの場合:

およびブランチは次のとおりです。

ubuntuマシンの作業コピーを別のブランチ（フレームワークブランチなど）に切り替えるために使用しているコマンドは次のとおりです。

上記のように、次のものが返されます。

Windowsマシンがブランチにアクセスできるのに、Ubuntuクライアントがアクセスできない理由を誰かが明らかにすることはできますか?

共有リポジトリからコードをチェックアウトし、いくつかの作業を行いました。その過程で、共有リポジトリからコードに変更をマージしてきました。

ローカル レポジトリを共有レポジトリの新しいブランチにプッシュして、他の人がアクセスできるようにすると同時に、共有レポに損害を与えないようにしたいと考えています。

Gitを使用してこれを行うにはどうすればよいですか?

変更のあるブランチを取り、分岐元の上流と同じになるように戻そうとしています。変更は両方ともローカルであり、github にプッシュされているため、履歴が変更されるため、どちらgit resetもgit rebase実際には実行可能ではありません。これは、既にプッシュされているブランチでは悪いことです。

私もgit mergeさまざまな戦略を試しましたが、ローカルの変更を元に戻すものはありません。つまり、ファイルを追加した場合、マージにより他のファイルが元に戻る可能性がありますが、上流にないファイルがまだ残っています持ってる。

アップストリームから新しいブランチを作成することもできますが、リビジョン履歴の観点からすべての変更を適用してブランチを取得し、アップストリームと同じにするマージが本当に必要です。これにより、その変更を安全にプッシュできます。歴史を壊すことなく。そのようなコマンドまたは一連のコマンドはありますか?