2

関連していますが、私が探しているものは完全ではありません。merge -two-branches-what-direction。

状況：

私は興味深い問題を受け継いでいます。そのため、多くのWebサイトのコードを格納するRailsアプリケーションがあります。私がここで働くようになる前に、彼らは新しいウェブサイトを開発するためにマスターブランチを分岐させました。それは素晴らしいことですが、マスターにマージされることはなく、マスターからの変更はブランチにマージされて最新の状態に保たれませんでした。

現在、マスターには2つの新しいWebサイトがあり、ほぼ3分の1が実行されていますが、このブランチには分岐したWebサイトと、そのブランチで実行することで開発が簡単になるほど類似した新しいWebサイトがあります（100時間の最小節約など） 。

また、同じデータベース構造と認証システムを使用しており、これはお客様を追跡するために非常に重要です。そのため、データベースなどで何かを変更するときに、各コードベースに同じ変更を加える必要がないように、それらをマージしたいと思います...

問題：

私の問題は、このブランチをどうすればよいかわからないことです。ロールバックされた新機能のために時折中断してマスターブランチから作業を実行したいのですが、それは起こったことではありません。コードベースがこれまでに離れて成長したため、現在2つのマスターブランチがあるようです。

マスターを他のブランチにマージしようとしましたが、両方のブランチで開発が行われているため、混乱が生じました。そこで、ローカルブランチを作成し、2つをマージしようとしました。しかし、数日間苦労し、すべての競合がマージされたように見えた後、ユニットテストと通常のテストに失敗するだけでした。

助けを求める:(質問）

現時点ではほぼ別々のプロジェクトであるため、2つをマージすることは不可能だと思い始めています（これらをマージするには、430ファイルなどの追加または変更が必要です）

要するに、私の質問はこれだと思います：私は今ブランチで何をしますか？

（私がソース管理と全体的なプロジェクト管理を担当したのは、開発者としては初めてです。したがって、ここでは本当に途方に暮れています。）

テキストの壁をごめんなさい、

4

2 に答える 2

4

まず第一に、フォークは大丈夫です！分岐した2つのブランチがある場合は、それらを別々に検討する価値があるかもしれません。それぞれに素晴らしいコアコードの改善があり、お互いに共有するのが良い場合にのみ、実際にそれらをマージして戻します。それ以外の場合は、フォークを使用すると便利なことがよくあります。

そうは言っても、あなたがそれらをマージしようと努力していると仮定しましょう。

まず、どのブランチが実際にマスターブランチであるかを決定します。確かに、1つはマスターと呼ばれますが、このマージの目的のために、どのブランチがより共有され、履歴が変更された場合により多くの人々に影響を与えるかを決定する必要があります。通常、これは確かにマスターブランチですが、マスターのコピーを他に誰も持っていない場合は、より簡単と思われる方を選択できます。

さて、これで「マスター」ブランチができたので、そのマスターブランチの履歴を乱さないように努力する必要があります。もう一方のブランチを呼び出しますtf（totally_forkedの場合）。それがブランチの先頭に追加された大規模なマージコミットによるものか、からのコミットのほとんどを保持するリベースによるものかtf。これが私が最初にすることです：

  • リポジトリの完全バックアップを作成してください！ <-疑わしい場合は常にこれを行ってください。

トライアルマージ

git checkout tf;
git branch tf_merging;
git checkout tf_merging;

git merge master; 競合の範囲を調べます。これらが重複した修正（この場合はコミットを削除できます）または並列修正での競合であるかどうかを確認します//マージを使用できると思わない場合は、このブランチを破棄します。

git checkout tf;

インタラクティブリベース

git checkout tf;
git branch tf_rebase;

git rebase -i master;//インタラクティブなリベース。マージ試行からのリストを使用して、重複するコミットを排除して防止してください。また、tfのコミットを再配置すると、より適切なマージ候補が得られるかどうかも確認してください。
//競合が多すぎる場合：

git rebase --abort

// git rebaseを数サイクルだけ実行してみてください。リベースが開始された後、おそらく最大で7〜10回続行してください。そうしないと、競合に過度に対処し、とにかく最後に混乱が発生する可能性があります。

最終的な解決策

gitを使用して目的のソリューションを実現できない場合は、別の方法があります。これは、非マスターブランチから特に保持したい機能を選択して選択し、tf重要でないものを破棄することです。たとえば、tfマスターに存在しないライブラリが追加されている場合は、それと他の便利な機能を脇に置いて、マスターからの明確なコミットを追加し、のようなtf、同じ機能を持つブランチを作成します。実際には、最も有用な/コア機能の変更の再実装で、必須ではない多くのコミットがスキップされます。基本的に、tfコアマスターからのブランチの上にその最良の部分を削除して再実装し、共有開発を再開できるようにします。

于 2012-08-28T15:32:35.447 に答える
1

ライアン、新しいプロジェクトを作成して、古いプロジェクトの一部を徐々にコピーし、その間にチームが2つの異なるブランチで作業できるようにすることができます。良い点は、430ファイルを最初から実装するのと同じ苦痛を感じないように、作業コードを移行する必要があることです。アプリケーションの基盤から始めて、常に少数のファイルを移行し、徐々にマージ効果に到達します。また、2つのブランチですでにマージされているファイルの変更にも注意を払う必要があります。幸運を。

于 2012-08-28T15:19:41.497 に答える