質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Git

Gitはオープンソースの分散バージョン管理システム(DVCS)です。

Q&A

解決済

2回答

25042閲覧

gitでMerge branch 'master' of http://~と表示された。

redhat98

総合スコア236

Git

Gitはオープンソースの分散バージョン管理システム(DVCS)です。

0グッド

1クリップ

投稿2016/09/06 14:30

こんにちは

タイトルで書いてある通り、gitを複数人で使っていたらばgitで「Merge branch 'master' of http://~」と表示されました。

やった操作なのですか

  1. 菊池さんがサーバへpush
  2. 小野寺さんがファイルをコミット
  3. 小野寺さんがプルを実行
  4. 小野寺さんがサーバへpush

イメージ説明

ローカルでブランチをマージした時にマージコミットが出来るのは知っていたのですが、
gitではpullした時もリモートからpullした場合もマージコミットが出来るということなのでしょうか?


「4. 小野寺さんがサーバへpush」をした後に、菊池さんのPCでpullしたらば「Merge branch 'master' of http://~」 というログが残っていました。
これは小野寺さんがremote/masterをmasterへマージコミットした履歴がサーバへpushされたということですか?

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答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

KiyoshiMotoki

総合スコア4791

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

redhat98

2016/09/07 09:04

回答有り難うございました。
guest

0

ベストアンサー

2020-02-17 訂正

この回答の通知が来てたので自分の回答を読み直したのですが、
「この時の俺、完全に誤解してやがる……」
と思ったので、5年ぶりに追記を。

gitではpullした時もリモートからpullした場合もマージコミットが出来るということなのでしょうか?

リモートからのプル操作を行ったということであれば、おそらくそのはずです。

質問文章を改めて読み直すと、主語・述語がgitで行われる操作と比べると、私も大分誤解があった印象がありましたので補足します。

マージコミットが出来る

この辺りはKiyoshiMotoki さんの回答内容 の説明の通りです。

ですが、これをもう少し紐解くのと、自分の前回の回答内容の訂正のために、次は順を追って解説していこうと思います。

これは小野寺さんがremote/masterをmasterへマージコミットした履歴がサーバへpushされたということですか?

これはちょっと違うと思います。
あくまで小野寺さんがremote/masterでマージ操作をした履歴が記録されているものと思われます。

自分の事ですが、この回答は大分間違っておりますね……orz
むしろ、 redhad98 さんの認識で間違いないです。

行った操作を見直しましょう。

やった操作なのですか

  1. 菊池さんがサーバへpush
  2. 小野寺さんがファイルをコミット
  3. 小野寺さんがプルを実行
  4. 小野寺さんがサーバへpush

ということですので、一つずつgitでどんなことが行われたか、紐解いていきましょう。

(1.) の時点では、菊池さんの master ブランチの 今までのコミット内容remote/masterpush されたと思います。この時点では remote/master の内容は、菊池さんの今までのコミット内容と同一です。

この時、(2.) の時点では小野寺さんのローカルリポジトリの master ブランチは、菊池さんが push した master ブランチの内容、つまり remote/master ブランチの内容は全く知りません。

(3.)がミソですね。
ここで小野寺さんが pull を行ったことで、 remote/master の内容、すなわち菊池さんの今までのコミットの内容が小野寺さんのローカルリポジトリの master ブランチに取り込もうとします。

しかし、菊池さんの行った変更履歴と小野寺さんが行った変更履歴は、同じ始点から始まっているものの、別の履歴を辿っております。

ここでgitプログラムそのものが気を利かせ、マージを行います(おそらく、小野寺さんが pull を行い、 remote/master の情報を取得し終わった後に、マージコミットの内容がgitで指定されたテキストエディタで開かれてたかもしれません)。

そして、 remote/master に書かれていた履歴の変更内容と小野寺さんの master ブランチの履歴の変更内容を集約したマージコミットが、小野寺さんの master ブランチに付け加えられます。

そして(4.)。ここで小野寺さんが remote/masterpush しましたので、 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
manzyun

総合スコア2244

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

redhat98

2016/09/06 23:10

回答ありがとうございます。 余談にはリモートからpull/mergeをなるべくしないほうがいいと書いてあるのですが、これは毎回ブランチを切った方がいいということなのでしょうか?
manzyun

2016/09/07 00:47

リモート*から*というより、リモート*で*ですね。 gitはどんな細かい変更でも、ローカルでも一度ブランチを切って作業をし、その変更をmasterにマージするというのが、自分が関わってきたプロジェクトでは主流でした。 また、リモート側のソースコードは、どのブランチのコードも動作するソースコードである(コンパイルが通る、シンタックスエラーがでない)ことが望ましいと個人的には思います。 なぜかというと、もしも作業途中で動作しないソースコードをプッシュした場合、他の人が最新のソースコードが欲しいと思ってプルした際に、動作するように書かなければいけないという手間が発生する可能性も否定できないからです。 また、もしも作業中のソースコードを補完したままリモートにある最新のソースコードをローカルに持ってきたいということであれば、stashというコマンドを使うと捗ると思います :) もしかするとこちらのページが参考になるかもしれません。 Git チュートリアルとトレーニング| Atlassian https://www.atlassian.com/ja/git
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問