Git Rebase は 既存のコミットに対して行い― 今日から始まるブランチに 配置することができるものです GitHub と Git 基礎 ブランチを作成するのは 難しい決断です 今日からにすべきか 後で開始するようにすべきか？ 重要な修正がいくつか 今まさに起こっているかもしれません 明日まで待った方がいいのでしょうか Gitなら そんな難しい決断は不要です 好きなときにブランチを開始して 実行するつもりの変更を 残しておきましょう 特定の機能や バグや目的の修正に 特化したものにします 基本的な使用法 masterブランチで起こりつつある 重要な修正に組み込むため― この変更を履歴上では 後から開始したい場合は どうすればいいでしょう？ 問題ありません Rebase が助けてくれます 一般的な使用法ではRebase によって ブランチを履歴の後の方に 再配置できます つまりあなたのブランチに 分岐させておいた変更を全て まるでmasterブランチで 現在起こっている作業の あとから起こったように見せるのです 行うことは同じですが masterブランチから 今後作られるブランチへと 逆マージするよりも 履歴がすっきりします 後のブランチで表示される コンテンツは同じですが マージが後のブランチに行われるといった 複雑さや履歴上の記録が 残りません git checkout と git rebase rebase コマンドによって ブランチにある全てのコミットが 変更されることを覚えておいて下さい 全ての作業を保存しますが 場所や他のコミットに対する関係性は 全て変更されます これは基本的に 他の人が作業していない 自分だけのブランチに行う作業です 関係性や 各コミットの識別名における変更により 他の人の作業と一致させるのは難しいのです あなた が作業している ブランチについて話していきますが それらの制約を考えると 使用法はとてもシンプルです Git checkoutは 後に作られるブランチに行い git rebase はソースブランチ― 一般的にmasterブランチに行います そうすると後に作られるブランチに 行われるはずのコミットを すべて反復して 機械的に書き直されたかのように masterブランチの 最新の時点から再生します このプロセスが完了したら 個々のコミットがすべて 行われたことを確認して rebase が完了したことを 知らせてくれます そしてあなたは指示を実行する前と 同じような状態に見える コマンドプロンプトに戻ります しかし これらの履歴上のコミットは 今や新しい識別名を持っていることを 念頭に置いておきましょう このパターンを使うリクエストは オープンソースプロジェクトにおいて 最もよくみられることがわかるでしょう なぜなら コードベースを 将来読む人たちのために 最適化しておこうと考えるためです プロジェクトに将来関わる人たちにとっては １本のまっすぐな履歴が 一番読みやすいのです このため貢献する人たちの方に 履歴をすっきりさせるよう 負荷をかけているのです これは努力ではありますが このプロジェクトに 将来関わるすべての 協力者が 恩恵を受けます 履歴 vs 機能 継続的に実行されるアプリケーション― 例えば ウェブサービスやアプリは 一般的にrebase ではなく マージに最適化されています これらは小さく的の絞られた変更を masterブランチに できるだけ素早く実行できるような メカニズムが必要だからです それによって行われるべき変更が 全てなされなければ 別のブランチを使って またマージするのです Rebase は履歴を明瞭なものに 最適化する力強い機能です あなたのプロジェクトやチームの 必要としている物を確認しましょう 今後のブランチに 素早く実行する必要があれば すぐマージすればいいでしょう 明確な履歴が必要なら Rebase を使えばいいのです Git & GitHub Foundationsの Rebase編を ご覧いただきありがとうございます ここでチャンネルの購読を忘れずに 質問やコメントは下からどうぞ ブランチの作り方などの 関連動画もご覧下さい