未解決の変更をコミットしてみませんか？

従来のVCSでは、ビルドを壊す可能性があるため、未解決のファイルをコミットしない理由を理解できます。ただし、DVCSで未解決のファイルをコミットしない理由を理解できません（実際には、ファイルのコミットを妨げるものもあります）。

代わりに、リポジトリをプッシュおよびプルからロックする必要がありますが、コミットしないでください。

マージプロセス中にコミットできることには、いくつかの利点があります（私が見ているように）。

• 実際のマージの変更は履歴にあります。
• マージが非常に大きい場合は、定期的なコミットを行うことができます。
• 間違えた場合、（マージ全体をやり直すことなく）ロールバックするのがはるかに簡単になります。
• ファイルは、解決済みとしてマークされるまで未解決としてフラグを立てたままにすることができます。これにより、プッシュ/プルが防止されます。

単一の変更セットではなく、変更セットのセットをマージとして機能させることもできます。これにより、などのツールを引き続き使用できますgit rerere。

それでは、なぜ未解決のファイルで眉をひそめたり、予防したりするのですか？伝統以外の理由はありますか？

私が見ることができる最大の問題は、物事が半分マージされ、（おそらく）正しく動作しないコミットのウィンドウを作成することです。ローカルコミットの最終セットをプッシュすると、それらの中間コミットはすべて他のすべてのユーザーにも表示されます。理想的な世界で、私は引くことができるはず任意のコミットとコードが動作するはずです。マージの途中でコミットを開始すると、コードの状態が明確に定義されません。

あなたができることの1つは、マージするローカルコミットを作成し、プッシュするときにそれらを1つの大きなコミットにバンドルすることです（どのVCがこれをサポートするかはわかりませんが）。これはあなたが言及した利点のいくつかをもたらすかもしれませんが、私はそれが余分な複雑さの価値があると確信していません（私たちはすでにかなり混乱して複雑な領域を扱っています）。

私はGitに最も精通しているので、その観点から答えます。

特にコードである場合、あなたや優れたVCSがマージされていないファイルのコミットを許可したい理由はわかりません。リポジトリを一貫した状態に保つ必要があり、提案していることはコミットの原子性に違反します。多くのVCSはファイルを物理的に変更して、競合の場所を示します-Git、SVN、およびCVSは>>>> <<<<タイプマーカーを使用します。アトミックリポジトリレベルのコミットとマージを備えたVCSでは、自分以外の人には意味のないノードを作成しただけです。ソフトウェア開発では、プロジェクトをビルドできませんでした。グループのドキュメントでは、どの変更が正しいかは誰にもわかりません。

現在、Gitは、これを容易にするツールを提供しています。これは、許可されているタイプのコミットです。たとえば、プッシュする前にコミットをマージするすべてを押しつぶすことができます。これは、通常のマージコミットと同じ結果になります。

特典リストに関する具体的な懸念：

1. 実際のマージの変更は履歴にあります。なぜ追加情報が必要なのですか？DVCSは、競合を制限された領域に制限することに関して非常に優れています。保持する変更セットを選択したら、マージコミットノードのコピーを前のコピーと比較すると、まさにこれがわかります。
2. マージが非常に大きい場合、定期的なコミットを行うことができます。これは有効な懸念事項ですが、そもそもここに来るべきではありません。これが起こらないように、ブランチは常にアップストリームの変更を取り込む必要があります。rebase一度に1つのコミットまたはチェリーピッキングなどのツールも、状況によってはここで役立ちます。
3. 間違えた場合、（マージ全体をやり直すことなく）ロールバックするのがはるかに簡単になります。上記を参照してください-あなたの競合がこれほど管理不能になってはいけません。

この提案が機能する唯一の方法は、ブランチがマージ全体がアトミックである場合です-一連のコミットを見ることができますが、それらはコミットツリーの1つのノードとして扱われなければならない大きなマージコミットの単なるステップになります。現在のVCSがこのタイプのワークフローをサポートしているとは思わず、必要だとは思わない。

