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
にマージして、タイムラインをできるだけ直線的に保つことです。
私ならこうする
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を見てみてください。これはとてもクールな機能です。
これは非常に実用的な質問ですが、上記の回答はすべて実用的ではありません。
のようなものです。
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
アペンディックス
リベースもマージも、誰かの変更を上書きしてはいけません(コンフリクトを解決する際に上書きすることを選択した場合を除く)。
開発中の通常のアプローチは
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にプッシュしているのかよくわかりません。