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