こんにちは
タイトルで書いてある通り、gitを複数人で使っていたらばgitで「Merge branch 'master' of http://~」と表示されました。
やった操作なのですか
- 菊池さんがサーバへpush
- 小野寺さんがファイルをコミット
- 小野寺さんがプルを実行
- 小野寺さんがサーバへpush
ローカルでブランチをマージした時にマージコミットが出来るのは知っていたのですが、
gitではpullした時もリモートからpullした場合もマージコミットが出来るということなのでしょうか?
「4. 小野寺さんがサーバへpush」をした後に、菊池さんのPCでpullしたらば「Merge branch 'master' of http://~」 というログが残っていました。
これは小野寺さんがremote/masterをmasterへマージコミットした履歴がサーバへpushされたということですか?
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。

回答2件
0
gitではpullした時もリモートからpullした場合もマージコミットが出来るということなのでしょうか?
その通りです。
git pull
のデフォルトの動作は、以下のコマンドを続けて実行するのと同等だからです。
sh
1git fetch 2git merge FETCH_HEAD
https://git-scm.com/docs/git-pull
In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.
ただし、'fast-forward'マージが可能な場合は例外で、このときはマージコミットは作成されません。
--ff
When the merge resolves as a fast-forward, only update the branch pointer, without creating a merge commit. This is the default behavior.
'fast-forward'マージとは、要するにローカルで何も変更を行なっていないブランチが、自身の元となったリモートブランチの変更を取り込むことです。
https://git-scm.com/docs/git-merge#_fast_forward_merge
you have committed no local changes, and now you want to update to a newer upstream revision. In this case, a new commit is not needed to store the combined history; instead, the HEAD (along with the index) is updated to point at the named commit, without creating an extra merge commit.
redhat98 様のケースでは、小野寺さん、菊池さんの双方がローカルブランチを変更した上で git pull しているため、'fast-forward'マージとはなりません。
投稿2016/09/07 03:40
総合スコア4791
0
ベストアンサー
2020-02-17 訂正
この回答の通知が来てたので自分の回答を読み直したのですが、
「この時の俺、完全に誤解してやがる……」
と思ったので、5年ぶりに追記を。
gitではpullした時もリモートからpullした場合もマージコミットが出来るということなのでしょうか?
リモートからのプル操作を行ったということであれば、おそらくそのはずです。
質問文章を改めて読み直すと、主語・述語がgitで行われる操作と比べると、私も大分誤解があった印象がありましたので補足します。
マージコミットが出来る
この辺りはKiyoshiMotoki さんの回答内容 の説明の通りです。
ですが、これをもう少し紐解くのと、自分の前回の回答内容の訂正のために、次は順を追って解説していこうと思います。
これは小野寺さんがremote/masterをmasterへマージコミットした履歴がサーバへpushされたということですか?
これはちょっと違うと思います。
あくまで小野寺さんがremote/masterでマージ操作をした履歴が記録されているものと思われます。
自分の事ですが、この回答は大分間違っておりますね……orz
むしろ、 redhad98 さんの認識で間違いないです。
行った操作を見直しましょう。
やった操作なのですか
- 菊池さんがサーバへpush
- 小野寺さんがファイルをコミット
- 小野寺さんがプルを実行
- 小野寺さんがサーバへpush
ということですので、一つずつgitでどんなことが行われたか、紐解いていきましょう。
(1.) の時点では、菊池さんの master
ブランチの 今までのコミット内容 が remote/master
に push
されたと思います。この時点では remote/master
の内容は、菊池さんの今までのコミット内容と同一です。
この時、(2.) の時点では小野寺さんのローカルリポジトリの master
ブランチは、菊池さんが push
した master
ブランチの内容、つまり remote/master
ブランチの内容は全く知りません。
(3.)がミソですね。
ここで小野寺さんが pull
を行ったことで、 remote/master
の内容、すなわち菊池さんの今までのコミットの内容が小野寺さんのローカルリポジトリの master
ブランチに取り込もうとします。
しかし、菊池さんの行った変更履歴と小野寺さんが行った変更履歴は、同じ始点から始まっているものの、別の履歴を辿っております。
ここでgitプログラムそのものが気を利かせ、マージを行います(おそらく、小野寺さんが pull
を行い、 remote/master
の情報を取得し終わった後に、マージコミットの内容がgitで指定されたテキストエディタで開かれてたかもしれません)。
そして、 remote/master
に書かれていた履歴の変更内容と小野寺さんの master
ブランチの履歴の変更内容を集約したマージコミットが、小野寺さんの master
ブランチに付け加えられます。
そして(4.)。ここで小野寺さんが remote/master
に push
しましたので、 remote/master
に記録されている 今までのコミット内容 は、
「菊池さんの今までのコミット内容が含まれている」
履歴をたどっているので、無事 push
が成功したものと思われます。
今回のケースでは無事にコミットできましたが、やはり個人的には不要なコンフリクト(変更内容の衝突)の発生とその解消に使う時間と労力を減らすためにも、
「変更内容に対して1つはブランチを切る」
運用をお勧めします(5年も経っているのですでにそのように運用されているとは存じ上げますが ^^;)。
他に考えられるマージコミット生成タイミング
GitHub, GitLab, GitBucket などの「ソースコードホスティングWebサービス」で、
プルリクエスト(マージリクエスト)を取り込む操作を行った際には、基本はリモートリポジトリ上でマージなどの変更が行われます(リクエストの取り込み方はリベースでの歴史改変に変更できたりもします(GitHub, GitBucketでは確認済み)。
以下2020-02-17 以前の回答内容(誤回答)
gitではpullした時もリモートからpullした場合もマージコミットが出来るということなのでしょうか?
リモートからのプル操作を行ったということであれば、おそらくそのはずです。
これは小野寺さんがremote/masterをmasterへマージコミットした履歴がサーバへpushされたということですか?
これはちょっと違うと思います。
あくまで小野寺さんがremote/masterでマージ操作をした履歴が記録されているものと思われます。
余談
あまりリモート側でフェッチ&マージやプルなど、ソースコードを編集する操作は行わないほうが混乱を避けれると思います。
投稿2016/09/06 20:13
編集2020/02/17 06:18総合スコア2244
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。

あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/09/07 09:04