0

私が取り組んでいる大規模な機能ブランチを台無しにしないようにしようとしています。私は2つのリモコンを持っています:

origin - with branch dev
my - a fork of origin, with my branch dev

したがって、ワークフローは、オリジンをフェッチし、オリジン dev にプルし、そこから分岐し、プッシュアップし、ブランチをオリジン dev にマージすることです。

# On my dev
git fetch origin
... received new stuff...
git pull origin dev

マージされていない他のブランチ機能に依存する機能がありました。だから、私はこれをしました：

# On my dev
git checkout -b first-feature
git checkout -b second-feature-based-on-first-feature

ここからは通常のワークフローに従っています。オリジン dev が更新されると、それに基づいてブランチをリベースします。

git checkout first-feature
git pull --rebase origin dev
git push my first-feature -f

そして、その最初のブランチを 2 番目のブランチの下にプルします。

git checkout second-feature-based-on-first-feature
git pull --rebase my first-feature
git push my second-feature-based-on-first-feature -f

今日、first-feature が origin dev にマージされました。私は、2 つのコミット (first-feature と second-feature) を示した github の second-feature のプル リクエストが、基本的に今 second-feature を表示することを期待していました。しかし、そうではありません。origin dev の 2 番目の機能をリベースしました。すべて問題ないように見えますが、これが心配です。2番目の機能を強制的に押し上げるだけですか?

私はこれが少し具体的であることを知っています。私の質問は次のとおりだと思います:これはどのように機能する必要があり、どこが間違っているのですか? ブランチからブランチを作成するための他の回答に従おうとしましたが、これは非常になじみのない領域であるため、大きな間違いを犯したくありません。

4

1 に答える 1

1

あなたが見ている問題は、歴史を書き換えることの副作用だと思います。

リベースすると、実際にコミットハッシュが変更されます

コミットのハッシュは次のものに依存します。

  1. このコミットのツリー (つまり、ソースの現在の状態)
  2. コミットの親のハッシュ
  3. コミットのメタデータ (作成者の日付、作成者、コミットの日付、コミッター、コミット メッセージなど)

ソース

したがって、オリジン/マスターでリベースしたときの最初の機能のコミットは、元の最初の機能からのコミットに基づいていたため、最初の機能で2番目の機能をリベースすると、最初の場所でコミットします異なる場合、リベースは上位2つのコミットも変更しました。だからあなたは持っていました：

1) -- A 
       \ -- B
             \ -- C 
After rebase origin/dev
2) -- A  -- B'
   -- A  -- B
            \ -- C
Rebase with first-feature
3) -- A' -- B' -- B -- C'

少なくとも、これはあなたが説明したフローから見えるものです。これが役立つことを願っています！

于 2013-11-15T04:24:23.860 に答える