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

の結果ls -1を1行に結合して、好きなように区切りたいと思います。 これを達成するために使用できる標準のLinuxコマンドはありますか？

441 linux  bash  shell  parsing  merge 

git-mergeのmanページから、いくつかのマージ戦略を使用できます。 resolve -3ウェイマージアルゴリズムを使用して解決できるのは、2つのヘッド（つまり、現在のブランチとプルした別のブランチ）だけです。それは交差交差のあいまいさを注意深く検出することを試み、一般に安全かつ高速であると考えられています。 再帰的 -これは、3方向マージアルゴリズムを使用して2つのヘッドのみを解決できます。3ウェイマージに使用できる共通の祖先が複数ある場合は、共通の祖先のマージされたツリーを作成し、それを3ウェイマージの参照ツリーとして使用します。これにより、Linux 2.6カーネル開発履歴から取得された実際のマージコミットに対して行われたテストで、マージのミスを引き起こさずにマージの競合が減少すると報告されています。さらに、名前の変更を伴うマージを検出して処理できます。これは、1つのブランチをプルまたはマージするときのデフォルトのマージ戦略です。 タコ -これは2頭以上のケースを解決しますが、手動での解決が必要な複雑なマージを拒否します。これは主に、トピックのブランチヘッドをまとめるために使用することを目的としています。これは、複数のブランチをプルまたはマージするときのデフォルトのマージ戦略です。 私たち -これは任意の数のヘッドを解決しますが、マージの結果は常に現在のブランチヘッドになります。これは、サイドブランチの古い開発履歴に取って代わるために使用されることを意図しています。 サブツリー -これは修正された再帰戦略です。ツリーAとBをマージするとき、BがAのサブツリーに対応する場合、Bは、同じレベルでツリーを読み取るのではなく、最初にAのツリー構造に一致するように調整されます。この調整は、共通の祖先ツリーに対しても行われます。 デフォルトとは異なるものをいつ指定する必要がありますか？それぞれに最適なシナリオは何ですか？

430 git  merge  git-merge 

分散バージョン管理システムが優れている主な理由の1つは、SVNのような従来のツールよりもはるかに優れていると聞いたことがあります。これは、実際には2つのシステムの動作方法に固有の違いが原因ですか、それともGit / Mercurialなどの特定の DVCS実装には、SVNよりも巧妙なマージアルゴリズムしかありませんか？

400 svn  git  version-control  mercurial  merge 

視覚的なマージツールは必要ありません。また、競合するファイルをviで開き、HEAD（鉱山）とインポートされた変更（それら）の間で手動で選択する必要もありません。ほとんどの場合、私はそれらのすべての変更または私のすべてのいずれかが必要です。これは一般的に、私の変更によってアップストリームになり、プルを通じて戻ってきたためですが、さまざまな場所でわずかに変更される可能性があります。 競合マーカーを取り除き、私の選択に基づいてすべての方法を選択するコマンドラインツールはありますか？または、私がエイリアスを設定して各コマンドを実行できる一連のgitコマンド。 # accept mine alias am="some_sequence;of;commands" alias at="some_other_sequence;of;commands" これを行うのはかなり面倒です。「私を受け入れる」ために私は試しました： randy@sabotage ~/linus $ git merge test-branch Auto-merging Makefile CONFLICT (content): Merge conflict in Makefile Automatic merge failed; fix conflicts and then commit the result. randy@sabotage ~/linus $ git checkout Makefile error: path 'Makefile' is unmerged andy@sabotage ~/linus $ git reset …

399 git  merge 

このように迅速に作成された2つの配列がある場合： var a:[CGFloat] = [1, 2, 3] var b:[CGFloat] = [4, 5, 6] それらをどのようにマージでき[1, 2, 3, 4, 5, 6]ますか？

396 ios  arrays  merge  swift  append 

2つのブランチ（AおよびB）があり、ブランチAからの単一のファイルをブランチBからの対応する単一のファイルとマージしたい。

383 git  merge  git-branch 

