長期にわたって実行されているローカル機能ブランチがあり、これを定期的にマスターで圧縮およびリベースして、ローカルで最新の状態に保っていました。
完了したら、マスターの上に単一の圧縮コミットで機能を置きます。
しかし、ハードウェアの問題が発生した場合に作業が失われるのではないかと心配だったので、予防措置としてこれを github の新しい機能ブランチにプッシュしました。これを実行してから、機能ブランチはすでにプッシュされているため、どのように最新の状態に保つべきかよくわかりません (マスターからの変更をマージしてマージ コミットを作成したくありません)。
この機能ブランチを使用している開発者は私だけです。そのため、すでにプッシュされたブランチの履歴を書き換えることについては心配していません。追加のコミットをリモートの機能ブランチにプッシュし、機能が完了したらそのブランチを圧縮し、これをマスターにリベースしても問題ありませんか? それとも、ブランチがすでに公開されているため、git はブランチが分岐しているというエラーをスローしますか?
あるいは、作業が完了したら、リモート機能ブランチの追跡を解除し (ローカル ブランチとリモート ブランチの関連がなくなるように)、ローカル機能ブランチのコミットを圧縮してから、機能ブランチをマスターの上にローカルにリベースすればよいと考えていました。
ベストアンサー1
追加のコミットをリモート機能ブランチにプッシュし、機能が完了したらそのブランチをスカッシュし、これをマスターにリベースしても問題ありませんか?
はい、はい、そうです。このブランチの履歴を書き換えることを恐れていないとおっしゃったので、何でも好きなことができます。
または、ブランチがすでに公開されているため、git はブランチが分岐することに関する何らかのエラーをスローしますか?
Git にはパブリック ブランチとプライベート ブランチという概念はありません。ブランチをパブリックまたはプライベートで使用しても、Git はそれについてエラーを出力しません。
の上にブランチをリベースするとmaster、基本的に、 のタイムラインから分岐したポイントからコミットを再生することになりますmaster。そのポイント以降にコミットがありmaster、そのポイント以降に機能ブランチでコミットを行った場合、masterと ブランチは分岐しています。リベースすると、2 つのブランチの変更内容によっては競合が発生する可能性があります。
要約すると、ドキュメント化されていない機能ブランチで何でも好きなことをして、 の上にリベースすることができますmaster。もちろん、何をするかに応じて、リベースはより簡単になるか (競合がほとんどないかまったくない)、より困難になるか (競合が多い) があります。一度にたくさんの競合を見つけるのではなく、少しずつ競合を見つけるために、頻繁にリベースを行うのが良いでしょう。