リベース後にブランチにプッシュできない 質問する

リベース後にブランチにプッシュできない 質問する

私たちは Git を使用しており、マスター ブランチと開発者ブランチがあります。新しい機能を追加し、コミットをマスターにリベースしてから、マスターを CI サーバーにプッシュする必要があります。

問題は、リベース中に競合が発生した場合、リベースの完了後、リモート ブランチをプルするまで、リモート開発者ブランチ (Github 上) にプッシュできないことです。これにより、コミットが重複します。競合がない場合は、期待どおりに動作します。

質問: リベースと競合解決後、重複コミットを作成せずにローカルとリモートの開発ブランチを同期するにはどうすればよいですか?

設定:

// master branch is the main branch
git checkout master
git checkout -b myNewFeature

// I will work on this at work and at home
git push origin myNewFeature

// work work work on myNewFeature
// master branch has been updated and will conflict with myNewFeature
git pull --rebase origin master

// we have conflicts
// solve conflict
git rebase --continue

//repeat until rebase is complete
git push origin myNewFeature

//ERROR
error: failed to push some refs to '[email protected]:ariklevy/dropLocker.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

// do what git says and pull
git pull origin myNewFeature

git push origin myNewFeature

// Now I have duplicate commits on the remote branch myNewFeature

編集

つまり、次のことがワークフローを壊すことになるようです:

developer1はmyNewFeatureで作業し、developer2はhisNewFeatureで作業しており、どちらもmasterをメインブランチとして使用しています。

developer2はmyNewFeatureをhisNewFeatureにマージします

developer1 はリベースし、競合を解決し、myNewFeature のリモート ブランチに強制プッシュします。

数日後、developer2はmyNewFeatureをhisNewFeatureに再度マージします。

これにより、他の開発者が developer1 を嫌うようになるでしょうか?

ベストアンサー1

まず、あなたと共同作業する人たちは、topic/devel ブランチが共有開発用か、それとも自分だけのものか合意する必要があります。他の開発者は、いつでもリベースされる可能性があるため、私の開発ブランチにマージしないよう知っています。通常、ワークフローは次のようになります。

o-----o-----o-----o-----o-----o       master
 \
   o-----o-----o                      devel0
                \
                  o-----o-----o       devel1

次に、リモートを最新の状態に保つために、次の操作を行います。

 git fetch origin
 git checkout master
 git merge --ff origin/master

私がこれをする理由は 2 つあります。1 つ目は、devel ブランチから切り替えなくてもリモートの変更があるかどうかを確認できるためです。2 つ目は、保存されていない/コミットされていない変更を上書きしないようにするための安全メカニズムです。また、master ブランチにマージを高速化できない場合は、誰かがリモートの master をリベースしたか (その場合は厳しく罰せられる必要があります)、私が誤って master にコミットしたため、自分の側でクリーンアップする必要があることを意味します。

次に、リモートに変更があり、最新の状態に早送りしたら、リベースします。

git checkout devel0
git rebase master
git push -f origin devel0

他の開発者は、自分の開発ブランチを私の最新のものからリベースする必要があることがわかります。

git fetch <remote>
git checkout devel1
git rebase <remote>/devel0

その結果、履歴がより明確になります。

o-----o                                 master
       \
         o-----o-----o                  devel0
                      \
                        o-----o-----o   devel1

しないでくださいコミットを気まぐれにマージします。コミットが重複して作成され、履歴を追跡できなくなるだけでなく、特定の変更によるリグレッションを見つけることがほぼ不可能になります (そもそもバージョン管理を使用するのはそのためですよね?)。あなたが抱えている問題は、まさにこれを行った結果です。

また、他の開発者があなたの開発ブランチにコミットしている可能性があります。これを確認できますか?

マージできるのは、トピック ブランチが に受け入れられる準備ができたときだけですmaster

補足ですが、複数の開発者が同じリポジトリにコミットする場合は、開発者の開発ブランチを区別するために、名前付きブランチを持つことを検討する必要があります。例:

git branch 'my-name/devel-branch'

したがって、すべての開発者のトピック ブランチは、独自のネストされたセット内に存在します。

おすすめ記事