違い - git 別ブランチ 取り込み




gitブランチをマスターにマージするベスト(かつ安全な)方法 (6)

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

他のブランチをmasterまたは作成して後でmasterにマージすることをコミットする開発者がいくつかあります。

test作業が数日かかるとし、 master内でコミットを使ってtest更新し続けたいとしましょう。

私はtestからgit pull origin mastergit pull origin masterを行うだろう。

質問1:これは正しいアプローチですか? 他の開発者が私がbtwで働いたのと同じファイルで簡単に作業できました。

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とstack mineの変更を上書きし、他の人が行った変更を上書きすることができるからです。

質問2:どちらの方法が正しいのですか? 違いは何ですか?

このすべての目標は、 masterで起こっていることでtestブランチを更新しておき、タイムラインを可能な限り線形に保つことを望んでmaster戻すことです。


KingCrunchesの答えに加えて 、私は

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

他のブランチでは多くのコミットを行っている可能性がありますが、マスターブランチでコミットする必要があります。 コミット履歴を可能な限りきれいに保つには、テストブランチからのすべてのコミットをマスターブランチの1つのコミットにスカッシュすることもできます( Git:スカッシュまたはスカッシュを参照してください)。 次にコミットメッセージを非常に表現力のあるものに書き直すこともできます。 コードを掘り下げることなく、読みやすく理解しやすいもの。

編集:興味があるかもしれない

ですから、GitHubでは、フィーチャーブランチのブランチに対して次のことを行います。

起源から最新のものを入手する

$ git checkout master
$ git pull origin master

マージベースハッシュを見つける:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

今すぐ最初のものだけがpickていることを確認し、残りはs

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

次に、非常に良いコミットメッセージを選択し、GitHubにプッシュします。 次にプルリクエストを行います。

プルリクエストをマージした後、ローカルで削除することができます。

$ git branch -d mybranch

GitHubで

$ git push origin :mybranch

これは、自分の仕事でチームで使用するワークフローです。 このシナリオはあなたが説明した通りです。 まず、 test作業を終えたら、masterとrebaseして、 testブランチで作業していた時間にmasterに追加されたものを取り込みます。

git pull -r upstream master

testブランチをフォークして適用してからマスターに変更を引き出し、マスターの現在の状態の「上に」テストするために行った変更を適用します。 他の人がテストで編集したのと同じファイルに変更を加えた場合、ここで競合が発生する可能性があります。 存在する場合は、手動で修正してコミットする必要があります。 これを済ませたら、masterブランチに切り替えて、問題なくtestをマージすると良いでしょう。


リベースもマージも誰の変更も上書きすることはできません(競合を解決するときに選択しない限り)。

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

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

あなたがマスターに合併する準備ができたら、

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

あなたがマージで何かを壊すことを心配しているなら、 git merge --abortがあなたのためにあります。

プッシュを使ってマージの手段として引っ張ると、馬鹿です。 なぜあなたがテストを起点にしているのかも分かりません。


古い糸だけど、私のやり方は分からなかった。 リベースを使って作業していて、ブランチからすべてのコミットをマスターの上にマージしようとする人には、価値があるかもしれません。 途中で競合が発生した場合は、コミットごとに解決することができます。

マスターと支店を最新にする:

git checkout master
git pull --rebase origin master
git checkout <branch_name>
git pull --rebase origin <branch_name>

マスターの上にブランチをマージ:

git checkout <branch_name>
git rebase master
git add .
git rebase continue

Rebase中にConflictsを実行した場合:

まず、ファイル内の競合を解決します。 次に:

git add .
git rebase --continue

リベースが終了したら、マスターの上にブランチをリベースする:

git checkout master
git rebase <branch_name>

私はこれをどうやってやるのか

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

リモートからローカルブランチを持っている場合は、リモートブランチよりも別のブランチをマージするのが気になりません。 また、私は私が押したいものに満足し、私と私のローカルリポジトリのためだけで、私は物事を全くプッシュしない、私の変更をプッシュしません。 あなたの説明では、そのtestはあなたのためだけだと思われますか? だからそれを出版する理由はない。

gitは常にあなたと他の人たちを尊重しようとします、そしてそうするでしょう--rebase 。 私はそれを適切に説明することはできないと思うので、Gitの本を見てください- Rebasingまたはgit-ready:少し説明のためにリベースします。 それは非常にクールな機能です


git checkout master
git pull origin master
# Merge branch test into master
git merge test

マージした後、ファイルが変更された場合、マージすると「衝突の解決」というエラーが表示されます

それでは、最初にすべての競合を解決する必要があります。変更をすべてコミットしてから、

git push origin master

これは、彼が何をしたのかを知っていたため、誰がテストブランチで変更を加えた方が良いでしょう。





git-merge