6

背景:

  1. 私は 1 つのサイトで作業している単一の開発者です。
  2. バージョン管理にgitを使用しています。
  3. オフィス、自宅、ラップトップなど、複数のコンピューターを使用して仕事をしています。

現在、サーバーに中央の裸のリポジトリがあります。各コンピューターは、このリポジトリーからクローンを作成し、変更をプッシュします。現在、ブランチ マスターとブランチ dev があります。すべての作業は dev ブランチで行われます。マスターは常に最新の安定した製品コードです。変更は、dev で進行中の変更とともに、いつでもマスターに適用できます。

私の日常のワークフローは次のとおりです。

git checkout dev
//pull in changes from remote
git pull
//make and commit changes as need throughout the day
git add -u
git commit
//these steps only happens when I know master has changed
git checkout master
git pull
git checkout dev
git rebase master //to get changes to master into dev branch
//push changes to central remote at end of day
git push

これは、1 人の開発者にとってかなり標準的なワークフローであるべきだと思います。

さて、私の質問の目的のために、邪魔にならないようにしましょう。私は最近、適切に対処する方法と将来的にそれを防ぐ方法がわからない状況に遭遇しました. 現在、私の開発ブランチは、サイトの一部を大幅に書き直した長期の開発ブランチです。そのため、数か月間開発されています。この作業を行っている間、Master に小さな変更やバグ修正も加えています。Master への変更の 1 つが終了したら、dev を Master にリベースして変更を取得し、それらを中央リポジトリにプッシュします。これはうまくいきました。

しかし、数日前にマスターに変更を加えました。約 1 か月ぶりの変更です。リベースに行ったとき、すべての地獄が解き放たれたように見えました。マスターに存在しないファイルでマージ競合が発生し、同じファイルで同じ競合が何度も発生していました。すべての対立を解決するために 1 日の大部分を費やした後、私はついにあきらめました。

今朝、もう一度試してみましたが、開始する前にプロジェクトのコミット履歴を調べたところ、奇妙なことがわかりました。約 15 件のコミットが繰り返されていることがわかりました。2012 年 7 月 12 日から 2012 年 8 月 24 日までのすべてのコミットが表示されました。次に、すべて異なる SHA ハッシュを使用して、同じコミットを再度リストしました。ご想像のとおり、コミットの日付がすべて時系列でリストされているのを見るまで、私はそれに気づきませんでしたが、突然、再び過去に戻ってしまいました。

解決するために、別のリベースを行いましたが、重複したコミットをスキップしました。私がそれをしたとき、すべてがまったく競合することなく、私が期待したとおりに機能しました.

では、皆さんへの私の質問は、これらのコミットがどのようにして 2 回行われるようになったのか、また今後この悪夢が再び起こらないようにするにはどうすればよいのかということです。質問のタイトルが示すように、問題はリベースされたブランチのリベースとプッシュの使用に関係していると思います。しかし、私は本当にそこで推測しています。何が間違っていたのかを理解するための助けが必要です。

4

1 に答える 1

3

開発マシンが 3 台あるので、このモデルは基本的に 3 人の開発者がいるのと同じだと思います。したがって、開発ブランチはその意味で共有されます。また、共有ブランチとしてリベースすると問題が発生することを SO で読みました。共有ブランチをリベースするよりもマージする方がよいでしょう。それを読んだ後、私はプライベートブランチのみにリベースを使い始めましたが、良い結果が得られました。テスト リポジトリを作成し、2 つのアプローチを試して、それらがどのように比較されるかを確認することをお勧めします。

他の SO の質問が見つかったら、ここにリンクを追加します。

編集:

これがGit でのリモート ブランチのリベースです

もちろん、これにはさまざまな意見があります。:)

于 2012-09-20T17:52:48.077 に答える