タグ付けされた質問 「merging」

これは、バージョン管理ソフトウェアで2つ以上の開発履歴を結合することです。

14
新しい開発者はブランチのマージについていくことができません
私は新しい開発者です-これが私の最初のプログラミング職です。 私の問題はこれです:私たちは使用しますgit-私はブランチからブランチを切り取り、develop割り当てられたマイナータスクの作業を開始します。私は経験が浅いので、とても遅いです。ブランチをdevelop他のブランチにマージする準備が整うまでに、多くの変更を行って競合を解決するのは圧倒的です(実際、作業を破棄してタスクをやり直すのは簡単なようですが、もちろん持続可能なソリューションではありません) )。 どうすればこれを克服できますか?「コーディングが上手」以外の方法を使用できますか?私は来週、これを上司に報告するつもりです。

7
多くのプロジェクトが「git merge」よりも「git rebase」を好むのはなぜですか?
DVCSを使用する利点の1つは、edit-commit-mergeワークフローです(多くの場合、CVCSによって施行されるedit-merge-commitを超える)。マージに関係なく、固有の各変更をリポジトリに記録できるようにすることで、DAGがプロジェクトの真の血統を正確に反映するようになります。 なぜこれほど多くのWebサイトが「マージコミットを回避する」ことについて話しているのですか?事前コミットまたはマージ後のリベースをマージすると、リグレッションの分離、過去の変更の取り消しなどが難しくなりませんか? 明確化のポイント: DVCSのデフォルトの動作があるコミットをマージ作成します。なぜそんなに多くの場所が、これらのマージコミットを隠す線形の開発履歴を見たいという願望について語っているのでしょうか?

5
「頻繁に」マージする方が良いのですか、それとも機能ブランチの大規模なマージが完了してからですか?
複数のブランチが開発されていると言う、AとBだけでなく、増分「バグ修正」ブランチC。 今Cはすでに「完成」しており、マスターにマージされています。AそしてB、まだ開発中であり、(おそらく)別のバグ修正ブランチがmasterにマージされる前に修正されません。 C新しい機能ブランチにできるだけ早くマージすることをお勧めしますか?新しい機能がmasterできるだけ近くにあるように?それとも、新しい機能を完成させてからマスターにマージするだけで、独自の「世界」で開発することをお勧めしますか? とにかく競合が発生するため、それらの修正に時間を費やす必要があります。

4
Visual Studioで1年間の開発を統合するための戦略
私は、2016年全体で新しい開発をメインブランチから分離することを主張するクライアントがいます。他の3〜4チームがさまざまな能力でアプリケーションに取り組んでいます。多数の大きな変更が行われました(依存性注入の実行方法の切り替え、ReSharperによるコードのクリーンアップなど)。mainを新しいdevブランチにマージして、変更をチェーンにプッシュする準備をするようになりました。 私の最初のマージプルで、TFSは競合解決を伴う〜6500ファイルを報告しました。これらのいくつかは簡単になりますが、それらのいくつかははるかに困難になります(具体的には、javascript、apiコントローラー、およびこれらのコントローラーをサポートするサービスの一部)。 これを私にとって簡単にするアプローチがありますか? 明確にするために、途中で何度もこのアプローチに多くの懸念を表明しました。クライアントはこれに関する困難を認識していました。彼らはQAスタッフ(4人の開発者に1人のテスター、自動テストなし、ほとんど回帰テストなし)を選択したため、ブランチの必要性を減らすためにメインブランチの変更からブランチを隔離することを主張しました他の場所で行われている変更について知るためのテスター。 ここでの大きな問題の1つは、アンギュラーバージョンと他のサードパーティソフトウェアのアップグレードです。残念ながら、すべてのピースを元に戻すまで、このソリューションを構築する良い方法を思いつきません。