当社は現在、単純なトランク/リリース/ホットフィックス分岐モデルを使用しており、どの分岐モデルが会社または開発プロセスに最適かについてアドバイスを求めています。 ワークフロー/分岐モデル 以下は、これについて私が見た3つの主な説明ですが、それらは部分的に互いに矛盾しているか、（以下で説明するように）発生した後続の問題を整理するのに十分ではありません。したがって、これまでのところ、私たちのチームはそれほど優れたソリューションではないとしています。あなたはもっと良いことをしていますか？ gitworkflows（7）マニュアルページ （nvie）成功した​​Git分岐モデル （reinh）アジャイルチームのためのGitワークフロー マージとリベース（複雑な履歴と順次履歴） pull --rebaseタスクが完了するまで、メインラインにマージして待機する必要がありますか？個人的には、どのベースでタスクが開始および終了したかを示す視覚的なイラストが保存されるため、私はマージに傾倒していますmerge --no-ff。この目的のためにも、私は好んで使用しています。ただし、他の欠点もあります。また、マージの有用な特性を理解していない人も多くいます-それは可換ではありません（トピックブランチをマスターにマージしても、マスターをトピックブランチにマージすることを意味するわけではありません）。 自然なワークフローを探しています 私たちの手順は単純なルールでは特定の状況を捉えていないため、時々間違いが発生します。たとえば、以前のリリースに必要な修正はもちろん、必要なすべてのブランチに上流をマージできるように十分に下流に基づいている必要があります（これらの用語の使用法は十分明確ですか？）ただし、開発者がそれがさらに下流に配置されているはずであることに開発者が気付く前に、修正がマスターに組み込まれ、それがすでにプッシュされている場合（さらに悪いことに、マージまたはそれに基づくもの）、残りのオプションはチェリーピッキングであり、関連する危険。このような単純なルールを使用しますか？これには、他のトピックブランチを必ず除外する1つのトピックブランチのぎこちなさも含まれます（それらが共通のベースラインからブランチされている場合）。開発者は、機能を完成させて、今書いたコードがもう存在しないような別の感覚を開始したくない （cherry-pickによる）マージの競合を回避する方法 マージの競合を発生させる確実な方法は、ブランチ間でチェリーピックすることです。ブランチを再びマージすることはできませんか？どちらのブランチでも、リバートで同じコミットを適用すると（これを行う方法は？）、この状況が解決される可能性がありますか？これは、私が大部分がマージベースのワークフローを敢えて推し進めない1つの理由です。 局所的な枝に分解する方法は？ トピックブランチから完成した統合をアセンブルすることは素晴らしいことだと認識していますが、開発者による作業は明確に定義されていないことがあり（「ポーキング」のように単純な場合もあります）、コードがすでに「その他」のトピックに入っている場合は、上記の質問によると、それを再びそこから取り出すことはできませんか？トピックブランチの定義/承認/卒業/リリースをどのように行いますか？ コードのレビューや卒業などの適切な手順はもちろんすばらしいでしょう。 しかし、これを管理するのに十分なほど絡み合っておくことはできません。何か提案はありますか？統合ブランチ、イラスト？ 以下は関連する質問のリストです： デプロイされたアプリケーションをホットフィックス可能にするための良い戦略は何ですか？ 社内開発でのGit使用のワークフローの説明 企業のLinuxカーネル開発のためのGitワークフロー 開発コードと製品コードをどのように維持しますか？（この PDFに感謝！） gitリリース管理 Git Cherry-pickとマージのワークフロー 複数のコミットを選択する方法 選択したファイルをgit-mergeでどのようにマージしますか？ 一連のコミットを選択して別のブランチにマージする方法 ReinH Gitワークフロー 元に戻さない変更を行うためのgitワークフロー マージをチェリーピックする OSとプライベートコードを組み合わせた適切なGitワークフロー？ Gitでプロジェクトを維持する 変更された親/マスターでGitがファイルの変更をマージできないのはなぜですか。 Gitのブランチ/グッドプラクティスのリベース 「git pull --rebase」を実行するといつ問題が発生しますか？ 大規模なチームでDVCSはどのように使用されますか？ また、Plastic SCMがタスク駆動開発に書き込む内容を確認し、Plasticを選択しない場合は、nvieの分岐モデルとそれをサポートするスクリプトを調べてください。

378 git  merge  workflow  release  cherry-pick 

パンダと（LEFT| RIGHT| FULL）（INNER| OUTER）結合を実行する方法？ マージ後に不足している行にNaNを追加するにはどうすればよいですか？ マージ後にNaNを取り除くにはどうすればよいですか？ インデックスでマージできますか？ パンダと一緒に参加しますか？ 複数のデータフレームをマージするにはどうすればよいですか？ merge？join？concat？update？WHO？何？なぜ？！ ... もっと。私はパンダのマージ機能のさまざまな側面について尋ねるこれらの繰り返しの質問を見てきました。今日のマージとそのさまざまな使用例に関するほとんどの情報は、不適切な言葉で検索できない数十の投稿に断片化されています。ここでの目的は、後世のためのいくつかのより重要なポイントを照合することです。 このQnAは、一般的なパンダのイディオムに関する一連の役立つユーザーガイドの次の記事になることを意図しています（ピボットに関するこの投稿と、後で説明する連結に関するこの投稿を参照してください）。 この投稿はドキュメントの代わりとなるものではないので注意してください。いくつかの例はそこから取られています。

