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