Gitのブランチをmasterにマージする最良の（そして最も安全な）方法は何ですか？

masterから新しいブランチが作成され、それをtest`と呼びます。

開発者の中には、masterにコミットしたり、他のブランチを作成して後でmasterにマージしたりする人もいます。

例えば、testでの作業に数日かかっていて、masterでのコミットによってtestを継続的に更新したいとします。

私なら、test から git pull origin master を実行します。

Question 1: これは正しいアプローチですか？ 私が作業したのと同じファイルを他の開発者が簡単に作業できたはずです。

testでの作業が終わり、それをmaster`にマージする準備ができました。考えられる2つの方法は以下の通りです。

A:

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test

B:

git checkout test
git pull origin master
git checkout master
git merge test

私は--rebaseを使用していません。私の理解では、rebaseはmasterから変更を取得し、私の変更をその上に重ねるため、他の人が行った変更を上書きする可能性があるからです。

Question 2: この2つの方法のうち、どちらが正しいのでしょうか？ 何が違うのでしょうか？

これらすべての目的は、testブランチをmasterで起きていることに合わせて更新し続け、後でそれらをmasterにマージして、タイムラインをできるだけ直線的に保つことです。

uneet7
編集された質問 28日 1月 2019 в 7:21
プログラミング
git branching-and-merging git-merge git-branch
9日 4月 2011 в 12:01
16 ビュー
ソリューション

私ならこうする

git checkout master
git pull origin master
git merge test
git push origin master

リモートからのローカルブランチがある場合、このブランチ以外のブランチをリモートにマージするのは気が引けます。また、プッシュしたい内容に満足するまで変更をプッシュしませんし、自分と自分のローカルリポジトリのためだけのものをプッシュすることもありません。あなたの説明では、testはあなたのためだけのもののようですね？ですから、それを公開する理由はありません。

git は常にあなたと他の人の変更を尊重しようとしますし、「--rebase」も同様です。私には適切な説明ができないので、the Git book - Rebasingやgit-ready: Intro into rebasingを見てみてください。これはとてもクールな機能です。

Noctis
編集した答え 15日 6月 2016 в 12:02
解説 (19)

これは非常に実用的な質問ですが、上記の回答はすべて実用的ではありません。

のようなものです。

git checkout master
git pull origin master
git merge test
git push origin master

この方法には、2つの問題があります。

1.1. テストブランチとマスターブランチの間にコンフリクトがあるかどうかがわからないので、安全ではありません。

2.つまり、masterブランチでは、testブランチのすべての変更ログを見ることができないということです。

そこで、コンフリクトが発生しているのではないかと思われるときには、次のような git 操作を行います。

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

コミットする前に merge をテストし、--no-off によるファストフォワードコミットを回避します。

コンフリクトが発生した場合は、git status を実行してコンフリクトの詳細を確認し、解決を試みます。

git status

コンフリクトを解決したら、あるいはコンフリクトがない場合は、それらを commit して push します。

git commit -m 'merge test branch'
git push

しかし、この方法ではテストブランチに記録された変更履歴が失われてしまい、他の開発者がプロジェクトの履歴を理解するのが難しいmasterブランチになってしまいます。

ですから、最良の方法は、mergeの代わりにrebaseを使うことです(今回のように、ブランチの衝突を解決した場合を想定しています)。

以下は簡単なサンプルです。高度な操作については、http://git-scm.com/book/en/v2/Git-Branching-Rebasing を参照してください。

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

そう、upper が完了すると、Test ブランチのすべてのコミットが Master ブランチの先頭に移動します。リベースの主な利点は、プロジェクトの履歴が直線的で非常にきれいになることです。

唯一の注意点は、master ブランチのような公開ブランチでは rebase を使わないことです。

**以下のような操作は絶対にしないでください。

git checkout master
git rebase -i test

詳細はこちら https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

アペンディックス

Semnodime
編集した答え 24日 9月 2018 в 8:36
解説 (8)

リベースもマージも、誰かの変更を上書きしてはいけません（コンフリクトを解決する際に上書きすることを選択した場合を除く）。

開発中の通常のアプローチは

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

masterに戻ってマージする準備ができたら

git checkout master
git log ..test # if you're curious
git merge test
git push

マージ中に何かを壊してしまうのではないかと心配な場合は、git merge --abortがあります。

マージの手段として push や pull を使うのは馬鹿げています。また、なぜtestをoriginにプッシュしているのかよくわかりません。

raylu
編集した答え 14日 10月 2013 в 9:47
解説 (7)