2

Git クライアントとして Github Desktop (以前の Github for Windows) を使用しています。次のような状況が頻繁に発生します。

開発者 A は、素敵な説明メッセージを含む一連の更新をコミットします。開発者 B は同じブランチで作業しており、その後メッセージとともにコミットを行います。

メッセージ付きの開発者 B のコミットが git ログに表示され、それに続いて、開発者 B から自動メッセージ「merge branch ...」とともにマージ コミットが取得されます。マージ コミットには開発者 A のすべての変更が含まれていますが、開発者 A の素敵なメッセージは消えています。この動作は少し変わったようです。以前はめったに発生しませんでしたが、現在は常に発生しているようです。

(Github Desktop の [同期] ボタンが正確に何をしているのかについての最新情報を見つけるのは難しいですが、以前はそうであったのに変更されたことを示唆する参考文献git pull --rebaseを見つけました。このマージ コミットの問題は、以前よりもはるかに悪化しています。)

私の質問は、開発者 A のコミット メッセージが失われないようにする方法はありますか?

追加するために編集: 問題は 2 つあるようです: 1) 開発者がコミットする前に常にプルを行っているとは限らないため、マージコミットが発生します。元のコミットは失われませんが、表示されません。2) Github Desktop がログを表示する方法は、マージ コミットを表示していますが、元のコミットは表示していません。Github デスクトップ チームからメールで受け取ったコメントを次に示します。

これをさらに掘り下げると、GitHub デスクトップで履歴を表示するときに使用する --first-parent フラグが原因で、コミットが非表示になっているように見えます。現在、この動作を変更する方法はありません。

GitHub Desktop の開発者が共有した、これを行う理由の背後にある合理的な理由の一部を次に示します。

「GitHub Desktop は GitHub Flow 用に最適化されています。このモデルでは、ほとんどの場合、マージは (1) プル リクエストによってブランチがデフォルト ブランチにマージされるか、(2) デフォルト ブランチから更新されるブランチのいずれかを表します。

最初のケースでは、そのプル リクエストを構成する個々のコミットではなく、どのプル リクエストがマージされたかを確認することが最も役に立ちます。プルリクエストはすごいし、歴史を理解するのにとても役立つと思うので、そちらを優先したいと思っています。

2 番目のケースでは、マージに伴うコミットを確認しても、ブランチの変更が不明瞭になるだけです。ブランチに固有のコミットを確認するのが最も便利です。」

おそらく Github デスクトップは私たちに適していないのではないかと感じています。私は個人的に GitKraken に切り替えましたが、私たちの多くはコマンド ラインをより多く使用しています。

4

2 に答える 2

2

Git マージはそうすべきではありません。Git GUI が実行しているコマンド (マージ、リベース、スカッシュなど) がわからない場合は、git mergeコマンドラインで実行することをお勧めします。これにより、何が起こるかを制御できます。

ほとんどのグラフィカルな Git クライアントはあいまいで語彙が混乱するため、私はコマンドライン Git を支持する傾向があります。

于 2016-03-24T13:51:40.427 に答える
1

おそらく、開発者 A のコミット メッセージは失われません。これは、Github デスクトップ アプリケーションがコミットを表示する方法です。

を実行して、実際にコミットを失ったかどうかを確認できますgit log --graph

マージされたコミットを表示するクライアントが必要な場合は、SourceTreeまたはTortoiseGitを使用できます。

詳細については、この回答この質問を参照してください。

于 2016-06-03T11:28:44.623 に答える