私の主な経験はMercurialにありますが、Gitも散発的に使用しています。

Mercurialは、未解決のファイルをコミットすることを禁止していません。持っていない変更をプルする前にプッシュすることと同じです。

Mercurialで行う必要があるのは、ファイルをコミットしたい方法で作成した後です。

hg resolve --mark --all
hg commit -m "I'm such a rebel"

--mark will ...マージツールを使用せずに、ファイルを解決済みとしてマークします。--allは、競合のあるすべてのファイルを選択します。

プルせずにプッシュしたい場合（そして結果として他の変更をマージする必要がある場合）は、Jediのようにします。

hg push --force

引っ張る次の男は+1ヘッドを取得します（しゃれは意図されていません）

Gitで同じことを行う方法があると確信しています（おそらくより複雑です）。

gitでマージすると、すべての変更（マージの競合を含む）をすぐにコミットします。次に、次回のコミットで、テキストエディターを使用してマージの競合を解決します。競合が解決したら、必要に応じてプッシュします。

正直なところ、なぜ他の人がこのようにしないのか、またはgitが強制しないのはわかりません。

• 「マージコミット」は、マージする必要があるものの正確な履歴です。
• 次のコミットは、マージの競合を解決するために行ったことを正確に示しています。
• プッシュすると、それまでに競合が解決され、ブランチの先端でビルドが壊れなくなります。
• どの時点でも、競合解決を台無しにした場合、「マージ後」コミットの1つに単純に戻り、再試行できます。

コミットする前に競合を解決する標準ワークフローの大きな欠点は、ローカルコピーからの変更が潜入する可能性があることです。追加は、大規模なマージdiffによってコードレビューから隠されるため、誤ってAPIをコミットしたことに気付かないキーなど

上記の私のワークフローは、このローカルコピーの問題を回避し、コードレビュアーが、標準のコミットdiffとまったく同じように見えるコミットdiffでマージ解決の詳細を（のみ）調べることもできます。

可能な場合は小さな変更をプッシュし、頻繁にプッシュするのが最善だと思います（そしてもちろん常にそうではありません）、ビルドしない、または半分完了したコードをコミットしないでください（私たちはすべてミスをしますが、意図的にそれをしないでください）。私もgitから来ました。私が思う最も良いことの1つは、デスクトップにリポジトリの実行可能なコピーを作成できるということです。大きな変更が完了したら、送信します。

gitで多くのオープンソースを実行するときの最大の不満は、コードの半分をレポに落とし込んでビルドを実行しようとしたことでした。しかし、できませんでした。 、1週間で終了します」。だから、私はそれを廃棄する必要があります（これは男を悩ますでしょう）、または時間をかけて完了して完全に統合します。

私の観点からは、半分のお尻のものをローカルに保管し、有線で良いものを送ってください。

ツールの奴隷にならないでください。

VCSの目標は、仕事を行えるようにすることです。あなたの仕事は、手つかずのローカルリポジトリを保持することではなく、コードを書くことです。早期に、そして多くの場合ローカルでコミットすることで作業効率が向上する場合は、実行してください。

ただし、壊れたコードを上流にプッシュするべきではありません。

根本的に悪いアイデアだからです-それはあなたをparlous状態のリポジトリに導きます（そしてあなたはどこかにプッシュすることを前提とするその発疹、あなたは常に少なくとも1つのコピーを持っているべきだと主張しますが）。

大規模/複雑なマージの場合、進行中の作業を保存して参照ポイントを確立したいかもしれませんが、解決する必要がある混乱した状態のままにシステムを残していることがわかります。

そして、選択肢があります-あなたは頭よりも前からマージするオプションがあります-それはあなたに壮大なマージなしで（または少なくとも理解しやすいより大きなマージで少なくとも変更に適応する能力を与えるかもしれません）。

これは、Gitのリベースが特に便利だと思う場合です（リベースに関する通常の注意事項があります）。現在の状態で変更をリプレイしているので、衝突をより小さく分割することができます。