失敗した例この問題は思っている以上に大きいかもしれません。使うのでしょう?コード内のバグの原因を突き止めるための最も重要なツールだからです。私たちのセーフティネットです。利点を損ねてしまいます。しなければなりませんでした。欠陥のあるコミットは、同僚が失敗したリベースによって、コンパイルしなかったコミットの長いチェーンの途中にあります。この不必要かつ回避可能なエラーの結果、私はコミットを追跡するのに1日近く費やしてしまいました。1つのアプローチは、リベースプロセスを終了させ、コードをテストしてバグを特定し、バグが混入したした箇所に履歴を戻すことです。これは対話型のリベースを使うことで実現できます。一つのアプローチは、リベースプロセスのすべてのステップで一時停止し、バグをテスト・修正していく方法です。これは厄介でエラーを起こしやすいプロセスであり、それを行う唯一の理由は直線的な履歴を達成することです。シンプルで良い方法があるでしょうか?あります。シンプルな1ステッププロセスです。すべてのコンフリクトが1回のコミットで解決されます。マージした結果として得られるマージコミットは、ブランチ間の統合点を明確に示しており、実際に何が起こったか、そしていつ起きたかを履歴でわかります。あなたのリポジトリの履歴を正確に保つことの重要性は過小評価されるべきではありません。リベースすることは自分自身とチームに対して嘘をつきます。実際は昨日の別のコミットを元にしているが、そのコミットが今日書かれたふりをします。元のコミットの文脈が失われ、実際に何が起こったかわからなくなります。コードがビルドできることを確認していますか?そのコミットメッセージがまだ意味をなさないことを確認していますか?あなたはリポジトリの履歴を見やすくさせていると信じているかもしれませんが、その結果は逆になるかもしれません。将来、あなたのコードベースにどのようなエラーや課題が起こるのかを言うことは不可能です。正しいリポジトリの履歴は、書き直された(または偽の)履歴よりも有用であると確信することができます。開発者たちがブランチをリベースさせる動機は何ですか?私はそれが虚栄心であるという結論に至りました。リベースは純粋に審美的な操作です。きれいな履歴は、開発者としての私たちにとって魅力的ですが、技術的または機能的な観点からは正当化できません。Hammant非直線的な履歴のグラフ(線路のようなグラフ)は脅威になりえます。私もはじめは間違いなくそう感じると思いますが、恐れなくても大丈夫です。両方)が数多くあります。非直線的なグラフには、いつ、何が起こったのか、という貴重な情報が含まれており、それを直線的にしたところで何も得られません。ブランチが分岐するような非直線的な履歴のために作られ、またそれを推奨しています。使うほうが良いかもしれません。私はあなたのリポジトリの履歴を正確に保つべきだと思います。正しい履歴のリポジトリを分析するツールで快適になり、リベースする誘惑にも落ちません。リベースのメリットは少ないですが、リスクは大きいです。する際、あなたは私に感謝するでしょう。より、この記事に対する貴重なフィードバックを頂きました。彼の素晴らしいサイトは非常におすすめです。ノルウェーで発表した話に基づいています。原著者の許諾を得て翻訳・掲載しています。海外で話題の記事を翻訳して届けるエンジニアのためのメディアです。