問題タブ [branch]

私は分岐とマージに svn を使用することにかなり慣れていますが、通常はこれで問題なく動作します。ただし、1 つのコンポーネントが 2 つのブランチで作業され、基本的にコンポーネントが異なる方向に進んだため、自動マージは機能せず、beyond compare を使用するとファイルがほとんど異なるものとして表示されます。

いくつかのファイルをつなぎ合わせようとしましたが、うまくいったとしても結果はかなりひどいものです。

私はビジネスに対して、これは絶対にできないと言いたくなる。モジュール + 機能 A が機能し、モジュール + 機能 B が機能しているのに、モジュール + 機能 A + 機能 B がそのままでは意味をなさないので、これが彼らを苛立たせているのがわかります。たとえば、機能 A は、機能 B の重要なコンポーネントだったものを削除する場合があります。

そのようなコードをマージしようとする方法はありますか? それとも、モジュール + A + B は本当にモジュール + C ですか?

私たちはこれが実現することを確認しましたが、機能 A は、長期にわたるプロジェクトの一部であった機能 B よりも短い時間スケールで必要でした。このようなことが起こらないようにする方法はありますか? それとも、両方の機能がうまく適合するようにコードを構成する方法はありますか?

継続的インテグレーションを行う場合に使用する最適な分岐戦略は何ですか?

1. リリースの分岐:トランクで開発し、リリースごとに分岐を保持します。
2. 機能の分岐:個別の分岐で各機能を開発し、安定してから一度だけマージします。

これらの両方の戦略を一緒に使用することは理にかなっていますか? のように、リリースごとに分岐しますが、大きな機能にも分岐しますか? これらの戦略の 1 つは、継続的インテグレーションとうまく調和しますか? 不安定なトランクを使用している場合でも、継続的インテグレーションを使用することは理にかなっていますか?

Gitを使用して維持されていたプロジェクトを継承しました。ある時点で、コードは3つの別々のシステムにデプロイされ、各システムは独自の分散型Gitリポジトリを維持していました。

3つのシステムはそれぞれ、元の基本システムを3つの異なる方向に拡張しました。3つのシステムのいずれも互いに同期されていません。一部の変更はマスターブランチにあり、その他は新しいブランチにあります。

3つの異なるソースをまとめて、次のことができるようにするにはどうすればよいですか。

1. 使用する共通ベースを見つけます。
2. 3つのシステムすべてに適用する必要があるバグ修正がどの変更であるかを調べます。と
3. 共通のブランチが1つだけになるように、3つのシステムを適切な方法で維持し、3つの異なるシステムに必要なカスタマイズを分離しますか？

これが理にかなっていることを願っています。これが以前に取り上げられていた場合はお詫び申し上げます。

状況: 本番環境への定期的なリリースを行っています。少なくとも 2 週間に 1 回ですが、多くの場合、1 週間に最大 3 回のリリースがあります。私たちには、3xSE、2xWD、3xQA、およびテクニカル マネージャー/リード (私) の集中チームがあります。チームは要件に応じて変動しますが、QA は通常、要件/アセットの遅延や大規模な回帰テスト フェーズに対処するために、最後に向けて大幅に規模が大きくなります。通常はリリース日をターゲットとする 6 つの標準機能ブランチと、リリース ブランチを兼ねる 1 つのトランク。マージと分岐のオーバーヘッドがありますが、これを芸術に落とし込むのはかなり上手になりました。そのため、フィーチャー ブランチの 1 つからトランクへのマージが行われるたびに、定期的にトランクからフィーチャー ブランチにマージすることでブランチを維持します。

問題: このプロセスを改善する方法を検討したいと思います。すべての作業をトランク リポジトリで行い、QA リポジトリに分岐してからリリース ブランチに分岐するオプションを検討しました。これは眉をひそめられる可能性がありますが、トランクから必要な場合は引き続き機能ブランチを使用できます。ポイントは、サイトの 2 つの主要な要素であるコンテンツと機能をまとめるには、物事を時間依存にする必要があるということです。つまり、コンテンツに時間依存性を持たせるメカニズムを提供します (機能に依存できるかどうかはわかりません)。このプロセスのコストは比較的高く、クライアントに十分な速さで対応できないため、うまくいかなかった場合はすぐにわかります。

誰か提案がありますか、または以前に同様の状況に遭遇したことがありますか?

ありがとう

(現在) 3 つのブランチを持つ git リポジトリがあります。

• head安定版です（ git と混同しないでくださいHEAD）
• experimental実験的なコードです。コンパイルするはずです
• norman私のサンドボックスです。その中のコードが壊れている可能性があります

