Git / Sourcetreeの基本的な分岐とマージ
初心者の質問アラート!!!私はGitを使い始めました。特にSourcetreeはGitを視覚化するのに適したアプリケーションのようです。私の最初のテストでは、分岐とマージがうまくいきました（上の図を参照）。この構造は、開発ブランチとマスターブランチを間違った方法で使用していることを意味しますが、少なくとも機能しているので問題ありません。
2回目の試行では、両方のブランチで作業が行われていても、ブランチが1つのブランチに表示されているように見えますが（「7アヘッド」のメモ付き）、何も起こらないようです。誰かがここで何が起こっているのかを伝えるには、2番目のスクリーンショットで十分だと思いますか？そうでない場合は、さらに情報を提供してみます。
私はちょうど今遊んでいるので、適切なワークフローを理解し、Sourcetreeを通じて一貫した方法で基本的な分岐およびマージアクションを実行しようとしています。任意の助けをいただければ幸いです。
2番目の図には枝があります。ローカルには、2つのブランチ、master＆developがあります。ただし、両方のブランチは同じコミットで停止しています。最初の図のように「ブランチを表示」したい場合は、developでコミットできますが、グラフはまだ直線に見えます。必要に応じて、その時点でmergedevelopにmasterにすることができます。
グラフの分岐を確認したい場合は、masterにもコミットしてみてください。その後、最初の写真のようなものが表示され始めます。
このような視覚化プログラムでgitがどのように機能するかを理解するには、上記で提案したようなアクションを実行し、各中間ステップでグラフを確認することをお勧めします。
ここでいくつかのことが行われています。まず、Gitのブランチは実際には特定のコミットに固執する「ラベル」であり、ブランチにコミットすると自動的に移動することを理解しておくと役立ちます。 Gitは、新しいコミットハッシュを使用して新しいコミットを作成し、新しいコミットを指すようにブランチ/ラベルを更新します。 （これはタグとどう違うのかと尋ねるかもしれませんが、タグは同じコミットに固定されており、git commitを呼び出しても更新を取得しません。）
新しいブランチを作成すると、Gitは新しいラベルを作成して、同じコミットを指し示します。この新しいブランチがチェックアウトされている間に新しいコミットを作成する場合にのみ、新しいブランチが他のブランチから分岐することがわかります。
実際の混乱は、ブランチのマージを再開すると始まります。これは主に、Gitが「早送りマージ」と呼ぶ奇妙なことによるもので、デフォルトでは。 2番目の例を取り上げて、マスターと開発が元のOrigin/masterとOrigin/developがあった場所を想像してみましょう。
Gitに1つのブランチを別のブランチにマージするように依頼すると、Gitはそれらのブランチの違いをターゲットブランチに取り込むために必要なことを見つけ出します。開発のために行った変更をmasterにマージしたいとし、gitに次のように伝えます。
$ git checkout master
$ git merge develop
Gitはブランチを確認し、いくつかのコミットによって開発がマスターよりも少し先にあることを確認しますが、それ以上に複雑なことはありません。したがって、マスターラベルを取得し、developが指しているコミットに貼り付けるだけで、「早送り」マージを実行します。ミッションが完了し、以前は開発段階にあった変更がマスターになりました。
マスターを開発にマージする直前の最初の例のように、各ブランチに追加のコミットがある場合、「より複雑な」isが実行されます。マスターでコミットを行い、次にgit checkout開発を行い、そこでコミットを行い、thenはGitにmasterを開発にマージするように依頼しました。 Gitは、ブランチラベルを移動するだけで「チート」できなくなりました。 2つのブランチからの変更をその制御下にあるファイルの単一の状態に統合する方法を理解する必要があります（今のところ、それは常に真実であり、それほど遠くないことを前提としています;できない場合は、マージの競合が発生しますが、実際にはそれは見た目ほど悪くはありません）。
マージ後の新しいコンテンツは、最初のブランチの最後の状態でも、2番目のブランチの状態でもありません。したがって、最初の例の一番上に表示されるのは、新しいコミットで表す必要があります。 Gitは「マージコミット」と呼ばれるものを作成し、各ブランチからの変更が単一の状態にマージされた新しい状態を表します。
最後に、厳密に、技術的には必要ではありませんが、Gitに常にマージコミットを作成させることができます。コマンドラインで、-no-ffフラグを使用してこれを行うことができ、早送りしません。グラフィカルクライアントには、同じことを実行するチェックボックスがあります（SourceTreeでは、現在、「早送りでマージが解決されてもコミットを作成する」というラベルが付けられています）。多くの（私も含めて）実際には--no-ffとマージすることをお勧めします。これは、ブランチポインターを単に移動させることが技術的に可能かどうかなどの技術に関係なく、マージの動作が常に履歴に記録されるためです。
私はちょうどこの同じ問題にぶつかり、SourceTreeには「マージ時に早送りしないで、常にコミットを作成する」という設定があることがわかりました。それがチェックされていることを確認すると、それらからのブランチ構造が表示されます。
この設定は、設定の[Git]タブにあります。
"マージ時に早送りしないで、常にコミットを作成する" inツール/オプションを有効にすることで、ソースツリーでブランチが永久に消えないようにすることができます。
マージ操作ごとに決定する場合は、[マージ]ダイアログボックスに「早送りが可能な場合でも新しいコミットを作成する」オプションがあります。
また、技術的な詳細については Eelke Blok の answer を参照することをお勧めします。