問題タブ [git-merge]

デフォルトの名前変更制限は 100 であり、config を使用してこの値を増やすことができることを認識しています。diff.renamelimit config

私が心配しているのは、この構成がセットアップされていない場合、間違ったマージや不足しているコードがあるのでしょうか? 大きな変更がある 2 つのブランチをマージ (git merge) しようとしています。

誰かがこの構成設定についてもっと光を当てることができますか?

ここ数日、Git を使ったリベースを検討してきました。リベースの議論のほとんどは、リベースによって履歴がクリーンアップされ、より直線的になると言われています。単純なマージを行うと (たとえば)、履歴がいつ分岐し、いつ元に戻されたかを示す履歴が得られます。私の知る限り、リベースするとその履歴がすべて削除されます。質問は次のとおりです。コードがどこでどのように分岐したかなど、コードが開発されたすべての方法をレポ履歴に反映させたくないのはなぜですか?

私は git 初心者で、これが現在持っているものです。

1. B と C からの変更でコミット Y を更新するにはどうすればよいですか?

   これは単に次のとおりgit fetch machine master; git merge machine/masterです。

2. 特定のファイルの変更を Y から C にプッシュしますか?

マスターと開発ブランチを使用して、git リポジトリで Web サイトのプライベート (孤独な) 開発を行っています。私はいくつかの「大きな」機能と問題に焦点を当てて dev ブランチでかなりの作業を行いましたが、正直なところ、dev ブランチでのコミットはアトミック コミットのショーケースではありませんでした。これは (いくつかの大きな差分で) 終了しましたが、いくつかの主要な機能が機能しなくなりました。動作を停止した理由は多数ある可能性があります。マスターとブランチ間の差分は、いくつかのファイルの多数の変更で構成されています。

ここで、開発ブランチを 1 つずつマスター (またはマスターからのブランチ) にマージし、主な機能を壊した原因を確認したいと思います。

これをGITで簡単に理解する方法はありますか? 私は他の選択肢にもオープンです。私の好みの IDE は emacs ですが、手頃な価格の代替品も受け入れています。

よろしく、ジェロン。

私はリモートGitサーバーを持っています、これが私が実行したいシナリオです：

• バグ/機能ごとに異なるGitブランチを作成します

• 非公式のGitメッセージを使用してそのGitブランチでコードをコミットし続けます

• トップリポジトリでは、公式のGitメッセージを使用して1つのバグに対して1つのコミットを実行する必要があります

では、ブランチをリモートブランチにマージして、すべてのチェックインに対して1つのコミットだけを取得するにはどうすればよいですか（これに対してコミットメッセージを提供したい場合もあります）。

社内で GIT を使用することにしましたが、問題が発生しました。さまざまな機能を持つ複数のブランチがあります。次に必要なのは、そのブランチをマージしてマスターにプッシュすることです。autoreplace を使用してこれを行うにはどうすればよいでしょうか - ブランチ a、ブランチ b、ブランチ c があります - それらすべてをマスターで取得する必要がありますが、ファイルが繰り返される場合、ブランチ b はメジャー、ブランチ c - マイナーである必要があります。

更新:

結果として必要なもの:

documentationによると、git update-index --refreshこれを行います：

現在のインデックスを調べ、stat() 情報をチェックして、マージまたは更新が必要かどうかを確認します。

git が「マージまたは更新が必要かどうかを確認する」とはどういう意味ですか? git は、特定の操作の後に「mergeme」という任意のフラグをどこかに保持していますか?

また、私は理解していると思いますstat（gitインデックスの「統計情報」とは何ですか？）が、マージが必要かどうかをgitが知るのにUIDなどの情報がどのように役立つかわかりません。

aq私のリポジトリには、私が取り組んでいるというブランチがあります。

次に、で新しい作業とバグをコミットしましたmaster。

aqそれらのコミットをブランチに取り込むための最良の方法は何ですか？から別の新しいブランチを作成し、masterそれをaq？

リポジトリA：リビジョンでプロジェクトのSVNからgitに移行されましたr：SVNの履歴、タグなどのすべてを含むすべてのクローンを作成しました。その後、gitで少し開発しました。

リポジトリB：同じプロジェクトですが、リビジョンでSVNから独立して移行されましたr+small_number。最新のスナップショットのみがgitに取り込まれました。その後、多くの独立した開発が行われました。

ここで、AをBにマージしました。SVNは破棄さdevelopれ、GitHub上のプロジェクトのリポジトリのブランチで開発が続行されるという考えです。私は単純なマージを使用して仕事をしました。ありがたいことに、実際の競合はほとんどありませんでした。開発は主にさまざまな分野で行われましたが、マージ後はgitとは関係なく、多くのクリーンアップが行われました。

しかし、今、たとえばマージgit rebase -i HEAD~2された結果を実行すると、最後の2つのコミットをリベースできるはずですが、300以上のコミットのページが表示されます。これは、SVNのリビジョン1以降のプロジェクトの完全な履歴です。私はさらに混乱することを恐れてリベースを中止しました（明らかに私は完全なGit初心者です）。

その結果は期待されていますか？それは望ましいですか？そうでない場合、それを修正する方法は？

すべての単体テストなどに合格し、ファイル自体は問題ないことに注意してください。gitメタデータ/履歴に何が起こったのか理解できません。

編集：これは私が*思う*リポジトリが今のように見えるものです：

私は2つの裸のリポジトリを持っています。それらは次のように作成されます。

1 つは開発に使用され (これをprimaryと呼びましょう)、もう 1 つはバックアップに使用されます (first にアクセスできない場合)。それらを自動的に同期することは可能ですか -git pullバックアップで行うようなものです。

裸のリポジトリをマージまたはプルすることはできないと思います。これではなく、バックアップリポジトリを最新の状態にする別の方法はありますか:

もちろん、プライマリにしばらくアクセスできず、バックアップを使用していた場合は、プライマリを更新したいと思います。

また、作業リポジトリに 2 つのリモートを追加することも解決策ですが、常に両方にプッシュする必要があり、一方にアクセスできない場合は起こりません。

すべての競合は非裸のリポジトリで解決されます

編集なぜバックアップリポジトリが必要なのですか：

リモートリポジトリを使用してコードを交換していますが、これは毎日必要です。通常、人々は他の開発者が作成したコードを必要としませんが、常にそうであるとは限りません。プライマリーとの連絡が 3 日間途絶え、開発は容易ではありませんでした。別のサーバーに 2 番目のリポジトリを作成し、ローカルにクローンを作成しましたが、多くのプロジェクトでそれを行う必要があり、時間がかかります。2 番目のリポジトリを自動的に更新することを好みます。