私はローカル支店で機能を開発しています。私はただそれをrebasedし、メインブランチに私の変更をマージしました。現地支店で開発を続けたいのであれば、既存の支店で引き続き開発できますか？そのブランチでリベースした場合、最後のマージ以降にコミットをリベースしますか、またはそのブランチに対して行われたすべてのコミットを再度リベースしますか？リベースしてマスタにマージした後でローカルブランチを削除する必要がありますか？
それを削除して新しいものを開始する必要がありますか？
ありがとうございました。
はい、あなたはあなたのローカルブランチで作業を続けることができます（のは、それがfeatureと呼ばれていますしましょう）、あなたはfeatureにgit rebase masterしばらくやる好きなとき。これについての注意点の1つは、ブランチを公開した後（つまり、別のリポジトリにプッシュしたり、リポジトリからリポジトリを取得できるようにした場合）、ブランチをリベースしないことです。開発中の機能が完全であり、テストされているとみなす場合は、featureブランチをmasterにマージしてください。その後、別の機能を追加したい場合は、そのための新しいブランチを作成します。
featureにいるときにgit rebase masterを実行すると、featureのすべての変更がmasterにないとみなしてgitを開始します。これは、約git log master..featureから表示されるコミットの集合です。コミットごとに導入された変更をmasterに再適用しようとしますが、すでに適用されているものはスキップします。この状況は、featureをmasterにマージしてからfeatureにコミットした場合、それ以降のリベースにマージされたものだけが表示されることになります。
毎回リベースする必要はありません。リベースがコミットを一度に適用する際に、さらに多くの競合が発生する可能性があります。ですから、代わりにマージするだけです。
2つ目のrebaseは、トピックブランチを新しいマージコミットに向けるとマージしてからコミットを移動します。 Rebaseは履歴の最後の共通コミットに移動し、指定したブランチの上にその範囲を移動します。
注：
リベースが効果的にそのブランチの歴史を変えます。他の誰かがそのブランチでも作業している場合は、変更をプッシュしようとすると厄介な驚きを与え、gitはできないと伝えます。これは正当な理由によるものです。彼らはそれを押し上げるために彼らの仕事を再建しなければならないでしょう。ご覧のとおり、より多くの人々が一緒に働くと、これはサークルで続けることができます。
マージングは、一部の人が考えるように悪いものではありません。多くの人がトランクベースの開発に慣れているので、彼らは良い線形の履歴を見たいと思っています。誰もが合併しているとき、それはかなり異なって見えるかもしれません！これに対する答えは、最終的には、コミットに加わるラインを見る必要があり、すでに結合されているものと、まだ結合されているものをツールセットに依存するだけです。あなたがより多くの経験を積むにつれ、合併はおそらくあなたが高く評価するものです。
あなたのためにブランチを行っているので、これは私が作業しているプロセスについてよく読んで、ブランチごとの機能の長所と短所を少しでも分かりやすくしてくれることを願っています。あなたはそれらを短命に保つことを望みます！リンク：https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
私が聞いたことのすべてから、新しい開発をマージする最良の方法は、リベースを経由することです。 http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions 私は、リベースが出発点としてどのような点を取っているかを理解しようとしています。 – Catherine
である必要はありません。どちらも長所と短所があります。あなたの質問について。あなたのブランチがあなたが行ったマージの第2の親を指している場合、リベースはすべてを取り、頭痛を引き起こします。あなたのブランチをチェックアウトし、 'git merge -ff-only master'をマージに向けます。次のrebaseは、そのマージ後のコミットのみを考慮します。 –
ありがとう、私はそれを念頭に置くよ！ – Catherine
ありがとう、それは私が知る必要があったものです。 – Catherine