7
私の会社は支店の合併は間違っていますか?
最近、分岐とマージとSCMについてのMSDNの記事に出くわしました:分岐とマージプライマー-Chris Birmele。 記事では、「ビッグバンマージ」はマージアンチパターンであると述べています。 Big Bang Merge —開発作業の最後までブランチのマージを延期し、すべてのブランチを同時にマージしようとします。 これは、私の会社が生産されているすべての開発ブランチで行っていることに非常に似ていることに気付きました。 私は非常に小さな会社で働いており、1人が最終審査とトランクマージの権限を持っています。5人の開発者(私を含む)がいて、それぞれに個別のタスク/バグ/プロジェクトが割り当てられ、それぞれ現在のトランク(subversion)から分岐し、分岐で開発作業を実行し、結果をテストし、ドキュメントを作成します。必要に応じて、他の開発者とピアレビューとフィードバックループを実行し、プロジェクト管理ソフトウェアでレビュー+マージのためにブランチを送信します。 トランクリポジトリの唯一の権限である私のボスは、ブランチのレビューのすべてを実際に可能な限りレビューを行う単一の時点まで延期し、一部のブランチは拡張/修正のためにスローバックされます。ブランチはすぐにトランクにマージされ、一部のブランチは競合などのためにスローバックされます。 10〜20のアクティブなブランチを最終レビューキューに入れてトランクにマージすることは珍しくありません。 また、2つのブランチが同じトランクから作成されたものの、同じコードを変更したため、最終レビューとマージの段階で競合を頻繁に解決する必要があります。通常、これを回避するには、トランクから分岐し直して変更を再適用し、競合を解決してから、レビューのために新しいブランチを送信します(poor mans rebase)。 私が持っているいくつかの直接的な質問は次のとおりです。 「ビッグバンマージ」と呼ばれる非常にアンチパターンを示していますか? このマージプロセスの結果に見られる問題の一部はありますか? 上司のボトルネックを増やすことなく、このマージプロセスを改善するにはどうすればよいですか? 編集:私の上司がトランクリポジトリに対する彼のグリップを緩めるか、他の開発者がトランクにマージできるようにすることを疑います。彼の理由は定かではありませんが、私はこのトピックを取り上げるつもりはありません。なぜなら、それは以前に取り上げられており、かなり早く撃downされたからです。彼らは私たちを信じていないだけだと思いますが、とにかくすべてが追跡されているので意味がありません。 この状況に関する他の洞察は歓迎されます。

6
SVNマージの難しさは何ですか?
可能性のある重複: 私はSubversionオタクですが、なぜMercurial、Git、またはその他のDVCSを検討する必要があるのですか? 時々、誰かが分散バージョン管理(Git、HG)は集中管理(SVNなど)よりも優れていると言うのを耳にします。SVNではマージが困難で苦痛だからです。実は、SVNでのマージに問題はなかったし、実際のSVNユーザーによるものではなく、DVCS支持者による主張だけを聞いたことがあるので、TVでの不快なコマーシャルを思い出す傾向があるあなたがすでに持っていてうまく動作するものは使用するのが信じられないほど難しいとふりをすることによって、あなたが必要のないものをあなたに売ろうとします。 そして、常に発生するユースケースはブランチを再マージすることです。これは、これらのストローマン製品の広告を思い出させます。自分が何をしているのかわかっているなら、そもそもブランチを再マージするべきではありません(また、その必要はありません)。(もちろん、根本的に間違っていて愚かなことをしているときは難しいです!) だから、ばかげたストローマンのユースケースを割り引いて、DVCSシステムでのマージよりも本質的に難しいSVNマージには何がありますか?
28 git  svn  mercurial  dvcs  merging 

4
なぜgitは競合せずに隣接する行をマージしないのですか?
私は最近、gitで2つのブランチをマージするときに、2つの隣接する行に変更がある場合、gitがこれを競合と宣言することを学びました。たとえば、ファイルtest.txtに次のコンテンツがある場合: Line 1: A Line 2: B Line 3: C Line 4: D ブランチでmasterはこれを Line 1: A Line 2: B1 Line 3: C Line 4: D ブランチでtestingはこれを Line 1: A Line 2: B Line 3: C1 Line 4: D その後、マージしようとするとtestingにmaster、Gitはマージ競合を宣言します。私の素朴な期待は、マージが競合せずに発生し、これをもたらすことでした: Line 1: A Line 2: B1 Line 3: C1 Line …
25 git  merging 

