2

私はまだ Git に自信を持っている途中なので、Git のいくつかの要素を慎重に検討しています。

作業中にプライベートブランチをリベースするためのコマンドのリストは次のとおりです (作業が終了するまでに古くならないようにするため)。

# Prepare the new private branch
git checkout develop
git pull origin develop
git checkout -b new-feature
# work, commit, work commit, time to rebase...
git checkout develop
git pull develop origin
git checkout new-feature
git rebase develop
# continue working...

私が疑問に思っているのは、いくつかの手順を節約して、リベースしたいときに次のことを実行できるかどうかです。

# on the new-feature branch
git fetch
git rebase origin/develop
# continue working....

それとも、プライベートブランチを開発とマージするときに問題が発生しますか? よろしければ、自分のプライベート ブランチで既に行っている場合、origin/develop を develop とマージする必要がありますか?

4

1 に答える 1

4

概説したフェッチとリベースは問題ありません。2番目の質問については、あなたが何を求めているのかよくわからないので、以下はすべてのベースをカバーしています。

（たとえば、設定しない限り、git pull主に だけgit fetchが続くことに注意してください。十分に最近の.git mergerebasegit mergefetch

origin/developorigin/develop のコミット D1 で進行中のアクティビティと開始点を想定すると、次のようになります。

... - M6                          <- master, origin/master
        \
         D0 - D1                  <- develop, origin/develop
                \
                 N0 - N1          <- HEAD=new_feature

これでgit fetch、「彼ら」は D2 と D3 を追加しました。master と origin/master は移動していないと仮定して (もし移動していれば問題ありません)、ローカルのもののための余地を残しておきます:

        D2 - D3                   <- origin/develop
       /
D0 - D1                           <- develop
       \
        N0 - N1                   <- HEAD=new_feature

だから今（HEAD=new_featureすべて commit を指しているN1）あなたは次のことをします：

git rebase origin/develop

git はこれを行い、2 つの新しいコミットN0'を作成しN1'ます。

                N0' - N1'         <- HEAD=new_feature
               /
        D2 - D3                   <- origin/develop
       /
D0 - D1                           <- develop
       \
        N0 - N1                   [abandoned]

放棄されたコミットは最終的にはなくなり (以下では省略します)、その間に を追加するN2と、 が追加されD4ます。したがって、あなたgit fetchとは次のようになりますgit rebase origin/develop。

                N0' - N1' - N2    [abandoned]
               /
              |     N0''-N1''-N2' <- HEAD=new_feature
              |     /
        D2 - D3 - D4              <- origin/develop
       /
D0 - D1                           <- develop

前と同じように、「放棄された」ものは忘れることができます。これにより、origin/develop.

途中のどの時点でも、次のことができますが、必須ではありません。

git checkout develop && git merge origin/develop && git checkout new_feature

にコミットを追加していないためD1、これは早送りするだけでdevelop、 は と同じコミットを指しorigin/developます。

local をdevelopまだ操作していないが、 をマージする時が来たnew_featureとしましょう。これで次のようになりました。

                    N0''-N1''-N2' <- HEAD=new_feature
                    /
        D2 - D3 - D4              <- origin/develop
       /
D0 - D1                           <- develop

N2'おそらく、上の図の commit を介して のエンドポイントでマージしたいと思うでしょうorigin/develop。あなたは確かに今これを行うことができます:

git checkout develop           # get HEAD onto develop breanch
git merge origin/develop       # fast-forward local develop branch

これにより、これが得られます（ と の間のねじれをまっすぐにしますD1）D2：

                    N0''-N1''-N2'     <- new_feature
                    /
...D1 - D2 - D3 - D4                  <- HEAD=develop, origin/develop

しかし、より興味深い質問は、最終結果を次のようにしたいかということです。

                    N0''-N1''-N2'     <- new_feature, HEAD=develop, origin/develop
                    /
...D1 - D2 - D3 - D4

または、次のようになります。

                    N0''-N1''-N2'     <- new_feature
                    /            \
...D1 - D2 - D3 - D4 ------------ M   <- HEAD=develop, origin/develop

? その merge commitが必要な場合はM、最後git mergeのコマンドに引数が必要になり、最初に commit を指す--no-ffローカルを取得する必要があります。その場合、早送りマージを実行して、ラベルが指すようにする必要があります。developD4developD4

git checkout develop           # set HEAD=develop
git merge origin/develop       # fast-forward develop to origin/develop
git merge --no-ff new_feature  # create merge commit M on local develop
git push origin develop        # and push local develop to origin/develop

ただし、マージ コミットが必要ない場合developは、 final を実行するときに がどこを指しているかは問題ではありませんmerge。早送りするだけだからです。したがって、代わりに次のようにします。

git checkout develop           # set HEAD=develop
# git merge origin/develop     # optional: not needed, but harmless
git merge new_feature          # fast-forward local develop to new_feature
git push origin develop        # and push local develop to origin/develop

最初に「最終的にどのようなコミット グラフを作成したいか」を把握することが常に求められます。必要なグラフを描くことができれば、現在どこにいてもそこにたどり着く方法を理解するのがずっと簡単になります。

于 2013-08-30T04:52:27.047 に答える