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編を
ご覧いただきありがとうございます
ここでチャンネルの購読を忘れずに
質問やコメントは下からどうぞ
ブランチの作り方などの 関連動画もご覧下さい