3
マージした変更をすぐにコミットしないのはなぜですか?
私のオフィスでは、バージョン管理にGitとSourceTreeを使用しています。これは、私が参加したときにバージョン管理がゼロであり、SourceTreeしか使用したことがなかったためです。私は決して専門家ではありませんが、同僚の中で最も経験豊富なので、Gitを適切に使用し、間違いを修正するように全員に教える責任がある事実上の専門家です。 GitとSourceTreeを経て、プロセスのすべてのステップを説明するチュートリアルドキュメントを作成しています。プルプロセスでは、SourceTreeダイアログで[マージされた変更をすぐにコミットする]オプションを選択できます。私はこれが何をするのか、なぜそれが役立つのかを理解しています。私が理解していないのは、なぜこの機能を使用したくないのかということです。 マージした変更を自動的にコミットしたくない理由を誰かが説明できますか?私はこの機能の有用性をよりよく説明し、将来どのような落とし穴に注意すべきかを理解できるように、理由を理解しようとしています。 編集:私の質問がリンクされた質問の複製だとは思わない。リンクされた質問は広くコミットする頻度を尋ねています。SourceTreeでのマージのコミットに関連する特定の機能を使用しないことを選択する理由について質問しています。


2
大きなプロジェクトレイアウト:複数のサブプロジェクトに新しい機能を追加する
バージョン管理管理システムで多くのコンポーネントを持つ大きなプロジェクトを管理する方法を知りたいです。 私の現在のプロジェクトには、4つの主要な部分があります。 ウェブ サーバ 管理コンソール プラットホーム。 Webとサーバーの部分は、私が書いた2つのライブラリーを使用します。合計で5つのgitリポジトリと1つのmercurialリポジトリがあります。プロジェクトビルドスクリプトはプラットフォームリポジトリにあります。構築プロセス全体を自動化します。 問題は、複数のコンポーネントに影響する新しい機能を追加するときに、影響を受ける各レポジトリに対してブランチを作成する必要があることです。機能を実装します。それを元に戻します。私の直感は「何かが間違っている」です。 単一のリポジトリを作成し、そこにすべてのコンポーネントを配置する必要がありますか?その場合、分岐が簡単になると思います。または、私が今やっていることをやるだけです。その場合、各リポジトリにブランチを作成するこの問題をどのように解決しますか?

2
プルリクエストを開始するか、マスターでローカルマージコミットを実行する方が良いですか?
私はGitHubをかなり長い間使用しており、通常は機能ブランチをプッシュしてから、自分でマージしたプルリクエストを開始していました。ブランチをマージした場所を追跡するのに役立つことがわかりました。 しかし最近、Gitの仕組みについてますます読んでおり、マージコミットを使用してブランチをマージするときに参照できることに気付きました。 マスターに機能ブランチをマージするときだから、私は何をすべき: 実行し、マージコミットマスターにして、それが上流押しORローカルブランチを押して、プルリクエストを開始しますか? 2人のチームのプルリクエストの紹介を読みました-自分のリクエストをマージしますか?そしていただきましたプロジェクトの2人との作業の流れと公式レポや私のフォーク上の枝から万一Iオープンプル要求?しかし、彼らは誰も私が探しているものに答えていないようです。

2
v1.5より前のSVNでのマージに関する不便さは、メタデータの欠如がもはや問題にならなくなった今では時代遅れになっていますか?
私はSVNを使い始めましたが、DVCSツールと比較してSVNでのマージは非常に難しいと多くのソースが言っています。最新の質問私はSEにここに見つけることができる2012年からです。 時々、v1.5より前のSVNにはメタデータがなかったが、SVNは現在バージョン1.8.9であるという理由が言及されています。 SVNがv1.5よりもはるかに成熟していることを考えると、特にSVN 1.5を使用しなかったため、前述のメタデータの欠如に悩まされていないという事実を考えると、SVN に対するこれらの議論にはまだ多くの妥当性がありますか? DVCSには完全に異なるアプローチがあり、それがより望ましい場合が多いことを理解していますが、何らかの理由でSVNを「必要」とする人にとって、マージはもはや「地獄」ではありませんか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.