5

featureに分岐したという名前のブランチがあるとしますmaster。developer1とdeveloper2の両方のチェックアウトfeature。developer1は変更をコミットしfeatureてプッシュします。次に、developer3は何かをにプッシュしmasterます。この時点masterでfeature分岐し、それぞれが個別のコミットを持ちます。

競合がある場合、最新のものmasterをに取得するための正しい方法は何ですか？featureにリベースmasterする必要featureがありますか、それともマージする必要がありますか？

編集：

この場合、developer2の履歴を書き直したくないことを述べておかなければなりません。それは悪いことだからです。右？

4

3 に答える 3

3

ブランチがすでに共有されていることを考えると、 （-共有された-履歴を変更するため）featureリベースすべきではありません。master

masterからへの単純なマージfeatureで十分です（そもそもなぜdev3プッシュされたのかを推測する必要はありません）。master

Adam Dymitrukが コメントしているように、これは「バックマージ」と呼ばれ、帰属する役割によってmasterは疑わしいものです。master安定した本番状態を表す場合は、からではなく、にマージする必要があります 。master master

しかし、繰り返しになりますが、私の答えは、その役割について何の仮定もしていませんでした。

これが、有名なgit-flowがブログ投稿でマスターに来るマージを示している理由です（たとえば、以前にコメントしたようhotfixに、ブランチから）

gitフロー

于 2012-10-17T05:56:36.087 に答える
2

git素晴らしいツールです。しかし、それは開発者間の良好なコミュニケーションに取って代わることはできません。

の変更もに含めるmaster 必要があるかどうかを確認する必要がありますfeature。理想的には、機能ブランチには可能な限り最小限のコードが含まれている必要があります。

変更を絶対に含める必要がfeatureある場合は、基本的に2つのオプションがありますgit rebase。そして、git cherry-pick。から;masterへの後方マージを実行できると思います。featureしかし、それは悪い状況につながる可能性があります...

cherry-pickHEADコメントと作成者情報を保持しながら、特定のコミットまたは複数のコミットを現在のコミットに適用できます。edに成功した後、gitは、にマージして戻ったcherry-pickときに2つのコミットが同じであることを知るのに十分賢いです。私たちが話しているコミットがほんの数個であれば、それで十分なはずです。featuremastercherry-pick

rebase履歴の別のポイントから開始して、現在のブランチ（コミットの行）を適用できます。ご指摘のとおり、これは、のコピーを既に持っているdeveloper1とdeveloper2にとって厄介な場合がありfeatureます。彼らはまた、新しい支店rebaseへの地元の発展を必要とするでしょう。 feature

いずれにせよmaster、developer3が直接コミットするのは独自の機能ブランチであり、その機能ブランチはマージされているはずです。その機能ブランチは、feature必要に応じてマージされている可能性があります。での（最新の）コミットが1つだけであると仮定するとmaster、次のように状況を修正できます。

# Ensure clean working directory
$ git stash

# Create new branch at master
$ git branch some-descriptive-name master

# Move master back one commit
$ git checkout master
$ git reset --hard HEAD^

# Merge the new branch into master
$ git merge --no-ff some-descriptive-name

# Forcibly update master
#   YOU SHOULD COMMUNICATE WITH OTHER DEVS BEFORE DOING THIS
$ git push -f origin master

# Merge the new branch into feature
$ git checkout feature
$ git merge --no-ff some-descriptive-name

この種の「おっと」のことは常に起こる可能性があり、実際に起こるので、私は十分に強調することはできません。

幸運を！

編集：

ingに関する部分は、コミットが数個（または1つだけ）であり、それらすべてがedされるcherry-pickことを前提として書かれています。mastercherry-pick

x -- y (master)
 \
  a -- b -- c (feature)
于 2012-10-17T06:16:29.810 に答える
1

3番目の開発者はマスターで機能を作成するべきではありません。まれな例外は修正プログラムです。しかし、それでも、それはそれ自身のブランチであり、--no-ffマスターにマージされるはずです。機能ごとのブランチに関する長い投稿をここに書きました：http：//dymitruk.com/blog/2012/02/05/branch-per-feature/

于 2012-10-17T05:53:34.350 に答える