はなぜgitkとsourcetreeグラフをコミットんここで同じリポジトリ

のために異なって見える私のgitkでグラフをコミット（私はグラフをコミットし、ここに正しい用語を使用しています？）はなぜgitkとsourcetreeグラフをコミットんここで同じリポジトリ

、ここでは私のsourcetreeあるため、グラフをコミット同じレポジトリ

どう違って見えるのですか？ gitkグラフが直線であるべきではないか？ここで何かを修正する必要がありますか？

2016-05-17 user20358

特に、マージベースのワークフローを使用している場合、ローカルブランチとリモートブランチは同一である必要はありません。保証されるのは、リモートから引っ張ると、ローカルブランチとリモートブランチが機能的に同一である（つまり、ソースファイルがすべて同期する）ことです。 –

私はローカルとリモートが同じでなければならないことを知っています。しかし、私が知りたいのは、なぜグラフがソルシーツリーでよりきれいに見えるのかです。それは3回目のコミット時にクリーンなブランチを示し、最後のコミット時にうまく戻ってきます。一方、gitkのコミットのグラフは不安定に見えます。私はいつもコミット・グラフが一直線のドットでなければならないと考えてきました。ここで何かが間違っているように見える。それをやった？私は言うことができません。 – user20358

「私には伝えられない」...「私はそれを読むことができません」と言えばより良い記述になります。このため、マージする代わりにリベースを使用する組織が多い理由は、履歴を読み取り可能にするためです。私はあなたの質問に答えることができませんどのように多くのマージがローカルで起こっているかリモコンであなた自身がこれを知っていないかもしれません。 –

私は直線が何であるか分かりません。数学

、より具体的には、グラフ理論において、グラフは、オブジェクトのいくつかのペアがリンクによってに接続されているオブジェクトのセットの表現である：

ウィキペディアによると、グラフです。

グラフの定義には、リンクの曲線や向きが意味を持ちません。

ノードとノード間の接続だけがグラフを作成します。

二つの異なるグラフ表現同じグラフです。

考えてみると、2つの異なる哲学を持ち、異なる2つの異なる時間に2人の異なる人々がグラフに対して全く同じレンダリングを実装することはほとんどありません。
グラフのレンダリングは、gitkまたはsourcetreeが残りの情報をどのように表示するか、またコミットの順序を決める方法によって異なります（グラフを平坦化して表示する必要があるため、コミットは同じである必要はありません）。

出典

2016-05-17 09:24:36

これらのグラフは、同時に同じリポジトリから取得されました。私はおそらく、コミットグラフのgitk表現を読む方法を理解する必要があると思います。 SourceTreeのことは私が今行ったことを模倣しているように理解しています。これはマスターブランチから分岐されたものです〜いくつかのコミットを行い、その後マスターに戻って合併しました。 gitkについては、コミットの順番が違うようです。だから私はより正確であると確信していますか？あるいは、もしコミット 'A'をコミットする前に' B'を入れ、もう一方が 'B'をコミットして後で' A'をコミットすることは重要ですか？ – user20358

私が言ったように、コミットの順序は意味がありません。グラフを平坦化するときに、コミットが時系列順に表示されることを保証することは不可能です。下のグラフから上のグラフに注目すれば、コミットは1つだけです。それから2番目。それから3番目。 3番目から、2つのブランチがあります（左右は意味がありません）。各ブランチにはコミットが1つあります。 2つのブランチは6番目のコミットとマージします。これは言葉によるグラフの記述であり、SourceTreeグラフとGitkグラフの両方で機能します。それ以外は意味がありません。 –

フラット化すると、sourcetreeとgitkは4番目と5番目のコミットの順序が異なりますが、何も意味がありません。 'git log'も独自の順序を持っています。 –

はなぜgitkとsourcetreeグラフをコミットんここで同じリポジトリ

答えて

関連する問題