rebase のバックアップ(No.5) - .NET 開発基盤部会 Wiki

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
rebase へ行く。
- 1 (2016-03-26 (土) 18:44:19)
- 2 (2016-03-26 (土) 23:17:13)
- 3 (2016-03-27 (日) 10:05:00)
- 4 (2016-04-07 (木) 09:43:52)
- 5 (2017-02-27 (月) 20:21:32)

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

戻る

目次 †

目次
概要
mergeとrebase
使い方
- commit履歴がわかりやすくなる
- rebaseのinteractiveモード
注意、使い分け
- mergeを利用する方法の特徴
  - 良い点
  - 悪い点
- rebaseを利用する方法の特徴
  - 良い点
  - 悪い点
参考

↑

概要 †

Git pull | アトラシアン Git チュートリアル
https://www.atlassian.com/ja/git/tutorial/remote-repositories#!pull
- git fetch commandとそれに続く git merge commandをひとつにまとめたcommand
- rebaseを用いたpull
```
git pull --rebase <remote>
```
  - --rebaseフラグは履歴の直線性を確保してmerge commitを減らす場合に使用する。
  - ＝変更作業は皆が変更を完了したものをベースとして行いたい場合に使用する。
  - 開発者の多くはmergeよりrebaseを選択する傾向がある。
  - SVN における svn update コマンドに近い。

初心者でもわかる！リベースの使い方を解説します | Git編：一歩踏み出すフロントエンド入門
http://liginc.co.jp/web/tool/79390
- rebaseを用いたpull
```
git pull --rebase <remote>
```
  - commit履歴がわかりやすくなる
- rebaseのinteractiveモード [#kee7d862]
```
git rebase -i <commit>
git rebase --interactive <commit>
```
  - commitメッセージを後から変える
  - commitの順序を後から変える
  - 2つ以上のcommitを1個に統合する
  - 一度commitした内容を編集する

↑

mergeとrebase †

[Git] 使い分けできていますか？マージ（merge）&リベース（rebase）再入門 - The Powerful Code
http://powerful-code.com/blog/2012/11/merge-or-rebase/
- merge
  featureブランチでの変更のみを統合後に確認する際には都合が良い
```
$ git checkout master
$ git merge bugfix
```
- rebase
  履歴をシンプルにする（履歴の一本化、マージコミットを生成しない）。
```
$ git checkout bugfix
$ git rebase master
```

↑

使い方 †

初心者でもわかる！リベースの使い方を解説します | Git編：一歩踏み出すフロントエンド入門
http://liginc.co.jp/web/tool/79390

↑

commit履歴がわかりやすくなる †

local branch
- <base-branch> に、現在のfeature branchの全commitを適用
```
git rebase <base-branch>
```

= git checkout <branch> && git rebase <base-branch>
```
git rebase <base-branch> <branch>
```

remote branch
- rebaseを用いたpull
  = git fetch <remote> && git rebase <remote>
```
git pull --rebase <remote>
```

↑

rebaseのinteractiveモード †

現在のbranchにある<commit>以降のcommit（commitとmerge commitを含まない）を取り上げて、エディタが立ち上がる。

git rebase -i <commit>
git rebase --interactive <commit>

以下のコマンドが使える。

pick：commitを採用
reword：commitを採用するがcommitメッセージを変更
edit：commitを採用するがファイルを修正する
squash：一個前のcommitと合体させる
fixup：commitメッセージを変更しない点以外squashと同じ
exec：shellでコマンドを実行する

↑

commitメッセージを後から変える †

直前のcommitメッセージを変える
```
git commit --amend
```

複数前のcommitメッセージを変える
interactiveモードで、pickからreword(r)に書き換える

↑

commitの順序を後から変える †

・・・

↑

2つ以上のcommitを1個に統合する †

直近2つのcommitを1個のcommitにする
```
reset --soft
```

1つ前のcommitと結合する
interactiveモードで、pickからsquash(s)に書き換える

↑

一度commitした内容を編集する †

edit

↑

注意、使い分け †

Git - リベース
https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%99%E3%83%BC%E3%82%B9
- 公開repositoryにpushしたcommitをrebaseしてはいけない（commit IDが変わる）
- mergeとrebase、単純にどちらがよいとは言い切れない。
- 良いとこ取りをするなら、pushしていないlocalの変更だけrebaseし歴史をきれいに保つ。

[Git] 使い分けできていますか？マージ（merge）&リベース（rebase）再入門 - The Powerful Code
http://powerful-code.com/blog/2012/11/merge-or-rebase/

↑

mergeを利用する方法の特徴 †

↑

良い点 †

比較的、簡単な操作
統合されるブランチのコミットを改変しない
統合後もブランチの情報を分離して保持（後から確認するのが容易）

↑

悪い点 †

（特に、複数人が並行して同じブランチ上で作業をする際には、）

多数のブランチの情報が残存したり、
マージコミットが散在したりすることで、

履歴が複雑化する原因になる

↑

rebaseを利用する方法の特徴 †

↑

良い点 †

不要なコミットが入り込むことがないので、直感的かつシンプルに履歴を保つ

↑

悪い点 †

競合発生時の対処手順が、比較的、複雑
統合されるブランチのコミットを改変するので注意が必要

↑

参考 †

Git pull | アトラシアン Git チュートリアル
https://www.atlassian.com/ja/git/tutorial/remote-repositories#!pull

初心者でもわかる！リベースの使い方を解説します | Git編：一歩踏み出すフロントエンド入門
http://liginc.co.jp/web/tool/79390

Git - リベース
https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%99%E3%83%BC%E3%82%B9

サルでもわかるGit入門〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ
- 5. rebase -i でコミットをまとめる【チュートリアル3 コミットを書き換えよう！】
  http://www.backlog.jp/git-guide/stepup/stepup7_5.html
- 6. rebase -i でコミットを修正する【チュートリアル3 コミットを書き換えよう！】
  http://www.backlog.jp/git-guide/stepup/stepup7_6.html