365 python  pandas  join  merge 

私はgitが初めてで、スカッシュとリベースの違いを理解しようとしています。私が理解しているように、リベースを行うときにスカッシュを実行します。

363 git  merge  rebase  git-rebase  squash 

私は私のトランクの機能ブランチを持っていて、私のトランクから私のブランチへの変更を定期的にマージしていて、すべてがうまく機能していました。今日、私はブランチをトランクにマージし、ブランチの作成後にトランクに追加されたすべてのファイルに「ツリーの競合」のフラグが付けられました。これを将来的に回避する方法はありますか？ これらは適切にフラグが付けられているとは思いません。

353 svn  merge  tree-conflict 

私のブランチでは、.gitignoreにいくつかのファイルがありました 別のブランチでは、これらのファイルは違います。 私は別のブランチを私のものにマージしたいのですが、それらのファイルが無視されなくなったかどうかは気にしません。 残念ながら私はこれを手に入れました： 次の追跡されていない作業ツリーファイルは、マージによって上書きされます これらのファイルを自分で見つけたり、移動したり、削除したりせずに、プルコマンドを変更してこれらのファイルを上書きするにはどうすればよいですか？

343 git  merge  git-merge  git-fetch 

私には2つのブランチがありました：masterとbranch1。私はマージしbranch1直してmaster、そのブランチは終わりです。削除するか、そのままにしておくべきですか？削除するとデータが失われますか？

341 git  merge  branch 

これは基本的な質問のように聞こえるかもしれませんが、私は回答を探しましたが、以前よりも混乱しています。 私のブランチを他のブランチにマージするとき、gitで「ours」と「theirs」はどういう意味ですか？どちらの枝も「私たち」です。 マージの競合では、「ours」は常に2つのバージョンの上部に表示されますか？ 「私たち」は常に、マージの開始時にHEADが指していたブランチを指しますか？もしそうなら、なぜ参照が曖昧な「ours」のような所有格代名詞を使用するのではなく、「current Branch's」のような明確な所有参照を使用しないのはなぜですか（両方のブランチは技術的には私たちのものなので）。 または単にブランチ名を使用します（「ours」と言う代わりに「local master's」などと言うだけです）？ 私にとって最も混乱する部分は、特定のブランチの.gitattributesファイルで指定した場合です。言うことができますテストブランチ、私は、次の.gitattributesファイルを持っています： config.xml merge=ours 次に、チェックアウトしてHEADをマスターに向け、テストでマージします。以来マスターが私たち、そしてあるテストの.gitattributesチェックアウトされていない、それも効果があるのだろうか？効果がある場合、マスターは「私たち」になったので、どうなるでしょうか。

323 git  merge 

私がリポジトリのメンテナーであり、コントリビューターから変更をプルしたい場合、いくつかの可能なワークフローがあります： 私はcherry-pickそれぞれリモートから（順番に）コミットします。この場合、gitはコミットをリモートブランチとは無関係であると記録します。 私mergeはブランチで、すべての変更を取り込み、新しい「競合」コミットを追加します（必要な場合）。 私はmergeそれぞれリモートブランチから（順番に）個別にコミットし、すべてを1つにまとめるのではなく、コミットごとに競合を記録できるようにします。 完全を期すために、rebase（cherry-pickオプションと同じですか？）を実行できますが、私の理解では、これは投稿者を混乱させる可能性があります。多分それはオプション1を排除します。 2と3のどちらの場合も、1とは異なり、gitはコミットのブランチ履歴を記録します。 cherry-pickまたはmerge説明されている方法を使用することの賛否両論は何ですか？私の理解は方法2が標準であるということですが、単一の「競合」マージで大規模なコミットを解決することは、最もクリーンな解決策ではないと感じています。

302 git  merge  cherry-pick 

次を達成するためのPythonicのアプローチは何ですか？ # Original lists: list_a = [1, 2, 3, 4] list_b = [5, 6, 7, 8] # List of tuples from 'list_a' and 'list_b': list_c = [(1,5), (2,6), (3,7), (4,8)] の各メンバーlist_cはタプルです。最初のメンバーはfrom list_aで、2番目のメンバーはfrom list_bです。

298 python  list  merge  tuples