「マスター」git リポジトリは、バックアップされたファイル サーバー上にあります。しかし、ローカル ディスク、自宅のマシン、およびラップトップにレプリカがあります。(いつでもどこでもコードを書く準備ができています)。

git branch -aショー:

Tufts ブランチは、「マスター」レポのリモート ブランチです。ローカル ブランチは追跡する必要があります。git config -l | grep -w remote言います:

これが私の質問です。単一の git コマンドを使用して、 リモートのブランチからすべてのローカル ブランチを同時に更新するにはどうすればよいですか? git-fetchうまくいきません。各リモートブランチの内容について知っていることを更新しますが、それらをローカルにマージしません。そして明らかにgit-pull、現在チェックアウトされているブランチのみを更新します。一度にすべてのブランチを更新したい。それはできますか？

（私は夢中ではありません

部分的には、これがすべて進行している間に作業ディレクトリ内の変更されたファイルに何が起こるかが明らかではないため、部分的には、現在どのブランチに関する情報を保存および復元するためにさらに多くのシェルコードが必要になるためです.)

私は1つの（あまり密接に関連していない）質問を見つけました：

• リモート ブランチの追跡について

私の会社は、顧客固有の修正を可能にするために、バージョン番号をもう 1 段階 (たとえば、major.minor.servicepack から major.minor.servicepack.customerfix に) 拡張するという考えを浮かび上がらせています。

私の経験では、製品の分岐が増えるほど (そして、顧客の修正はコード ベースの分岐であると私は信じています)、オーバーヘッドが増え、労力が希薄になり、最終的には開発の生産性が低下するため、これは表面的には悪い考えのように思えます。グループになります。

リスク対生産性の議論をたくさん見てきましたが、「これは悪い考えだと思います」と言うだけでは十分ではありません。リスクを回避しすぎて、重い、顧客固有の、ソース コードの分岐、開発モデルを採用することの実際のコストについて、どのような文献がありますか?

少し明確にします。このモデルは、顧客が自分のプライベート ブランチにどのバグ修正を適用するかを制御できることを意味すると思います。一般的なトランクにアップグレードすることはめったにないと思います（このモデルには存在しないかもしれません）。つまり、自分の私的な現実のバブルをコントロールできるとしたら、なぜそうするのですか?

TFSで、枯れた枝をマークする最良の方法は何ですか? 支店を移転しますか？ブランチリリースそれ？消して？名前を変更しますか？これらのアプローチのそれぞれについて、どのような問題に遭遇しましたか? 良い点は何ですか？

特定のブランチがデッドとしてタグ付けされた場合に、現在のビューを単にマークまたはフィルタリングする単純なインターフェイス ソリューションがあればいいのですが。そうすれば、ブランチの名前変更や削除などの永続的な操作を行う必要がなくなります。. .

こんにちは、次のことを行う単純なストアド プロシージャを作成したいと思います。

疑似コード

この方法は効果的ですか？ありがとうございました。

フォームのワークフローを作成しています。

フォームは、4 人の承認者を必要とする、または却下される承認フォームです。

承認は得られますが、却下はできません。

Designer 2007 を使用しています。

私のワークフローは次のようになります。

ステップ 1: 条件: 作成済みが作成済みの場合 アクション: すべての承認者に通知する電子メール。

ステップ 2:
条件: Else TomR が yes の場合、TomA が yes の場合 アクション: 作成者にメールを送信し、次の宛先にメールを送信...

ここから、上記と同じ手順を使用して、他の 3 人の承認者の条件分岐を作成しました。

自分がしていることを明らかに理解しているとは思えません。

1 つのリポジトリに複数の Web サイト プロジェクトがあり、それぞれに WordPress のコピーがあります。WordPress の更新とは、すべてのプロジェクト フォルダーを更新し、冗長コピーを保持することを意味します。これは、フォルダー全体を同期する rsync スクリプトに役立ちます。また、完全に機能するサイトのローカル コピーも提供されます。

これを改善する方法はいくつかありますので、フィードバックをお願いします。私は Windows を使用しており、最近 Subversion に移行しました。

1. 各 Web サイト フォルダー内の WordPress ビットへのシンボリック リンクを作成します。これは Subversion と Apache で持ちこたえますか。欠点はありますか？
2. 単一の WordPress フォルダーを用意し、それを他の Web サイト トランクに分岐します。ブランチは安価で、単一のコピーが維持されていると読みましたが、ブランチをトランク全体で行う必要があるかどうかはわかりません。個人的には、これが最良のアプローチだと思います。これを避ける理由はありますか？
3. 最後に、現在の構造を維持し、スクリプトを使用してすべての Web サイト フォルダーにコピーを作成することができました。

最善のアプローチは何ですか?代替ソリューションはありますか?