親ブランチの変更が子ブランチに反映されない コミット遅れ

Question

親ブランチ　develop から派生した　test ブランチで作業をしています
ローカルでブランチをきり、pushする際に、リモートをpullせずにそのままpushしてしまい
コミット遅れが生じてしまいました。

先日developに新しい変更があり、それをpullしてもtestブランチに反映されません。
その新しい変更と、testブランチの機能は独立している為、競合は起きないと思うのですが
この状態でtestブランチをdevelogにマージする際、不都合は起きるのでしょうか？

gitにあまり慣れていない為、おかしいことを質問しているかもしれませんが、よろしくお願いします。

Answer 1

Answer 2

「それをpullする」とは， ローカルのtestブランチで git pull develop コマンドを実行するということでしょうか？
それとも単に git pull を実行しているのでしょうか？
もし後者であれば，リモートのブランチと同名のローカルブランチに差分コミットが入るだけで，例えばdevelopがtestにマージされるというようなことはありません（脚注1）

developの変更分を作業ブランチであるtestにマージしたいときは，testに移動してから

$ git pull origin develop
``` とするのが一般的かと思います（脚注2）


---
脚注1： この表現は，多くの場合成り立ちますが正確ではありません
git pullおよびgitのブランチについてはこの記事が詳しいかと思います
[git pullの詳細な挙動を追ってみる](https://hokaccha.hatenablog.com/entry/20120404/1333507076)

脚注2: `git pull --rebase origin develop` の方が私は好きです
[git pull と git pull --rebaseの違いって？ ...](https://kray.jp/blog/git-pull-rebase/)

Comments

[ms5025]

回答ありがとうございます。
コマンドではなくSourceTreeを使っているので、
プルしているということしか理解していないのですが、
git pull を実行しているのだと思います。

ちなみに、developの変更分を作業ブランチであるtestにマージせず、
このままtestブランチをdevelopにマージ すると、どうなりますか？
developへの変更点（今回pullしてもpullできなかった変更点）がtestブランチによって差分として出てしまう感じなのでしょうか？
だとしたら
developにあった変更分を作業ブランチであるtestにマージしてから、
testブランチをdevelopにマージ しなくてはいけないのでしょうか？

[u-sho]

> developの変更分を作業ブランチであるtestにマージせず、
> このままtestブランチをdevelopにマージ すると、どうなりますか？

SourceTreeは使ったことがないため定かではないですが，
おそらくdevelopブランチ上で `git merge origin/test` を実行するのと同等と思われますので
そのつもりで回答させていただきますと
develop上にマージコミットが作成され，そこにtestブランチとdevelopの差分が一つのコミットにまとめて追加されます。

そして，この文の意味するところが私にはわからないのですが，
開発に関わるのがあなた一人なら，developをtestにマージして，
またtestからdevelopにマージして，というようなことはしなくても大丈夫です。
> developへの変更点（今回pullしてもpullできなかった変更点）がtestブランチによって差分として出てしまう感じなのでしょうか？

---
複数人で作業されているなら，developをtestにマージして，
test->developのプルリクエストを出した方が良いかと思います。

[ms5025]

ありがとうございます。
複数人で作業しています。
なのでやはり一度developをtestにマージして，
test->developのプルリクエストを出した方が良いですよね。

ちなみに、そのようにしなかった場合
developにもともとあった変更点が消えるようなことはあるのでしょうか？

[u-sho]

すみません。通知に気付かず・・・
もうお休みになられましたかね^^;

「developにもともとあった変更点」とは，testブランチをdevelopから切った後にdevelopに追加された変更(コミット)のことを指していますか？
それならば，消えることはありません。

これは老婆心で言いますが，コマンドでgitを操作していなくとも，gitの仕組みを知らないことには，対症療法的な解決はできても，疑問の根本的な解消には至らないと思われます。
gitの内部構造やコマンドの構成などは知らなくても支障はないですが，
・ローカルとリモートの違い，
・ローカルにリモートの変更をマージする(pushする)とは何か
・リモートの変更をローカルにマージする(pullする)とは何か
・pullとマージとpushの違い
を弁別できないとgitを使うのは大変だと思います。

回答の脚注2につけているリンク先の記事の図解がわかりやすいので，理解を深めるのに役立つと思います。

[ms5025]

ありがとうございます。
リンク先を熟読して理解を深めたいと思います。
遅くにありがとうございました。
助かりました。

[u-sho]

ベストアンサーありがとうございます。
夜遅くまでお疲れ様です(=^x^=)ﾌｧｲﾄです

[ms5025]

閉めた後に申し訳ありません
＞「developにもともとあった変更点」とは，testブランチをdevelopから切った後にdevelopに追加された変更(コミット)のことを指していますか？

とありましたが、違いました
testブランチをdevelopから切る前にdevelopに追加された変更(コミット)のことです。
私が最新を取らずにそのままリモートにtestブランチをpushしてしまったのです。
（ここで最新を取得してpushするべきだったのですが間違えました）

この場合どうなるのでしょうか？？
なんども申し訳ありません。

[u-sho]

回答を画像を貼るためだけに使ってしまいましたが，

> testブランチをdevelopから切る前にdevelopに追加された変更(コミット)のことです。
> 私が最新を取らずにそのままリモートにtestブランチをpushしてしまったのです。

とは，回答の画像のような状態でpushしたということでしょうか？

この画像の場合，pushすると(force pushでない限り)，
リモートの「コミット8/3」と「コミット8/4」の間でtestブランチが切られたことになります。
リモートの「コミット8/3」，「コミット8/4」，「コミット8/5」は変更されません。

これはリモートのdevelopに「コミット8/7」が追加されていても変わりません。

-------
ブランチを切った現実時間とリモートの状態がリンクしているわけではない。
という表現は，，，わかり辛いですかね^^;　ちょっといい表現が思いつかないです。

もし質問者さんがc言語などでリスト構造（グラフや木などでも）を実装したことがあれば
下の記事でより理解が深まるかと思いますが，，，
https://qiita.com/kaitoy/items/ce6cd3426a16268389d9
そうでないなら恐らく読んでも混乱を深めるだけですので，参考までに

[ms5025]

ご丁寧にありがとうございます。一度しめたのになんども申し訳ありません。
画像の状態で間違い無いです。
この場合、testブランチをdevelopにマージ すると、どうなるのでしょうか？
古い状態で切られたブランチなので
マージ する際、コミット8/3,8/4,8/5が差分として出るのでしょうか？

この場合最初におっしゃって下さったように、
一度testブランチにリモートのdevelopをマージしなければならない、という認識で合っていますでしょうか？

[u-sho]

一日経ってしまいましたが，ご自身で解決されましたでしょうか・・・？
複数人でgitを使って開発しているなら，
メンバーの方に聞いた方がレスポンスが早いのではないかと愚考します。

もしかするとググれと言われるのかもしれませんが，
プログラミングは実際ググって適切な情報を見つけられれば10分でわかることの方が多いので，
検索能力もエンジニアの能力の一つと言われます。私もその考えです。

とはいえ，初めの頃は何を調べればいいのかもわかってない状態なので難しいのですが，
「検索エンジンに何を入力すれば必要な情報が得られるのか？」という問いは
「私は何を知らないのか？」という問いと等しいことが多いです。

以下回答です。
---
ただし，
> 回答の脚注2につけているリンク先の記事の図解がわかりやすいので，理解を深めるのに役立つと思います。
というのは先に言っておきます。私のような素人よりも公式のドキュメントやそれを参照して書かれた記事の方がよっぽど正確です。
特にこの場では図が貼りにくいですし，言葉よりも，適切な図で理解した方が理解しやすいものです。
図解は理解の試金石という言葉もあります。
-------

testブランチをdevelopブランチにマージするなら，以下のようにします。
が，ms5025さんの場合，testをdevelopにマージするのではなく，developをtestにマージしてください。
(つまり，2番以下の操作は行わないでください)
1. リモートのdevelopをローカルにpullする
2. ローカルのtestブランチをローカルのdevelopにマージする
2.1 コミット8/4, 8/5, 8/6が差分として出る
2.2 (あれば)コンフリクトを解消
2.3 ローカルのtestブランチがローカルのdevelopブランチにマージされる
3. ローカルの状態をリモートにpushする

1.について，
　リモートの変更分(コミット8/4, 8/5)をpullしないことには，
ローカルのdevelopにtestをマージしたとしても，
リモートのdevelopにローカルのdevelopをマージする手間が発生しかねません。
なので先にpullして，リモートのdevelopとローカルのdevelopの状態を合わせます。

2.1について，
　コミット8/3からtestにブランチを切ったので，コミット8/3が差分として出ることはありません。
逆にコミット8/6はdevelopにはないので，差分として出ます。

----
> この場合最初におっしゃって下さったように、
> 一度testブランチにリモートのdevelopをマージしなければならない、という認識で合っていますでしょうか？

> 複数人で作業されているなら，developをtestにマージして，
> test->developのプルリクエストを出した方が良いかと思います。

以下，developをtestにマージしてプルリクエストを出す手順を書きます。
1. リモートのdevelopをローカルのdevelopにpullする
2. ローカルの(origin) developブランチをローカルのtestブランチにマージする
2.1 コミット8/4, 8/5, 8/6が差分として出る
2.2 (あれば)コンフリクトを解消
2.3 ローカルのdevelopブランチがローカルのtestブランチにマージされる
3. ローカルの状態をリモートにpushする
4. testをdevelopにマージするプルリクエストを出す
4.1 リモート環境(GitHubでしょうか)を見に行く
4.2 リモート環境がローカルの状態と同じ(testにdevelopがマージされた状態)になっているかを確認する
4.3 New PullRequestボタンなどからプルリクエストを作成する
4.3.1 このとき，baseがdevelopブランチ，sourceがtestブランチになっていることを確認しましょう
4.3.2 merge develop from testだとか，test -> developというように表示されます。
4.3.3 変更内容を書いてプルリクエストを作成(open)します

以上です。

[ms5025]

お返事遅れて申し訳ありません。
詳細にありがとうございました。
おっしゃってる手順でうまくいけました。
私の認識がまだまだ甘く、ちゃんと理解しないといけないなと思いました。
リンクやコメントを読んで、曖昧だった知識がだいぶしっかりできたと思います。
とても感謝しております。
SourceTreeだけでなく、やはりコマンドで処理できるようにもならないとと感じました。

ありがとうございました。