問題タブ [git-merge-conflict]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
git - コメントをコミットする代わりに、競合するファイルに git 挿入 SHA を作成するにはどうすればよいですか?
リベースして競合が発生すると、競合したファイルは次のようになります。
他の人がそれほど素晴らしいコミット メッセージを作成しない場合があるため、次のような結果になる可能性があります。
これの問題は、複数の「修正済み」コミットがある場合、正確なコミットを見つけるのに苦労することです。コミット メッセージの代わりに常に SHA ハッシュを使用するように git を設定する方法はありますか?
git - Git Rebase は前回の Rebase からの競合を繰り返します
以前のリベースで競合がすべて解決されていた場合に、リベースが以前のリベースからの競合を繰り返す一般的な理由はありますか?
さらに、リベースは、競合がどのように解決されたかより優先されますか? たとえば、リベースは、コード内の通常の git 競合ブラケット内の 2 つの可能なコード スニペットの間で厳密な選択を必要とし>>>
ます<<<
か? 競合を解決するために両方のコードの選択肢を削除すると、後の競合を適切に解決するリベースの機能に影響するかどうか興味があります。
さらに詳しく説明します。master
ブランチとdev
ブランチがあります。私がしばらくの間サイドで取り組んできたdev
ブランチなので、異なるコミットの数は 100 代でかなり大きくなりました (私は知っています...もっと頻繁 dev
にすべきです)。ブランチ自体には、いくつかの小さな機能ブランチがカットされてからマージされており、カットされ、リベースされ、ブランチとマージされ、ブランチされることはありませんでした (私が覚えていることです)。1週間前にブランチをブランチにリベースしました。それ以来、ブランチにさらにいくつかの変更を加え、マージの準備ができるようにもう一度リベースしたいと考えています。非常に小さな変更がありましたmaster
dev
dev
master
dev
master
dev
master
master
その 1 週間のウィンドウでも分岐しますが、コード ファイルは重複しません。ただし、リベースすると、1 週間前にリベースdev
しmaster
たときと比較して、現在のリベースを試みるときに git によって同じ一連の競合が発生していることがわかります。
ありがとう!
git - 複数のファイルでのGitマージの競合
1 つの特定のブランチから競合するすべてのファイルを取得するように git に指示するにはどうすればよいですか?
ブランチ 1 をブランチ 2 にマージしているときに、マージの競合が発生しました。各ファイルを追加するのではなく、競合するすべてのファイルを branch1 から取得すると言えますか。
git - Gitインタラクティブリベース - HEADバージョンを維持して競合を解決するようにgitに指示する方法はありますか?
さまざまなバリエーションを試しgit rebase -i -Xours master
ましたが、まだ競合が表示されており、手動で解決する必要があります。さらに、競合するコミットの場合に競合しない変更で何が起こるかは完全には明らかではありません-それらは保持されますか?
ユースケース: 一時的に master 上の古いブランチをリベースして、それらのブランチ (master にはまったくない) にそのような変更があるかどうかを確認しますが、競合する変更 (恐ろしい、恐ろしい競合) のためにコードのバージョンを master に保持します。
git - GIT - チーム内のファイル変更を追跡し、潜在的な競合について警告する方法
チームの他の誰かが私と同じファイルを編集している場合に通知を受ける方法/ツールを探しています。これは、後でマージするときに競合を防ぐためです。ファイルをロックすることではなく、ファイルに注意を向けることだけです (そして、必要に応じて他の開発者との会話を開始します)。
いいえ、チームのコミュニケーションを改善することが解決策になるとは思いません。チームのコミュニケーションがどれほど良好であっても、「合意した」ファイルで作業している間に、さまざまなファイルにいくつかの変更を加える必要がある場合が常にあります。10 分ごとに全員に「やあ、あのファイルに変更を加えている人はいますか?」と叫んでも、それほど生産的ではありません...
このようなプロセス/ツールは、次のように生産性を向上させます。
- 不必要な質問を避ける (「このファイルを変更した人はいますか?」)
- コードの競合や困難なマージを回避する
- 他の誰かがリファクタリングしているのと同じファイルをリファクタリングするために時間を無駄にしない
(検索しましたが、答えを見つけることができませんでした。関連する質問: https://productivity.stackexchange.com/questions/16721/git-way-to-track-file-changes-in-your-team- and-warn-about-potential-conflicts )